default_type limitations

[Dominick Grift]

The default_type functionality is too limited because it assumes that all login programs associate the same type with a given role

This is not the case

For example:

default_type for local_login: joe.role:joe.type
default_type for sshd: joe.role:joe_ssh_server.type
default_type for cockpit joe.role:joe_cockpit_bridge.type

etc

So pam_selinux "select_context" can only support a single login program due to this

I do not understand why default_type is needed in the first place. The contexts/users/ file is more specific:

/etc/selinux/TYPE/contexts/users/joe.user:
sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0
sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 joe1.role:joe1_ssh_server.type:s0
sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 joe1:joe1_cockpit_bridge.type:s0

ie. its already specified that for example joe1.type is default type for joe1.role for local_login and that joe1_ssh_server.type is default type for joe1.role for sshd

So unless i am overlooking something, the default_type file is redundant and it actually adds an extra file to configure

[Dominick Grift]

Post by Dominick Grift
The default_type functionality is too limited because it assumes that all login programs associate the same type with a given role
This is not the case
default_type for local_login: joe.role:joe.type
default_type for sshd: joe.role:joe_ssh_server.type
default_type for cockpit joe.role:joe_cockpit_bridge.type

The thing is that login programs these day's often dont just run a shell on behalf of users directly.
There is often an intermediate process that should not be associated with the shell type ideally

For example sshd uses pam_selinux to associate a context with the privileged user sshd process. This process needs
all kinds of extra permissions for tunneling, forwarding, chroots etc.

this privileged process then runs a shell on half of the user:

sshd -> user "priv" sshd process -> user shell

This works because it uses pam_selinux for the user "priv" sshd manual process transition, and then i can use a transparent automatic type transition to associate a context with the shell (user_sshd.type -> shell -> user.type)

Same with cockpit:
cockpits_session -> user cockpit bridge -> user shell

unlike local_login:
login -> user shell

Post by Dominick Grift
etc
So pam_selinux "select_context" can only support a single login program due to this
sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0
sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 joe1.role:joe1_ssh_server.type:s0
sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 joe1:joe1_cockpit_bridge.type:s0
ie. its already specified that for example joe1.type is default type for joe1.role for local_login and that joe1_ssh_server.type is default type for joe1.role for sshd
So unless i am overlooking something, the default_type file is redundant and it actually adds an extra file to configure
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[Dominick Grift]

Post by Dominick Grift

Post by Dominick Grift
The default_type functionality is too limited because it assumes that all login programs associate the same type with a given role
This is not the case
default_type for local_login: joe.role:joe.type
default_type for sshd: joe.role:joe_ssh_server.type
default_type for cockpit joe.role:joe_cockpit_bridge.type

The thing is that login programs these day's often dont just run a shell on behalf of users directly.
There is often an intermediate process that should not be associated with the shell type ideally
For example sshd uses pam_selinux to associate a context with the privileged user sshd process. This process needs
all kinds of extra permissions for tunneling, forwarding, chroots etc.
sshd -> user "priv" sshd process -> user shell
This works because it uses pam_selinux for the user "priv" sshd manual process transition, and then i can use a transparent automatic type transition to associate a context with the shell (user_sshd.type -> shell -> user.type)
cockpits_session -> user cockpit bridge -> user shell
login -> user shell

I other words: There is no such thing as a "default_type". The default type associated with a given role can vary per login program.

Post by Dominick Grift

Post by Dominick Grift
etc
So pam_selinux "select_context" can only support a single login program due to this
sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0
sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 joe1.role:joe1_ssh_server.type:s0
sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 joe1:joe1_cockpit_bridge.type:s0
ie. its already specified that for example joe1.type is default type for joe1.role for local_login and that joe1_ssh_server.type is default type for joe1.role for sshd
So unless i am overlooking something, the default_type file is redundant and it actually adds an extra file to configure
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[Dominick Grift]

Post by Dominick Grift

Post by Dominick Grift

Post by Dominick Grift
The default_type functionality is too limited because it assumes that all login programs associate the same type with a given role
This is not the case
default_type for local_login: joe.role:joe.type
default_type for sshd: joe.role:joe_ssh_server.type
default_type for cockpit joe.role:joe_cockpit_bridge.type

The thing is that login programs these day's often dont just run a shell on behalf of users directly.
There is often an intermediate process that should not be associated with the shell type ideally
For example sshd uses pam_selinux to associate a context with the privileged user sshd process. This process needs
all kinds of extra permissions for tunneling, forwarding, chroots etc.
sshd -> user "priv" sshd process -> user shell
This works because it uses pam_selinux for the user "priv" sshd manual process transition, and then i can use a transparent automatic type transition to associate a context with the shell (user_sshd.type -> shell -> user.type)
cockpits_session -> user cockpit bridge -> user shell
login -> user shell

I other words: There is no such thing as a "default_type". The default type associated with a given role can vary per login program.

hmm, never mind. I will have to investigate further... looks like i got confused

Post by Dominick Grift

Post by Dominick Grift

Post by Dominick Grift
etc
So pam_selinux "select_context" can only support a single login program due to this
sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0
sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 joe1.role:joe1_ssh_server.type:s0
sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 joe1:joe1_cockpit_bridge.type:s0
ie. its already specified that for example joe1.type is default type for joe1.role for local_login and that joe1_ssh_server.type is default type for joe1.role for sshd
So unless i am overlooking something, the default_type file is redundant and it actually adds an extra file to configure
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[Stephen Smalley]

Post by Dominick Grift
The default_type functionality is too limited because it assumes that
all login programs associate the same type with a given role
This is not the case
default_type for local_login: joe.role:joe.type
default_type for sshd: joe.role:joe_ssh_server.type
default_type for cockpit joe.role:joe_cockpit_bridge.type
etc
So pam_selinux "select_context" can only support a single login program due to this
I do not understand why default_type is needed in the first place.
sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0
sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0
joe1.role:joe1_ssh_server.type:s0
sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0
joe1:joe1_cockpit_bridge.type:s0
ie. its already specified that for example joe1.type is default type
for joe1.role for local_login and that joe1_ssh_server.type is
default type for joe1.role for sshd
So unless i am overlooking something, the default_type file is
redundant and it actually adds an extra file to configure

IIRC, it was first introduced and used by newrole to obtain a default
type for the role so the user wouldn't have to always specify -t, and
predates the introduction of the default_contexts and users/*
configurations. Yes, it could likely be replaced with something more
flexible. I'd like for all of that logic and configuration to get
overhauled and /sys/fs/selinux/user to die.