refpolicy roles / RBAC separation RFC

refpolicy roles / RBAC separation RFC

[Christopher J. PeBenito]

For those interested all of the user roles have been separated out into
individual modules in a new roles refpolicy layer, in refpolicy trunk.
This should enable interested users to add and remove roles more easily.
Each of the user roles has a module named after it (e.g., sysadm module
for sysadm_r), except user_r, which has a name unprivuser, since its not
possible to use "user" as a module name since it is a policy keyword.

Next we will be doing an experiment attempting to use the SELinux RBAC
functionality to separate users instead of SELinux TE.  What this means
is that the role field will start being used more substantially than it
currently is.  In a nutshell, this means that all user objects will have
the user's role rather than object_r.  Then the separate types will be
collapsed into one type where possible.  This will result in per-role
types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
(mozilla_t).

So for example, all of the home directory types will be collapsed into
home_t and home_dir_t.  This results in /root having the context
root:sysadm_r:home_dir_t.

My current idea for RBAC rules is to group object classes in RBAC
constraints similar to the current MLS constraints (e.g. file classes
together, network classes together).  The basic RBAC rule will be:

constrain { dir file ... } { getattr read write .... }
	r1 == r2
	or r1 == system_r
	or r2 == object_r
	or r1 == rbac_subj_role_file_exempt
	or r2 == rbac_obj_role_file_exempt
	or t1 == rbac_subj_type_file_exempt
	or t2 == rbac_obj_type_file_exempt;

Is this too coarse?  Do we want to break it down into read and write
rather than just exempt?

Unfortunately this necessitates some kernel and userspace changes:

Roles aren't respected on objects in the kernel.  So if you create a
file in a directory that has the role staff_r, the file will have an
object_r role instead of staff_r.

Login programs and newrole will have to be changed to set the role on
the terminal.

The above example rule utilizes a role attribute, which doesn't exist.
In the absence of role attributes, role dominance can be used, but its
unclear if the dominance code works, since no one uses it.

Genhomedircon may need to be updated.

Tools such as audit2allow will need more audit2why-like support and
policy info to fix RBAC denials (a general constraints usability issue).

Comments?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher J. PeBenito wrote:
> For those interested all of the user roles have been separated out into
> individual modules in a new roles refpolicy layer, in refpolicy trunk.
> This should enable interested users to add and remove roles more easily.
> Each of the user roles has a module named after it (e.g., sysadm module
> for sysadm_r), except user_r, which has a name unprivuser, since its not
> possible to use "user" as a module name since it is a policy keyword.
> 
> Next we will be doing an experiment attempting to use the SELinux RBAC
> functionality to separate users instead of SELinux TE.  What this means
> is that the role field will start being used more substantially than it
> currently is.  In a nutshell, this means that all user objects will have
> the user's role rather than object_r.  Then the separate types will be
> collapsed into one type where possible.  This will result in per-role
> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> (mozilla_t).
> 
> So for example, all of the home directory types will be collapsed into
> home_t and home_dir_t.  This results in /root having the context
> root:sysadm_r:home_dir_t.
> 
> My current idea for RBAC rules is to group object classes in RBAC
> constraints similar to the current MLS constraints (e.g. file classes
> together, network classes together).  The basic RBAC rule will be:
> 
> constrain { dir file ... } { getattr read write .... }
> 	r1 == r2
> 	or r1 == system_r
> 	or r2 == object_r
> 	or r1 == rbac_subj_role_file_exempt
> 	or r2 == rbac_obj_role_file_exempt
> 	or t1 == rbac_subj_type_file_exempt
> 	or t2 == rbac_obj_type_file_exempt;
> 
> Is this too coarse?  Do we want to break it down into read and write
> rather than just exempt?
> 
> Unfortunately this necessitates some kernel and userspace changes:
> 
> Roles aren't respected on objects in the kernel.  So if you create a
> file in a directory that has the role staff_r, the file will have an
> object_r role instead of staff_r.
> 
> Login programs and newrole will have to be changed to set the role on
> the terminal.
> 
> The above example rule utilizes a role attribute, which doesn't exist.
> In the absence of role attributes, role dominance can be used, but its
> unclear if the dominance code works, since no one uses it.
> 
> Genhomedircon may need to be updated.
> 
> Tools such as audit2allow will need more audit2why-like support and
> policy info to fix RBAC denials (a general constraints usability issue).
> 
> Comments?
> 
As has been stated before, I am not interested in separation of the
homedir based on Role, since this will prevent shared homedirs on
machines where the same user has different roles.  Also makes testing of
homedir roles difficult since changing a role requires a full relabel of
the homedir.  Labeling of the /root directory should be static and not
related to user or role, because domains often want read/write access to
the root directory and dontauditing this becomes complex if this changes
based on semanage rules.

service XYZ start in /root will almost always generate a search of the
/root directory.

Currently Fedora labeling on the homedir is user_home_t or
user_mozilla_home_t, Ie everything user_* So switching this to
mozilla_home_t or home_t would be fine.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgXWwoACgkQrlYvE4MpobMjhgCaAwNYj1MhxbOMA1ONpoh4FvkP
N2UAoMZkGBkmDdt6zaMyBUz/tui30l+8
=/CFO
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> For those interested all of the user roles have been separated out into
> individual modules in a new roles refpolicy layer, in refpolicy trunk.
> This should enable interested users to add and remove roles more easily.
> Each of the user roles has a module named after it (e.g., sysadm module
> for sysadm_r), except user_r, which has a name unprivuser, since its not
> possible to use "user" as a module name since it is a policy keyword.
> 
> Next we will be doing an experiment attempting to use the SELinux RBAC
> functionality to separate users instead of SELinux TE.  What this means
> is that the role field will start being used more substantially than it
> currently is.  In a nutshell, this means that all user objects will have
> the user's role rather than object_r.  Then the separate types will be
> collapsed into one type where possible.  This will result in per-role
> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> (mozilla_t).
> 
> So for example, all of the home directory types will be collapsed into
> home_t and home_dir_t.  This results in /root having the context
> root:sysadm_r:home_dir_t.
> 
> My current idea for RBAC rules is to group object classes in RBAC
> constraints similar to the current MLS constraints (e.g. file classes
> together, network classes together).  The basic RBAC rule will be:
> 
> constrain { dir file ... } { getattr read write .... }
> 	r1 == r2
> 	or r1 == system_r
> 	or r2 == object_r
> 	or r1 == rbac_subj_role_file_exempt
> 	or r2 == rbac_obj_role_file_exempt

Do we think there will ever be another "exempt" object role other than
object_r?  What benefit would it provide?

> 	or t1 == rbac_subj_type_file_exempt
> 	or t2 == rbac_obj_type_file_exempt;
> 
> Is this too coarse?  Do we want to break it down into read and write
> rather than just exempt?

Seems reasonable as a starting point - offhand I don't see the use case
for splitting it into read/write cases.

> Unfortunately this necessitates some kernel and userspace changes:
> 
> Roles aren't respected on objects in the kernel.  So if you create a
> file in a directory that has the role staff_r, the file will have an
> object_r role instead of staff_r.

That's an easy patch to security_compute_sid() to inherit role from the
target (related object) context rather than using object_r always.   In
which case we'll just inherit from the parent directory by default.  And
then role transition support on object classes.

> Login programs and newrole will have to be changed to set the role on
> the terminal.

Not if we get the security_compute_sid logic right and introduce
role_change rules analogous to the type_change rules.  Then the existing
security_compute_relabel() calls by login programs and newrole will
return the desired context.

> The above example rule utilizes a role attribute, which doesn't exist.
> In the absence of role attributes, role dominance can be used, but its
> unclear if the dominance code works, since no one uses it.

Yes, I think we should just add role attribute support.

> Genhomedircon may need to be updated.
> 
> Tools such as audit2allow will need more audit2why-like support and
> policy info to fix RBAC denials (a general constraints usability issue).

Dan has already moved audit2why into a shared object with a swig wrapper
to enable use by audit2allow.  Extending it to export more information
about constraint denials should be doable, although creating suitable
shared library interfaces for libsepol to get the information from the
policy will be more work.

> Comments?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Christopher J. PeBenito wrote:
> > For those interested all of the user roles have been separated out into
> > individual modules in a new roles refpolicy layer, in refpolicy trunk.
> > This should enable interested users to add and remove roles more easily.
> > Each of the user roles has a module named after it (e.g., sysadm module
> > for sysadm_r), except user_r, which has a name unprivuser, since its not
> > possible to use "user" as a module name since it is a policy keyword.
> > 
> > Next we will be doing an experiment attempting to use the SELinux RBAC
> > functionality to separate users instead of SELinux TE.  What this means
> > is that the role field will start being used more substantially than it
> > currently is.  In a nutshell, this means that all user objects will have
> > the user's role rather than object_r.  Then the separate types will be
> > collapsed into one type where possible.  This will result in per-role
> > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > (mozilla_t).
> > 
> > So for example, all of the home directory types will be collapsed into
> > home_t and home_dir_t.  This results in /root having the context
> > root:sysadm_r:home_dir_t.
> > 
> > My current idea for RBAC rules is to group object classes in RBAC
> > constraints similar to the current MLS constraints (e.g. file classes
> > together, network classes together).  The basic RBAC rule will be:
> > 
> > constrain { dir file ... } { getattr read write .... }
> > 	r1 == r2
> > 	or r1 == system_r
> > 	or r2 == object_r
> > 	or r1 == rbac_subj_role_file_exempt
> > 	or r2 == rbac_obj_role_file_exempt
> > 	or t1 == rbac_subj_type_file_exempt
> > 	or t2 == rbac_obj_type_file_exempt;
> > 
> > Is this too coarse?  Do we want to break it down into read and write
> > rather than just exempt?
> > 
> > Unfortunately this necessitates some kernel and userspace changes:
> > 
> > Roles aren't respected on objects in the kernel.  So if you create a
> > file in a directory that has the role staff_r, the file will have an
> > object_r role instead of staff_r.
> > 
> > Login programs and newrole will have to be changed to set the role on
> > the terminal.
> > 
> > The above example rule utilizes a role attribute, which doesn't exist.
> > In the absence of role attributes, role dominance can be used, but its
> > unclear if the dominance code works, since no one uses it.
> > 
> > Genhomedircon may need to be updated.
> > 
> > Tools such as audit2allow will need more audit2why-like support and
> > policy info to fix RBAC denials (a general constraints usability issue).
> > 
> > Comments?
> > 
> As has been stated before, I am not interested in separation of the
> homedir based on Role, since this will prevent shared homedirs on
> machines where the same user has different roles.  Also makes testing of
> homedir roles difficult since changing a role requires a full relabel of
> the homedir.  Labeling of the /root directory should be static and not
> related to user or role, because domains often want read/write access to
> the root directory and dontauditing this becomes complex if this changes
> based on semanage rules.
> 
> service XYZ start in /root will almost always generate a search of the
> /root directory.
> 
> Currently Fedora labeling on the homedir is user_home_t or
> user_mozilla_home_t, Ie everything user_* So switching this to
> mozilla_home_t or home_t would be fine.

As before, I don't believe any of this would force anyone to separate
files based on role; it would be driven by policy configuration and
using object_r pervasively would continue to work fine.  It would just
offer the ability to provide such separation based on role if so
configured, and it would drop the use of derived types to achieve such
separation.

If you aren't going to separate files based on role though, you may want
to think about how to protect roles against influence by other roles so
that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
into dotfiles.  DAC will help you with user-based separation (somewhat),
but there is still the case where you have a user who is authorized for
staff_r and sysadm_r who logs in initially in staff_r and later switches
to sysadm_r.  There you have consider the potential of a flawed or
malicious program run while in staff_r trying to inject commands to be
run in sysadm_r, all running under the same user identity.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Christopher J. PeBenito]

On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > Next we will be doing an experiment attempting to use the SELinux RBAC
> > functionality to separate users instead of SELinux TE.  What this means
> > is that the role field will start being used more substantially than it
> > currently is.  In a nutshell, this means that all user objects will have
> > the user's role rather than object_r.  Then the separate types will be
> > collapsed into one type where possible.  This will result in per-role
> > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > (mozilla_t).
> > 
> > So for example, all of the home directory types will be collapsed into
> > home_t and home_dir_t.  This results in /root having the context
> > root:sysadm_r:home_dir_t.
> > 
> > My current idea for RBAC rules is to group object classes in RBAC
> > constraints similar to the current MLS constraints (e.g. file classes
> > together, network classes together).  The basic RBAC rule will be:
> > 
> > constrain { dir file ... } { getattr read write .... }
> > 	r1 == r2
> > 	or r1 == system_r
> > 	or r2 == object_r
> > 	or r1 == rbac_subj_role_file_exempt
> > 	or r2 == rbac_obj_role_file_exempt
> 
> Do we think there will ever be another "exempt" object role other than
> object_r?  What benefit would it provide?

Perhaps if someone wants an exempt only on a specific set of object
classes, like on files or on process?  I don't have a good example, so I
could just as well drop it.

> > 	or t1 == rbac_subj_type_file_exempt
> > 	or t2 == rbac_obj_type_file_exempt;
> > 
> > Is this too coarse?  Do we want to break it down into read and write
> > rather than just exempt?
> 
> Seems reasonable as a starting point - offhand I don't see the use case
> for splitting it into read/write cases.

I didn't have a use case on this one either.

> > Unfortunately this necessitates some kernel and userspace changes:
[...]
> > Login programs and newrole will have to be changed to set the role on
> > the terminal.
> 
> Not if we get the security_compute_sid logic right and introduce
> role_change rules analogous to the type_change rules.  Then the existing
> security_compute_relabel() calls by login programs and newrole will
> return the desired context.

I just assumed that userspace changes would be preferred since there
doesn't necessarily have to be any logic in figuring out what role to
set on the object, the app would just set whatever role was logging in
(or the role being changed to, in the case of newrole).

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Tue, 2008-04-29 at 15:34 -0400, Christopher J. PeBenito wrote:
> On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> > On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > > Next we will be doing an experiment attempting to use the SELinux RBAC
> > > functionality to separate users instead of SELinux TE.  What this means
> > > is that the role field will start being used more substantially than it
> > > currently is.  In a nutshell, this means that all user objects will have
> > > the user's role rather than object_r.  Then the separate types will be
> > > collapsed into one type where possible.  This will result in per-role
> > > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > > (mozilla_t).
> > > 
> > > So for example, all of the home directory types will be collapsed into
> > > home_t and home_dir_t.  This results in /root having the context
> > > root:sysadm_r:home_dir_t.
> > > 
> > > My current idea for RBAC rules is to group object classes in RBAC
> > > constraints similar to the current MLS constraints (e.g. file classes
> > > together, network classes together).  The basic RBAC rule will be:
> > > 
> > > constrain { dir file ... } { getattr read write .... }
> > > 	r1 == r2
> > > 	or r1 == system_r
> > > 	or r2 == object_r
> > > 	or r1 == rbac_subj_role_file_exempt
> > > 	or r2 == rbac_obj_role_file_exempt
> > 
> > Do we think there will ever be another "exempt" object role other than
> > object_r?  What benefit would it provide?
> 
> Perhaps if someone wants an exempt only on a specific set of object
> classes, like on files or on process?  I don't have a good example, so I
> could just as well drop it.
> 
> > > 	or t1 == rbac_subj_type_file_exempt
> > > 	or t2 == rbac_obj_type_file_exempt;
> > > 
> > > Is this too coarse?  Do we want to break it down into read and write
> > > rather than just exempt?
> > 
> > Seems reasonable as a starting point - offhand I don't see the use case
> > for splitting it into read/write cases.
> 
> I didn't have a use case on this one either.
> 
> > > Unfortunately this necessitates some kernel and userspace changes:
> [...]
> > > Login programs and newrole will have to be changed to set the role on
> > > the terminal.
> > 
> > Not if we get the security_compute_sid logic right and introduce
> > role_change rules analogous to the type_change rules.  Then the existing
> > security_compute_relabel() calls by login programs and newrole will
> > return the desired context.
> 
> I just assumed that userspace changes would be preferred since there
> doesn't necessarily have to be any logic in figuring out what role to
> set on the object, the app would just set whatever role was logging in
> (or the role being changed to, in the case of newrole).

So under that approach, would userspace cease using
security_compute_relabel() altogether?  As its only real use today is to
obtain a derived type, and you are eliminating those.

I suppose that would be simpler.

This isn't directly related, but we'd also like to obsolete
security_compute_user() and have userspace directly determine the set of
legal contexts for get_ordered_context_list and friends.  Possibly with
some additional selinuxfs information, or via another config file that
gets generated from policy.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Christopher J. PeBenito wrote:
>>> For those interested all of the user roles have been separated out into
>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
>>> This should enable interested users to add and remove roles more easily.
>>> Each of the user roles has a module named after it (e.g., sysadm module
>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
>>> possible to use "user" as a module name since it is a policy keyword.
>>>
>>> Next we will be doing an experiment attempting to use the SELinux RBAC
>>> functionality to separate users instead of SELinux TE.  What this means
>>> is that the role field will start being used more substantially than it
>>> currently is.  In a nutshell, this means that all user objects will have
>>> the user's role rather than object_r.  Then the separate types will be
>>> collapsed into one type where possible.  This will result in per-role
>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
>>> (mozilla_t).
>>>
>>> So for example, all of the home directory types will be collapsed into
>>> home_t and home_dir_t.  This results in /root having the context
>>> root:sysadm_r:home_dir_t.
>>>
>>> My current idea for RBAC rules is to group object classes in RBAC
>>> constraints similar to the current MLS constraints (e.g. file classes
>>> together, network classes together).  The basic RBAC rule will be:
>>>
>>> constrain { dir file ... } { getattr read write .... }
>>> 	r1 == r2
>>> 	or r1 == system_r
>>> 	or r2 == object_r
>>> 	or r1 == rbac_subj_role_file_exempt
>>> 	or r2 == rbac_obj_role_file_exempt
>>> 	or t1 == rbac_subj_type_file_exempt
>>> 	or t2 == rbac_obj_type_file_exempt;
>>>
>>> Is this too coarse?  Do we want to break it down into read and write
>>> rather than just exempt?
>>>
>>> Unfortunately this necessitates some kernel and userspace changes:
>>>
>>> Roles aren't respected on objects in the kernel.  So if you create a
>>> file in a directory that has the role staff_r, the file will have an
>>> object_r role instead of staff_r.
>>>
>>> Login programs and newrole will have to be changed to set the role on
>>> the terminal.
>>>
>>> The above example rule utilizes a role attribute, which doesn't exist.
>>> In the absence of role attributes, role dominance can be used, but its
>>> unclear if the dominance code works, since no one uses it.
>>>
>>> Genhomedircon may need to be updated.
>>>
>>> Tools such as audit2allow will need more audit2why-like support and
>>> policy info to fix RBAC denials (a general constraints usability issue).
>>>
>>> Comments?
>>>
>> As has been stated before, I am not interested in separation of the
>> homedir based on Role, since this will prevent shared homedirs on
>> machines where the same user has different roles.  Also makes testing of
>> homedir roles difficult since changing a role requires a full relabel of
>> the homedir.  Labeling of the /root directory should be static and not
>> related to user or role, because domains often want read/write access to
>> the root directory and dontauditing this becomes complex if this changes
>> based on semanage rules.
>>
>> service XYZ start in /root will almost always generate a search of the
>> /root directory.
>>
>> Currently Fedora labeling on the homedir is user_home_t or
>> user_mozilla_home_t, Ie everything user_* So switching this to
>> mozilla_home_t or home_t would be fine.
> 
> As before, I don't believe any of this would force anyone to separate
> files based on role; it would be driven by policy configuration and
> using object_r pervasively would continue to work fine.  It would just
> offer the ability to provide such separation based on role if so
> configured, and it would drop the use of derived types to achieve such
> separation.
> 
> If you aren't going to separate files based on role though, you may want
> to think about how to protect roles against influence by other roles so
> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
> into dotfiles.  DAC will help you with user-based separation (somewhat),
> but there is still the case where you have a user who is authorized for
> staff_r and sysadm_r who logs in initially in staff_r and later switches
> to sysadm_r.  There you have consider the potential of a flawed or
> malicious program run while in staff_r trying to inject commands to be
> run in sysadm_r, all running under the same user identity.
> 

I label /root admin_home_t and don't allow any confined role to write to
it.  I have sysadm_r but have written before that I think it is a waste
of time, and prefer to just use unconfined_r.

My view of the world is that you have a "login" role and you have an
"admin" role.  On my machine this is staff_r and unconfined_r, respectively.

If I want to run a confined role say webadm_r, I would not allow
webadm_r to touch any files in /root, so I don't see that I need
protection.  Similarly webadm_r can not touch entries in the Homedir so
it can not attack other roles.  If you need to create an admin role
which administrates more then one confined domain, then you would
generate a new admin role or enhance an existing admin role.  For
example if you want to allow the webadm_r:webadm_t to be able to admin
mysql,  you simply create a policy module with

mysql_admin(webadm_t, webadm_r, { webadm_devpts_t webadm_tty_device_t })

Or you create a brand new admin module with

policy_module(myadm, 1.0)

userdom_base_user_template(myadm)
allow myadm_t self:capability { dac_override dac_read_search kill
sys_ptrace sys_nice };

apache_admin(myadm_t, myadm_r,  { myadm_devpts_t myadm_tty_device_t })
mysql_admin(myadm_t, myadm_r,  { myadm_devpts_t myadm_tty_device_t })

gen_require(`
        type staff_t;
')
allow staff_t myadm_t:process transition;
allow myadm_t staff_t:dir getattr;


We need to keep it this simple, or only Consultants will ever be able to
use this stuff.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgYY3wACgkQrlYvE4MpobMekQCcDcsUwL2YM4t/MzkH07qDlRbS
gdcAoJ2GbnSCqrioDU5LXRB6Amvoyl06
=tyy7
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Christopher J. PeBenito wrote:
> >>> For those interested all of the user roles have been separated out into
> >>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
> >>> This should enable interested users to add and remove roles more easily.
> >>> Each of the user roles has a module named after it (e.g., sysadm module
> >>> for sysadm_r), except user_r, which has a name unprivuser, since its not
> >>> possible to use "user" as a module name since it is a policy keyword.
> >>>
> >>> Next we will be doing an experiment attempting to use the SELinux RBAC
> >>> functionality to separate users instead of SELinux TE.  What this means
> >>> is that the role field will start being used more substantially than it
> >>> currently is.  In a nutshell, this means that all user objects will have
> >>> the user's role rather than object_r.  Then the separate types will be
> >>> collapsed into one type where possible.  This will result in per-role
> >>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> >>> (mozilla_t).
> >>>
> >>> So for example, all of the home directory types will be collapsed into
> >>> home_t and home_dir_t.  This results in /root having the context
> >>> root:sysadm_r:home_dir_t.
> >>>
> >>> My current idea for RBAC rules is to group object classes in RBAC
> >>> constraints similar to the current MLS constraints (e.g. file classes
> >>> together, network classes together).  The basic RBAC rule will be:
> >>>
> >>> constrain { dir file ... } { getattr read write .... }
> >>> 	r1 == r2
> >>> 	or r1 == system_r
> >>> 	or r2 == object_r
> >>> 	or r1 == rbac_subj_role_file_exempt
> >>> 	or r2 == rbac_obj_role_file_exempt
> >>> 	or t1 == rbac_subj_type_file_exempt
> >>> 	or t2 == rbac_obj_type_file_exempt;
> >>>
> >>> Is this too coarse?  Do we want to break it down into read and write
> >>> rather than just exempt?
> >>>
> >>> Unfortunately this necessitates some kernel and userspace changes:
> >>>
> >>> Roles aren't respected on objects in the kernel.  So if you create a
> >>> file in a directory that has the role staff_r, the file will have an
> >>> object_r role instead of staff_r.
> >>>
> >>> Login programs and newrole will have to be changed to set the role on
> >>> the terminal.
> >>>
> >>> The above example rule utilizes a role attribute, which doesn't exist.
> >>> In the absence of role attributes, role dominance can be used, but its
> >>> unclear if the dominance code works, since no one uses it.
> >>>
> >>> Genhomedircon may need to be updated.
> >>>
> >>> Tools such as audit2allow will need more audit2why-like support and
> >>> policy info to fix RBAC denials (a general constraints usability issue).
> >>>
> >>> Comments?
> >>>
> >> As has been stated before, I am not interested in separation of the
> >> homedir based on Role, since this will prevent shared homedirs on
> >> machines where the same user has different roles.  Also makes testing of
> >> homedir roles difficult since changing a role requires a full relabel of
> >> the homedir.  Labeling of the /root directory should be static and not
> >> related to user or role, because domains often want read/write access to
> >> the root directory and dontauditing this becomes complex if this changes
> >> based on semanage rules.
> >>
> >> service XYZ start in /root will almost always generate a search of the
> >> /root directory.
> >>
> >> Currently Fedora labeling on the homedir is user_home_t or
> >> user_mozilla_home_t, Ie everything user_* So switching this to
> >> mozilla_home_t or home_t would be fine.
> > 
> > As before, I don't believe any of this would force anyone to separate
> > files based on role; it would be driven by policy configuration and
> > using object_r pervasively would continue to work fine.  It would just
> > offer the ability to provide such separation based on role if so
> > configured, and it would drop the use of derived types to achieve such
> > separation.
> > 
> > If you aren't going to separate files based on role though, you may want
> > to think about how to protect roles against influence by other roles so
> > that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
> > into dotfiles.  DAC will help you with user-based separation (somewhat),
> > but there is still the case where you have a user who is authorized for
> > staff_r and sysadm_r who logs in initially in staff_r and later switches
> > to sysadm_r.  There you have consider the potential of a flawed or
> > malicious program run while in staff_r trying to inject commands to be
> > run in sysadm_r, all running under the same user identity.
> > 
> 
> I label /root admin_home_t and don't allow any confined role to write to
> it.  I have sysadm_r but have written before that I think it is a waste
> of time, and prefer to just use unconfined_r.
> 
> My view of the world is that you have a "login" role and you have an
> "admin" role.  On my machine this is staff_r and unconfined_r, respectively.

Right, but whether unconfined_r or sysadm_r, the question is how to
protect the more-privileged role (unconfined_r in your case) from
influence by the less-privileged login role (staff_r) when they both
operate under the same DAC uid and thus share the same set of dotfiles.
The per-role types or roles on home directory files are one mechanism
for achieving that protection.  Another way would be to polyinstantiate
the home directories by role.  Another way that relies on DAC-only would
be to create a dedicated (pseudo) user account for each role with its
own home directory and "safe" set of dotfiles and switch to that account
when switching roles.

> If I want to run a confined role say webadm_r, I would not allow
> webadm_r to touch any files in /root, so I don't see that I need
> protection.  Similarly webadm_r can not touch entries in the Homedir so
> it can not attack other roles.  If you need to create an admin role
> which administrates more then one confined domain, then you would
> generate a new admin role or enhance an existing admin role.  For
> example if you want to allow the webadm_r:webadm_t to be able to admin
> mysql,  you simply create a policy module with
> 

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
> If I want to run a confined role say webadm_r, I would not allow
> webadm_r to touch any files in /root, so I don't see that I need
> protection.  Similarly webadm_r can not touch entries in the Homedir so
> it can not attack other roles.  If you need to create an admin role
> which administrates more then one confined domain, then you would
> generate a new admin role or enhance an existing admin role.  For
> example if you want to allow the webadm_r:webadm_t to be able to admin
> mysql,  you simply create a policy module with
> 
> mysql_admin(webadm_t, webadm_r, { webadm_devpts_t webadm_tty_device_t })

Just noticed this - is the plan to retain the derived types for
ttys/ptys, or are those also going away as part of this elimination of
per-role types?

If you retain the derived types on ttys/ptys, then I'm not sure how you
eliminate the per-role program domains, as one of the reasons for them
to exist is to preserve isolation of the ttys/ptys.

> Or you create a brand new admin module with
> 
> policy_module(myadm, 1.0)
> 
> userdom_base_user_template(myadm)
> allow myadm_t self:capability { dac_override dac_read_search kill
> sys_ptrace sys_nice };
> 
> apache_admin(myadm_t, myadm_r,  { myadm_devpts_t myadm_tty_device_t })
> mysql_admin(myadm_t, myadm_r,  { myadm_devpts_t myadm_tty_device_t })
> 
> gen_require(`
>         type staff_t;
> ')
> allow staff_t myadm_t:process transition;
> allow myadm_t staff_t:dir getattr;
> 
> 
> We need to keep it this simple, or only Consultants will ever be able to
> use this stuff.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkgYY3wACgkQrlYvE4MpobMekQCcDcsUwL2YM4t/MzkH07qDlRbS
> gdcAoJ2GbnSCqrioDU5LXRB6Amvoyl06
> =tyy7
> -----END PGP SIGNATURE-----
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Christopher J. PeBenito]

On Tue, 2008-04-29 at 15:48 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-29 at 15:34 -0400, Christopher J. PeBenito wrote:
> > On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> > > On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > > > Next we will be doing an experiment attempting to use the SELinux RBAC
> > > > functionality to separate users instead of SELinux TE.  What this means
> > > > is that the role field will start being used more substantially than it
> > > > currently is.  In a nutshell, this means that all user objects will have
> > > > the user's role rather than object_r.  Then the separate types will be
> > > > collapsed into one type where possible.  This will result in per-role
> > > > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > > > (mozilla_t).
[...]
> > > > Unfortunately this necessitates some kernel and userspace changes:
> > [...]
> > > > Login programs and newrole will have to be changed to set the role on
> > > > the terminal.
> > > 
> > > Not if we get the security_compute_sid logic right and introduce
> > > role_change rules analogous to the type_change rules.  Then the existing
> > > security_compute_relabel() calls by login programs and newrole will
> > > return the desired context.
> > 
> > I just assumed that userspace changes would be preferred since there
> > doesn't necessarily have to be any logic in figuring out what role to
> > set on the object, the app would just set whatever role was logging in
> > (or the role being changed to, in the case of newrole).
> 
> So under that approach, would userspace cease using
> security_compute_relabel() altogether?  As its only real use today is to
> obtain a derived type, and you are eliminating those.
> 
> I suppose that would be simpler.

I didn't think of removing security_compute_relabel().  I figured it
would stick around for compatibility.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Wed, 2008-04-30 at 09:48 -0400, Christopher J. PeBenito wrote:
> On Tue, 2008-04-29 at 15:48 -0400, Stephen Smalley wrote:
> > On Tue, 2008-04-29 at 15:34 -0400, Christopher J. PeBenito wrote:
> > > On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> > > > On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > > > > Next we will be doing an experiment attempting to use the SELinux RBAC
> > > > > functionality to separate users instead of SELinux TE.  What this means
> > > > > is that the role field will start being used more substantially than it
> > > > > currently is.  In a nutshell, this means that all user objects will have
> > > > > the user's role rather than object_r.  Then the separate types will be
> > > > > collapsed into one type where possible.  This will result in per-role
> > > > > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > > > > (mozilla_t).
> [...]
> > > > > Unfortunately this necessitates some kernel and userspace changes:
> > > [...]
> > > > > Login programs and newrole will have to be changed to set the role on
> > > > > the terminal.
> > > > 
> > > > Not if we get the security_compute_sid logic right and introduce
> > > > role_change rules analogous to the type_change rules.  Then the existing
> > > > security_compute_relabel() calls by login programs and newrole will
> > > > return the desired context.
> > > 
> > > I just assumed that userspace changes would be preferred since there
> > > doesn't necessarily have to be any logic in figuring out what role to
> > > set on the object, the app would just set whatever role was logging in
> > > (or the role being changed to, in the case of newrole).
> > 
> > So under that approach, would userspace cease using
> > security_compute_relabel() altogether?  As its only real use today is to
> > obtain a derived type, and you are eliminating those.
> > 
> > I suppose that would be simpler.
> 
> I didn't think of removing security_compute_relabel().  I figured it
> would stick around for compatibility.

I think we already have to update the userland and policy in lock-step
if we are going to directly change the login programs and newrole to
directly set roles on the tty, as that will otherwise break.  Or do you
intend to provide some way for userspace to detect that the new role
support is present in policy (and in the kernel, for that matter)?

That btw might be an advantage to hiding the role determination behind
security_compute_relabel(), such that userspace doesn't have to change
at all and can seamlessly handle the transition from the old approach to
the new one.

Another issue btw is that when we start using roles on objects, then the
role-type relation has to be expanded to encompass all of the types that
might be assigned to files created by processes in that role rather than
only dealing with domains.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Christopher J. PeBenito]

On Wed, 2008-04-30 at 10:05 -0400, Stephen Smalley wrote:
> On Wed, 2008-04-30 at 09:48 -0400, Christopher J. PeBenito wrote:
> > On Tue, 2008-04-29 at 15:48 -0400, Stephen Smalley wrote:
> > > On Tue, 2008-04-29 at 15:34 -0400, Christopher J. PeBenito wrote:
> > > > On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> > > > > On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > > > > > Next we will be doing an experiment attempting to use the SELinux RBAC
> > > > > > functionality to separate users instead of SELinux TE.  What this means
> > > > > > is that the role field will start being used more substantially than it
> > > > > > currently is.  In a nutshell, this means that all user objects will have
> > > > > > the user's role rather than object_r.  Then the separate types will be
> > > > > > collapsed into one type where possible.  This will result in per-role
> > > > > > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > > > > > (mozilla_t).
> > [...]
> > > > > > Unfortunately this necessitates some kernel and userspace changes:
> > > > [...]
> > > > > > Login programs and newrole will have to be changed to set the role on
> > > > > > the terminal.
> > > > > 
> > > > > Not if we get the security_compute_sid logic right and introduce
> > > > > role_change rules analogous to the type_change rules.  Then the existing
> > > > > security_compute_relabel() calls by login programs and newrole will
> > > > > return the desired context.
> > > > 
> > > > I just assumed that userspace changes would be preferred since there
> > > > doesn't necessarily have to be any logic in figuring out what role to
> > > > set on the object, the app would just set whatever role was logging in
> > > > (or the role being changed to, in the case of newrole).
> > > 
> > > So under that approach, would userspace cease using
> > > security_compute_relabel() altogether?  As its only real use today is to
> > > obtain a derived type, and you are eliminating those.
> > > 
> > > I suppose that would be simpler.
> > 
> > I didn't think of removing security_compute_relabel().  I figured it
> > would stick around for compatibility.
> 
> I think we already have to update the userland and policy in lock-step
> if we are going to directly change the login programs and newrole to
> directly set roles on the tty, as that will otherwise break.  Or do you
> intend to provide some way for userspace to detect that the new role
> support is present in policy (and in the kernel, for that matter)?
> 
> That btw might be an advantage to hiding the role determination behind
> security_compute_relabel(), such that userspace doesn't have to change
> at all and can seamlessly handle the transition from the old approach to
> the new one.

A good point.  We could probably add in the user_transition support in
at the same time as role_change and role_transition w/object classes.

> Another issue btw is that when we start using roles on objects, then the
> role-type relation has to be expanded to encompass all of the types that
> might be assigned to files created by processes in that role rather than
> only dealing with domains.

Right.  My current thinking is that it would be types that were
previously per-role, since outside of home directories and /tmp
directories, everything else would be object_r.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Christopher J. PeBenito]

On Wed, 2008-04-30 at 08:57 -0400, Stephen Smalley wrote:
> On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
> > If I want to run a confined role say webadm_r, I would not allow
> > webadm_r to touch any files in /root, so I don't see that I need
> > protection.  Similarly webadm_r can not touch entries in the Homedir so
> > it can not attack other roles.  If you need to create an admin role
> > which administrates more then one confined domain, then you would
> > generate a new admin role or enhance an existing admin role.  For
> > example if you want to allow the webadm_r:webadm_t to be able to admin
> > mysql,  you simply create a policy module with
> > 
> > mysql_admin(webadm_t, webadm_r, { webadm_devpts_t webadm_tty_device_t })
> 
> Just noticed this - is the plan to retain the derived types for
> ttys/ptys, or are those also going away as part of this elimination of
> per-role types?
> 
> If you retain the derived types on ttys/ptys, then I'm not sure how you
> eliminate the per-role program domains, as one of the reasons for them
> to exist is to preserve isolation of the ttys/ptys.

I plan on removing derived-typed terminals.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Christopher J. PeBenito wrote:
>>>>> For those interested all of the user roles have been separated out into
>>>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
>>>>> This should enable interested users to add and remove roles more easily.
>>>>> Each of the user roles has a module named after it (e.g., sysadm module
>>>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
>>>>> possible to use "user" as a module name since it is a policy keyword.
>>>>>
>>>>> Next we will be doing an experiment attempting to use the SELinux RBAC
>>>>> functionality to separate users instead of SELinux TE.  What this means
>>>>> is that the role field will start being used more substantially than it
>>>>> currently is.  In a nutshell, this means that all user objects will have
>>>>> the user's role rather than object_r.  Then the separate types will be
>>>>> collapsed into one type where possible.  This will result in per-role
>>>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
>>>>> (mozilla_t).
>>>>>
>>>>> So for example, all of the home directory types will be collapsed into
>>>>> home_t and home_dir_t.  This results in /root having the context
>>>>> root:sysadm_r:home_dir_t.
>>>>>
>>>>> My current idea for RBAC rules is to group object classes in RBAC
>>>>> constraints similar to the current MLS constraints (e.g. file classes
>>>>> together, network classes together).  The basic RBAC rule will be:
>>>>>
>>>>> constrain { dir file ... } { getattr read write .... }
>>>>> 	r1 == r2
>>>>> 	or r1 == system_r
>>>>> 	or r2 == object_r
>>>>> 	or r1 == rbac_subj_role_file_exempt
>>>>> 	or r2 == rbac_obj_role_file_exempt
>>>>> 	or t1 == rbac_subj_type_file_exempt
>>>>> 	or t2 == rbac_obj_type_file_exempt;
>>>>>
>>>>> Is this too coarse?  Do we want to break it down into read and write
>>>>> rather than just exempt?
>>>>>
>>>>> Unfortunately this necessitates some kernel and userspace changes:
>>>>>
>>>>> Roles aren't respected on objects in the kernel.  So if you create a
>>>>> file in a directory that has the role staff_r, the file will have an
>>>>> object_r role instead of staff_r.
>>>>>
>>>>> Login programs and newrole will have to be changed to set the role on
>>>>> the terminal.
>>>>>
>>>>> The above example rule utilizes a role attribute, which doesn't exist.
>>>>> In the absence of role attributes, role dominance can be used, but its
>>>>> unclear if the dominance code works, since no one uses it.
>>>>>
>>>>> Genhomedircon may need to be updated.
>>>>>
>>>>> Tools such as audit2allow will need more audit2why-like support and
>>>>> policy info to fix RBAC denials (a general constraints usability issue).
>>>>>
>>>>> Comments?
>>>>>
>>>> As has been stated before, I am not interested in separation of the
>>>> homedir based on Role, since this will prevent shared homedirs on
>>>> machines where the same user has different roles.  Also makes testing of
>>>> homedir roles difficult since changing a role requires a full relabel of
>>>> the homedir.  Labeling of the /root directory should be static and not
>>>> related to user or role, because domains often want read/write access to
>>>> the root directory and dontauditing this becomes complex if this changes
>>>> based on semanage rules.
>>>>
>>>> service XYZ start in /root will almost always generate a search of the
>>>> /root directory.
>>>>
>>>> Currently Fedora labeling on the homedir is user_home_t or
>>>> user_mozilla_home_t, Ie everything user_* So switching this to
>>>> mozilla_home_t or home_t would be fine.
>>> As before, I don't believe any of this would force anyone to separate
>>> files based on role; it would be driven by policy configuration and
>>> using object_r pervasively would continue to work fine.  It would just
>>> offer the ability to provide such separation based on role if so
>>> configured, and it would drop the use of derived types to achieve such
>>> separation.
>>>
>>> If you aren't going to separate files based on role though, you may want
>>> to think about how to protect roles against influence by other roles so
>>> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
>>> into dotfiles.  DAC will help you with user-based separation (somewhat),
>>> but there is still the case where you have a user who is authorized for
>>> staff_r and sysadm_r who logs in initially in staff_r and later switches
>>> to sysadm_r.  There you have consider the potential of a flawed or
>>> malicious program run while in staff_r trying to inject commands to be
>>> run in sysadm_r, all running under the same user identity.
>>>
>> I label /root admin_home_t and don't allow any confined role to write to
>> it.  I have sysadm_r but have written before that I think it is a waste
>> of time, and prefer to just use unconfined_r.
>>
>> My view of the world is that you have a "login" role and you have an
>> "admin" role.  On my machine this is staff_r and unconfined_r, respectively.
> 
> Right, but whether unconfined_r or sysadm_r, the question is how to
> protect the more-privileged role (unconfined_r in your case) from
> influence by the less-privileged login role (staff_r) when they both
> operate under the same DAC uid and thus share the same set of dotfiles.
> The per-role types or roles on home directory files are one mechanism
> for achieving that protection.  Another way would be to polyinstantiate
> the home directories by role.  Another way that relies on DAC-only would
> be to create a dedicated (pseudo) user account for each role with its
> own home directory and "safe" set of dotfiles and switch to that account
> when switching roles.
> 
But you are assuming the UID does not change.   Since I look at the
world as Two Roles,  One Role when I am normal user and another role
when I am root.   I don't have this problem.  I don't want users using
newrole,  I want them to use sudo.  So unconfined_t or webadm_t when
UID==root, staff_t when UID=dwalsh.  newrole is just a complexity that
most users do not understand.    Since a confined application can not
read by default the directories of the user, the user will not be able
to effect the confined domain.

>> If I want to run a confined role say webadm_r, I would not allow
>> webadm_r to touch any files in /root, so I don't see that I need
>> protection.  Similarly webadm_r can not touch entries in the Homedir so
>> it can not attack other roles.  If you need to create an admin role
>> which administrates more then one confined domain, then you would
>> generate a new admin role or enhance an existing admin role.  For
>> example if you want to allow the webadm_r:webadm_t to be able to admin
>> mysql,  you simply create a policy module with
>>
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgYkZMACgkQrlYvE4MpobMrEACfS7ahpKcJAaloLlHknRryJ5h9
w24AoLzWVBkSRoY9o8c6IxN8sjLITRbz
=Jo3o
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Wed, 2008-04-30 at 11:34 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Stephen Smalley wrote:
> >>> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Christopher J. PeBenito wrote:
> >>>>> For those interested all of the user roles have been separated out into
> >>>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
> >>>>> This should enable interested users to add and remove roles more easily.
> >>>>> Each of the user roles has a module named after it (e.g., sysadm module
> >>>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
> >>>>> possible to use "user" as a module name since it is a policy keyword.
> >>>>>
> >>>>> Next we will be doing an experiment attempting to use the SELinux RBAC
> >>>>> functionality to separate users instead of SELinux TE.  What this means
> >>>>> is that the role field will start being used more substantially than it
> >>>>> currently is.  In a nutshell, this means that all user objects will have
> >>>>> the user's role rather than object_r.  Then the separate types will be
> >>>>> collapsed into one type where possible.  This will result in per-role
> >>>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> >>>>> (mozilla_t).
> >>>>>
> >>>>> So for example, all of the home directory types will be collapsed into
> >>>>> home_t and home_dir_t.  This results in /root having the context
> >>>>> root:sysadm_r:home_dir_t.
> >>>>>
> >>>>> My current idea for RBAC rules is to group object classes in RBAC
> >>>>> constraints similar to the current MLS constraints (e.g. file classes
> >>>>> together, network classes together).  The basic RBAC rule will be:
> >>>>>
> >>>>> constrain { dir file ... } { getattr read write .... }
> >>>>> 	r1 == r2
> >>>>> 	or r1 == system_r
> >>>>> 	or r2 == object_r
> >>>>> 	or r1 == rbac_subj_role_file_exempt
> >>>>> 	or r2 == rbac_obj_role_file_exempt
> >>>>> 	or t1 == rbac_subj_type_file_exempt
> >>>>> 	or t2 == rbac_obj_type_file_exempt;
> >>>>>
> >>>>> Is this too coarse?  Do we want to break it down into read and write
> >>>>> rather than just exempt?
> >>>>>
> >>>>> Unfortunately this necessitates some kernel and userspace changes:
> >>>>>
> >>>>> Roles aren't respected on objects in the kernel.  So if you create a
> >>>>> file in a directory that has the role staff_r, the file will have an
> >>>>> object_r role instead of staff_r.
> >>>>>
> >>>>> Login programs and newrole will have to be changed to set the role on
> >>>>> the terminal.
> >>>>>
> >>>>> The above example rule utilizes a role attribute, which doesn't exist.
> >>>>> In the absence of role attributes, role dominance can be used, but its
> >>>>> unclear if the dominance code works, since no one uses it.
> >>>>>
> >>>>> Genhomedircon may need to be updated.
> >>>>>
> >>>>> Tools such as audit2allow will need more audit2why-like support and
> >>>>> policy info to fix RBAC denials (a general constraints usability issue).
> >>>>>
> >>>>> Comments?
> >>>>>
> >>>> As has been stated before, I am not interested in separation of the
> >>>> homedir based on Role, since this will prevent shared homedirs on
> >>>> machines where the same user has different roles.  Also makes testing of
> >>>> homedir roles difficult since changing a role requires a full relabel of
> >>>> the homedir.  Labeling of the /root directory should be static and not
> >>>> related to user or role, because domains often want read/write access to
> >>>> the root directory and dontauditing this becomes complex if this changes
> >>>> based on semanage rules.
> >>>>
> >>>> service XYZ start in /root will almost always generate a search of the
> >>>> /root directory.
> >>>>
> >>>> Currently Fedora labeling on the homedir is user_home_t or
> >>>> user_mozilla_home_t, Ie everything user_* So switching this to
> >>>> mozilla_home_t or home_t would be fine.
> >>> As before, I don't believe any of this would force anyone to separate
> >>> files based on role; it would be driven by policy configuration and
> >>> using object_r pervasively would continue to work fine.  It would just
> >>> offer the ability to provide such separation based on role if so
> >>> configured, and it would drop the use of derived types to achieve such
> >>> separation.
> >>>
> >>> If you aren't going to separate files based on role though, you may want
> >>> to think about how to protect roles against influence by other roles so
> >>> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
> >>> into dotfiles.  DAC will help you with user-based separation (somewhat),
> >>> but there is still the case where you have a user who is authorized for
> >>> staff_r and sysadm_r who logs in initially in staff_r and later switches
> >>> to sysadm_r.  There you have consider the potential of a flawed or
> >>> malicious program run while in staff_r trying to inject commands to be
> >>> run in sysadm_r, all running under the same user identity.
> >>>
> >> I label /root admin_home_t and don't allow any confined role to write to
> >> it.  I have sysadm_r but have written before that I think it is a waste
> >> of time, and prefer to just use unconfined_r.
> >>
> >> My view of the world is that you have a "login" role and you have an
> >> "admin" role.  On my machine this is staff_r and unconfined_r, respectively.
> > 
> > Right, but whether unconfined_r or sysadm_r, the question is how to
> > protect the more-privileged role (unconfined_r in your case) from
> > influence by the less-privileged login role (staff_r) when they both
> > operate under the same DAC uid and thus share the same set of dotfiles.
> > The per-role types or roles on home directory files are one mechanism
> > for achieving that protection.  Another way would be to polyinstantiate
> > the home directories by role.  Another way that relies on DAC-only would
> > be to create a dedicated (pseudo) user account for each role with its
> > own home directory and "safe" set of dotfiles and switch to that account
> > when switching roles.
> > 
> But you are assuming the UID does not change.   Since I look at the
> world as Two Roles,  One Role when I am normal user and another role
> when I am root.   I don't have this problem.  I don't want users using
> newrole,  I want them to use sudo.  So unconfined_t or webadm_t when
> UID==root, staff_t when UID=dwalsh.  newrole is just a complexity that
> most users do not understand.    Since a confined application can not
> read by default the directories of the user, the user will not be able
> to effect the confined domain.

That's essentially the last case (create a dedicated pseudo user account
for each role with its own home directory) simplified to two-roles-only.
But I think you'll eventually find two-roles-only to be too limiting
(and certainly not sufficient for RBAC for organizations).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Wed, 2008-04-30 at 11:34 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Stephen Smalley wrote:
>>>>> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Christopher J. PeBenito wrote:
>>>>>>> For those interested all of the user roles have been separated out into
>>>>>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
>>>>>>> This should enable interested users to add and remove roles more easily.
>>>>>>> Each of the user roles has a module named after it (e.g., sysadm module
>>>>>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
>>>>>>> possible to use "user" as a module name since it is a policy keyword.
>>>>>>>
>>>>>>> Next we will be doing an experiment attempting to use the SELinux RBAC
>>>>>>> functionality to separate users instead of SELinux TE.  What this means
>>>>>>> is that the role field will start being used more substantially than it
>>>>>>> currently is.  In a nutshell, this means that all user objects will have
>>>>>>> the user's role rather than object_r.  Then the separate types will be
>>>>>>> collapsed into one type where possible.  This will result in per-role
>>>>>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
>>>>>>> (mozilla_t).
>>>>>>>
>>>>>>> So for example, all of the home directory types will be collapsed into
>>>>>>> home_t and home_dir_t.  This results in /root having the context
>>>>>>> root:sysadm_r:home_dir_t.
>>>>>>>
>>>>>>> My current idea for RBAC rules is to group object classes in RBAC
>>>>>>> constraints similar to the current MLS constraints (e.g. file classes
>>>>>>> together, network classes together).  The basic RBAC rule will be:
>>>>>>>
>>>>>>> constrain { dir file ... } { getattr read write .... }
>>>>>>> 	r1 == r2
>>>>>>> 	or r1 == system_r
>>>>>>> 	or r2 == object_r
>>>>>>> 	or r1 == rbac_subj_role_file_exempt
>>>>>>> 	or r2 == rbac_obj_role_file_exempt
>>>>>>> 	or t1 == rbac_subj_type_file_exempt
>>>>>>> 	or t2 == rbac_obj_type_file_exempt;
>>>>>>>
>>>>>>> Is this too coarse?  Do we want to break it down into read and write
>>>>>>> rather than just exempt?
>>>>>>>
>>>>>>> Unfortunately this necessitates some kernel and userspace changes:
>>>>>>>
>>>>>>> Roles aren't respected on objects in the kernel.  So if you create a
>>>>>>> file in a directory that has the role staff_r, the file will have an
>>>>>>> object_r role instead of staff_r.
>>>>>>>
>>>>>>> Login programs and newrole will have to be changed to set the role on
>>>>>>> the terminal.
>>>>>>>
>>>>>>> The above example rule utilizes a role attribute, which doesn't exist.
>>>>>>> In the absence of role attributes, role dominance can be used, but its
>>>>>>> unclear if the dominance code works, since no one uses it.
>>>>>>>
>>>>>>> Genhomedircon may need to be updated.
>>>>>>>
>>>>>>> Tools such as audit2allow will need more audit2why-like support and
>>>>>>> policy info to fix RBAC denials (a general constraints usability issue).
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>> As has been stated before, I am not interested in separation of the
>>>>>> homedir based on Role, since this will prevent shared homedirs on
>>>>>> machines where the same user has different roles.  Also makes testing of
>>>>>> homedir roles difficult since changing a role requires a full relabel of
>>>>>> the homedir.  Labeling of the /root directory should be static and not
>>>>>> related to user or role, because domains often want read/write access to
>>>>>> the root directory and dontauditing this becomes complex if this changes
>>>>>> based on semanage rules.
>>>>>>
>>>>>> service XYZ start in /root will almost always generate a search of the
>>>>>> /root directory.
>>>>>>
>>>>>> Currently Fedora labeling on the homedir is user_home_t or
>>>>>> user_mozilla_home_t, Ie everything user_* So switching this to
>>>>>> mozilla_home_t or home_t would be fine.
>>>>> As before, I don't believe any of this would force anyone to separate
>>>>> files based on role; it would be driven by policy configuration and
>>>>> using object_r pervasively would continue to work fine.  It would just
>>>>> offer the ability to provide such separation based on role if so
>>>>> configured, and it would drop the use of derived types to achieve such
>>>>> separation.
>>>>>
>>>>> If you aren't going to separate files based on role though, you may want
>>>>> to think about how to protect roles against influence by other roles so
>>>>> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
>>>>> into dotfiles.  DAC will help you with user-based separation (somewhat),
>>>>> but there is still the case where you have a user who is authorized for
>>>>> staff_r and sysadm_r who logs in initially in staff_r and later switches
>>>>> to sysadm_r.  There you have consider the potential of a flawed or
>>>>> malicious program run while in staff_r trying to inject commands to be
>>>>> run in sysadm_r, all running under the same user identity.
>>>>>
>>>> I label /root admin_home_t and don't allow any confined role to write to
>>>> it.  I have sysadm_r but have written before that I think it is a waste
>>>> of time, and prefer to just use unconfined_r.
>>>>
>>>> My view of the world is that you have a "login" role and you have an
>>>> "admin" role.  On my machine this is staff_r and unconfined_r, respectively.
>>> Right, but whether unconfined_r or sysadm_r, the question is how to
>>> protect the more-privileged role (unconfined_r in your case) from
>>> influence by the less-privileged login role (staff_r) when they both
>>> operate under the same DAC uid and thus share the same set of dotfiles.
>>> The per-role types or roles on home directory files are one mechanism
>>> for achieving that protection.  Another way would be to polyinstantiate
>>> the home directories by role.  Another way that relies on DAC-only would
>>> be to create a dedicated (pseudo) user account for each role with its
>>> own home directory and "safe" set of dotfiles and switch to that account
>>> when switching roles.
>>>
>> But you are assuming the UID does not change.   Since I look at the
>> world as Two Roles,  One Role when I am normal user and another role
>> when I am root.   I don't have this problem.  I don't want users using
>> newrole,  I want them to use sudo.  So unconfined_t or webadm_t when
>> UID==root, staff_t when UID=dwalsh.  newrole is just a complexity that
>> most users do not understand.    Since a confined application can not
>> read by default the directories of the user, the user will not be able
>> to effect the confined domain.
> 
> That's essentially the last case (create a dedicated pseudo user account
> for each role with its own home directory) simplified to two-roles-only.
> But I think you'll eventually find two-roles-only to be too limiting
> (and certainly not sufficient for RBAC for organizations).
> 
But I would argue this is exactly why RBAC has never caught on, because
administrators and users do not think of themselves as Roles, they run
applications.  The only roles an administrator of Unix systems
understands and his login role and his admin role.  He is not going to
want to run commands to Switch Roles other than Sudo, which my mechanism
fully supports.  But imagining him switching roles while root or while a
user is way too complicated.

We have had a hard time convincing users to Leave SELinux on, now we
want to start adding new complexities, that have nothing to do with the
way they are used to working.  Seems to be a lot of work for little
benefit for the masses.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgYrdQACgkQrlYvE4MpobN+ZACfc0A69rtCeVrsDlGX16rL1hzF
A8sAn2Nyorh8gP8JyFpTKRlP0OrKhsTc
=0++3
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Wed, 2008-04-30 at 13:35 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Wed, 2008-04-30 at 11:34 -0400, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Stephen Smalley wrote:
> >>> On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Stephen Smalley wrote:
> >>>>> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
> >>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>> Hash: SHA1
> >>>>>>
> >>>>>> Christopher J. PeBenito wrote:
> >>>>>>> For those interested all of the user roles have been separated out into
> >>>>>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
> >>>>>>> This should enable interested users to add and remove roles more easily.
> >>>>>>> Each of the user roles has a module named after it (e.g., sysadm module
> >>>>>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
> >>>>>>> possible to use "user" as a module name since it is a policy keyword.
> >>>>>>>
> >>>>>>> Next we will be doing an experiment attempting to use the SELinux RBAC
> >>>>>>> functionality to separate users instead of SELinux TE.  What this means
> >>>>>>> is that the role field will start being used more substantially than it
> >>>>>>> currently is.  In a nutshell, this means that all user objects will have
> >>>>>>> the user's role rather than object_r.  Then the separate types will be
> >>>>>>> collapsed into one type where possible.  This will result in per-role
> >>>>>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> >>>>>>> (mozilla_t).
> >>>>>>>
> >>>>>>> So for example, all of the home directory types will be collapsed into
> >>>>>>> home_t and home_dir_t.  This results in /root having the context
> >>>>>>> root:sysadm_r:home_dir_t.
> >>>>>>>
> >>>>>>> My current idea for RBAC rules is to group object classes in RBAC
> >>>>>>> constraints similar to the current MLS constraints (e.g. file classes
> >>>>>>> together, network classes together).  The basic RBAC rule will be:
> >>>>>>>
> >>>>>>> constrain { dir file ... } { getattr read write .... }
> >>>>>>> 	r1 == r2
> >>>>>>> 	or r1 == system_r
> >>>>>>> 	or r2 == object_r
> >>>>>>> 	or r1 == rbac_subj_role_file_exempt
> >>>>>>> 	or r2 == rbac_obj_role_file_exempt
> >>>>>>> 	or t1 == rbac_subj_type_file_exempt
> >>>>>>> 	or t2 == rbac_obj_type_file_exempt;
> >>>>>>>
> >>>>>>> Is this too coarse?  Do we want to break it down into read and write
> >>>>>>> rather than just exempt?
> >>>>>>>
> >>>>>>> Unfortunately this necessitates some kernel and userspace changes:
> >>>>>>>
> >>>>>>> Roles aren't respected on objects in the kernel.  So if you create a
> >>>>>>> file in a directory that has the role staff_r, the file will have an
> >>>>>>> object_r role instead of staff_r.
> >>>>>>>
> >>>>>>> Login programs and newrole will have to be changed to set the role on
> >>>>>>> the terminal.
> >>>>>>>
> >>>>>>> The above example rule utilizes a role attribute, which doesn't exist.
> >>>>>>> In the absence of role attributes, role dominance can be used, but its
> >>>>>>> unclear if the dominance code works, since no one uses it.
> >>>>>>>
> >>>>>>> Genhomedircon may need to be updated.
> >>>>>>>
> >>>>>>> Tools such as audit2allow will need more audit2why-like support and
> >>>>>>> policy info to fix RBAC denials (a general constraints usability issue).
> >>>>>>>
> >>>>>>> Comments?
> >>>>>>>
> >>>>>> As has been stated before, I am not interested in separation of the
> >>>>>> homedir based on Role, since this will prevent shared homedirs on
> >>>>>> machines where the same user has different roles.  Also makes testing of
> >>>>>> homedir roles difficult since changing a role requires a full relabel of
> >>>>>> the homedir.  Labeling of the /root directory should be static and not
> >>>>>> related to user or role, because domains often want read/write access to
> >>>>>> the root directory and dontauditing this becomes complex if this changes
> >>>>>> based on semanage rules.
> >>>>>>
> >>>>>> service XYZ start in /root will almost always generate a search of the
> >>>>>> /root directory.
> >>>>>>
> >>>>>> Currently Fedora labeling on the homedir is user_home_t or
> >>>>>> user_mozilla_home_t, Ie everything user_* So switching this to
> >>>>>> mozilla_home_t or home_t would be fine.
> >>>>> As before, I don't believe any of this would force anyone to separate
> >>>>> files based on role; it would be driven by policy configuration and
> >>>>> using object_r pervasively would continue to work fine.  It would just
> >>>>> offer the ability to provide such separation based on role if so
> >>>>> configured, and it would drop the use of derived types to achieve such
> >>>>> separation.
> >>>>>
> >>>>> If you aren't going to separate files based on role though, you may want
> >>>>> to think about how to protect roles against influence by other roles so
> >>>>> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
> >>>>> into dotfiles.  DAC will help you with user-based separation (somewhat),
> >>>>> but there is still the case where you have a user who is authorized for
> >>>>> staff_r and sysadm_r who logs in initially in staff_r and later switches
> >>>>> to sysadm_r.  There you have consider the potential of a flawed or
> >>>>> malicious program run while in staff_r trying to inject commands to be
> >>>>> run in sysadm_r, all running under the same user identity.
> >>>>>
> >>>> I label /root admin_home_t and don't allow any confined role to write to
> >>>> it.  I have sysadm_r but have written before that I think it is a waste
> >>>> of time, and prefer to just use unconfined_r.
> >>>>
> >>>> My view of the world is that you have a "login" role and you have an
> >>>> "admin" role.  On my machine this is staff_r and unconfined_r, respectively.
> >>> Right, but whether unconfined_r or sysadm_r, the question is how to
> >>> protect the more-privileged role (unconfined_r in your case) from
> >>> influence by the less-privileged login role (staff_r) when they both
> >>> operate under the same DAC uid and thus share the same set of dotfiles.
> >>> The per-role types or roles on home directory files are one mechanism
> >>> for achieving that protection.  Another way would be to polyinstantiate
> >>> the home directories by role.  Another way that relies on DAC-only would
> >>> be to create a dedicated (pseudo) user account for each role with its
> >>> own home directory and "safe" set of dotfiles and switch to that account
> >>> when switching roles.
> >>>
> >> But you are assuming the UID does not change.   Since I look at the
> >> world as Two Roles,  One Role when I am normal user and another role
> >> when I am root.   I don't have this problem.  I don't want users using
> >> newrole,  I want them to use sudo.  So unconfined_t or webadm_t when
> >> UID==root, staff_t when UID=dwalsh.  newrole is just a complexity that
> >> most users do not understand.    Since a confined application can not
> >> read by default the directories of the user, the user will not be able
> >> to effect the confined domain.
> > 
> > That's essentially the last case (create a dedicated pseudo user account
> > for each role with its own home directory) simplified to two-roles-only.
> > But I think you'll eventually find two-roles-only to be too limiting
> > (and certainly not sufficient for RBAC for organizations).
> > 
> But I would argue this is exactly why RBAC has never caught on, because
> administrators and users do not think of themselves as Roles, they run
> applications.  The only roles an administrator of Unix systems
> understands and his login role and his admin role.  He is not going to
> want to run commands to Switch Roles other than Sudo, which my mechanism
> fully supports.  But imagining him switching roles while root or while a
> user is way too complicated.

It doesn't have to be too complicated, and it is actually quite natural
as a model for organizations.

In any event, all I am saying is that there has to be a mechanism for
protecting the role against influence by less privileged roles, and if
you want to use separate user accounts (which is what you are doing
here) to achieve that protection as far as the filesystem is concerned
(while still using SELinux for role process isolation), then that is
certainly an option.  But doing it via primary user accounts is less
helpful than introducing pseudo user accounts dedicated to the
particular role, I think, as we want to preserve user accountability
while acting in a given role.  This btw is the Solaris model for roles -
they are pseudo user accounts that cannot be directly logged into, only
assumable via su.

> We have had a hard time convincing users to Leave SELinux on, now we
> want to start adding new complexities, that have nothing to do with the
> way they are used to working.  Seems to be a lot of work for little
> benefit for the masses.

Well, first, as you know, from what we've seen, the majority of Fedora
users now seem to be leaving SELinux enabled as they now have the tools
they need to recognize and solve the most common problems.

I'm not sure why you think we're adding complexity here; Chris is merely
migrating an existing mechanism for supporting role-based separation in
the filesystem (via derived types) to a new mechanism (directly based on
roles).  And you just want to use neither of those mechanisms, which is
your option, instead choosing to use a DAC-based mechanism.  Nothing
Chris is doing makes your job any harder AFAICS.

Meanwhile, there is real use of RBAC in organizations; you might want to
look over some of the resources on:
http://csrc.nist.gov/groups/SNS/rbac/

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Wed, 2008-04-30 at 13:35 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Wed, 2008-04-30 at 11:34 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Stephen Smalley wrote:
>>>>> On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Stephen Smalley wrote:
>>>>>>> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>>> For those interested all of the user roles have been separated out into
>>>>>>>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
>>>>>>>>> This should enable interested users to add and remove roles more easily.
>>>>>>>>> Each of the user roles has a module named after it (e.g., sysadm module
>>>>>>>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
>>>>>>>>> possible to use "user" as a module name since it is a policy keyword.
>>>>>>>>>
>>>>>>>>> Next we will be doing an experiment attempting to use the SELinux RBAC
>>>>>>>>> functionality to separate users instead of SELinux TE.  What this means
>>>>>>>>> is that the role field will start being used more substantially than it
>>>>>>>>> currently is.  In a nutshell, this means that all user objects will have
>>>>>>>>> the user's role rather than object_r.  Then the separate types will be
>>>>>>>>> collapsed into one type where possible.  This will result in per-role
>>>>>>>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
>>>>>>>>> (mozilla_t).
>>>>>>>>>
>>>>>>>>> So for example, all of the home directory types will be collapsed into
>>>>>>>>> home_t and home_dir_t.  This results in /root having the context
>>>>>>>>> root:sysadm_r:home_dir_t.
>>>>>>>>>
>>>>>>>>> My current idea for RBAC rules is to group object classes in RBAC
>>>>>>>>> constraints similar to the current MLS constraints (e.g. file classes
>>>>>>>>> together, network classes together).  The basic RBAC rule will be:
>>>>>>>>>
>>>>>>>>> constrain { dir file ... } { getattr read write .... }
>>>>>>>>> 	r1 == r2
>>>>>>>>> 	or r1 == system_r
>>>>>>>>> 	or r2 == object_r
>>>>>>>>> 	or r1 == rbac_subj_role_file_exempt
>>>>>>>>> 	or r2 == rbac_obj_role_file_exempt
>>>>>>>>> 	or t1 == rbac_subj_type_file_exempt
>>>>>>>>> 	or t2 == rbac_obj_type_file_exempt;
>>>>>>>>>
>>>>>>>>> Is this too coarse?  Do we want to break it down into read and write
>>>>>>>>> rather than just exempt?
>>>>>>>>>
>>>>>>>>> Unfortunately this necessitates some kernel and userspace changes:
>>>>>>>>>
>>>>>>>>> Roles aren't respected on objects in the kernel.  So if you create a
>>>>>>>>> file in a directory that has the role staff_r, the file will have an
>>>>>>>>> object_r role instead of staff_r.
>>>>>>>>>
>>>>>>>>> Login programs and newrole will have to be changed to set the role on
>>>>>>>>> the terminal.
>>>>>>>>>
>>>>>>>>> The above example rule utilizes a role attribute, which doesn't exist.
>>>>>>>>> In the absence of role attributes, role dominance can be used, but its
>>>>>>>>> unclear if the dominance code works, since no one uses it.
>>>>>>>>>
>>>>>>>>> Genhomedircon may need to be updated.
>>>>>>>>>
>>>>>>>>> Tools such as audit2allow will need more audit2why-like support and
>>>>>>>>> policy info to fix RBAC denials (a general constraints usability issue).
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>> As has been stated before, I am not interested in separation of the
>>>>>>>> homedir based on Role, since this will prevent shared homedirs on
>>>>>>>> machines where the same user has different roles.  Also makes testing of
>>>>>>>> homedir roles difficult since changing a role requires a full relabel of
>>>>>>>> the homedir.  Labeling of the /root directory should be static and not
>>>>>>>> related to user or role, because domains often want read/write access to
>>>>>>>> the root directory and dontauditing this becomes complex if this changes
>>>>>>>> based on semanage rules.
>>>>>>>>
>>>>>>>> service XYZ start in /root will almost always generate a search of the
>>>>>>>> /root directory.
>>>>>>>>
>>>>>>>> Currently Fedora labeling on the homedir is user_home_t or
>>>>>>>> user_mozilla_home_t, Ie everything user_* So switching this to
>>>>>>>> mozilla_home_t or home_t would be fine.
>>>>>>> As before, I don't believe any of this would force anyone to separate
>>>>>>> files based on role; it would be driven by policy configuration and
>>>>>>> using object_r pervasively would continue to work fine.  It would just
>>>>>>> offer the ability to provide such separation based on role if so
>>>>>>> configured, and it would drop the use of derived types to achieve such
>>>>>>> separation.
>>>>>>>
>>>>>>> If you aren't going to separate files based on role though, you may want
>>>>>>> to think about how to protect roles against influence by other roles so
>>>>>>> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
>>>>>>> into dotfiles.  DAC will help you with user-based separation (somewhat),
>>>>>>> but there is still the case where you have a user who is authorized for
>>>>>>> staff_r and sysadm_r who logs in initially in staff_r and later switches
>>>>>>> to sysadm_r.  There you have consider the potential of a flawed or
>>>>>>> malicious program run while in staff_r trying to inject commands to be
>>>>>>> run in sysadm_r, all running under the same user identity.
>>>>>>>
>>>>>> I label /root admin_home_t and don't allow any confined role to write to
>>>>>> it.  I have sysadm_r but have written before that I think it is a waste
>>>>>> of time, and prefer to just use unconfined_r.
>>>>>>
>>>>>> My view of the world is that you have a "login" role and you have an
>>>>>> "admin" role.  On my machine this is staff_r and unconfined_r, respectively.
>>>>> Right, but whether unconfined_r or sysadm_r, the question is how to
>>>>> protect the more-privileged role (unconfined_r in your case) from
>>>>> influence by the less-privileged login role (staff_r) when they both
>>>>> operate under the same DAC uid and thus share the same set of dotfiles.
>>>>> The per-role types or roles on home directory files are one mechanism
>>>>> for achieving that protection.  Another way would be to polyinstantiate
>>>>> the home directories by role.  Another way that relies on DAC-only would
>>>>> be to create a dedicated (pseudo) user account for each role with its
>>>>> own home directory and "safe" set of dotfiles and switch to that account
>>>>> when switching roles.
>>>>>
>>>> But you are assuming the UID does not change.   Since I look at the
>>>> world as Two Roles,  One Role when I am normal user and another role
>>>> when I am root.   I don't have this problem.  I don't want users using
>>>> newrole,  I want them to use sudo.  So unconfined_t or webadm_t when
>>>> UID==root, staff_t when UID=dwalsh.  newrole is just a complexity that
>>>> most users do not understand.    Since a confined application can not
>>>> read by default the directories of the user, the user will not be able
>>>> to effect the confined domain.
>>> That's essentially the last case (create a dedicated pseudo user account
>>> for each role with its own home directory) simplified to two-roles-only.
>>> But I think you'll eventually find two-roles-only to be too limiting
>>> (and certainly not sufficient for RBAC for organizations).
>>>
>> But I would argue this is exactly why RBAC has never caught on, because
>> administrators and users do not think of themselves as Roles, they run
>> applications.  The only roles an administrator of Unix systems
>> understands and his login role and his admin role.  He is not going to
>> want to run commands to Switch Roles other than Sudo, which my mechanism
>> fully supports.  But imagining him switching roles while root or while a
>> user is way too complicated.
> 
> It doesn't have to be too complicated, and it is actually quite natural
> as a model for organizations.
> 
> In any event, all I am saying is that there has to be a mechanism for
> protecting the role against influence by less privileged roles, and if
> you want to use separate user accounts (which is what you are doing
> here) to achieve that protection as far as the filesystem is concerned
> (while still using SELinux for role process isolation), then that is
> certainly an option.  But doing it via primary user accounts is less
> helpful than introducing pseudo user accounts dedicated to the
> particular role, I think, as we want to preserve user accountability
> while acting in a given role.  This btw is the Solaris model for roles -
> they are pseudo user accounts that cannot be directly logged into, only
> assumable via su.
> 
>> We have had a hard time convincing users to Leave SELinux on, now we
>> want to start adding new complexities, that have nothing to do with the
>> way they are used to working.  Seems to be a lot of work for little
>> benefit for the masses.
> 
> Well, first, as you know, from what we've seen, the majority of Fedora
> users now seem to be leaving SELinux enabled as they now have the tools
> they need to recognize and solve the most common problems.
> 
> I'm not sure why you think we're adding complexity here; Chris is merely
> migrating an existing mechanism for supporting role-based separation in
> the filesystem (via derived types) to a new mechanism (directly based on
> roles).  And you just want to use neither of those mechanisms, which is
> your option, instead choosing to use a DAC-based mechanism.  Nothing
> Chris is doing makes your job any harder AFAICS.
> 
> Meanwhile, there is real use of RBAC in organizations; you might want to
> look over some of the resources on:
> http://csrc.nist.gov/groups/SNS/rbac/
> 
That is fine.  I am not objecting, and if it makes it easier to merge in
my changes that would be great.  But userspace tools are going to need
to become smarter about handling differences in the Role.  For example
restorecon.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgYsxkACgkQrlYvE4MpobNamACgmS14YcAFnfSMgHmeguzCXFRR
wQoAoLzKKpD5XFoKVIwH13U43+e3h04Q
=c0K9
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Christopher J. PeBenito]

On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > Next we will be doing an experiment attempting to use the SELinux RBAC
> > functionality to separate users instead of SELinux TE.  What this means
> > is that the role field will start being used more substantially than it
> > currently is.  In a nutshell, this means that all user objects will have
> > the user's role rather than object_r.  Then the separate types will be
> > collapsed into one type where possible.  This will result in per-role
> > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > (mozilla_t).
[...]
> > The above example rule utilizes a role attribute, which doesn't exist.
> > In the absence of role attributes, role dominance can be used, but its
> > unclear if the dominance code works, since no one uses it.

Turns out that I can't use role dominance because dom and domby in
constraints only seem to work (syntax error) between r1 and r2, rather
than r1 and a specific role.

> Yes, I think we should just add role attribute support.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: refpolicy roles / RBAC separation RFC

[Stephen Smalley]

On Wed, 2008-05-07 at 13:32 -0400, Christopher J. PeBenito wrote:
> On Tue, 2008-04-29 at 14:56 -0400, Stephen Smalley wrote:
> > On Tue, 2008-04-29 at 11:54 -0400, Christopher J. PeBenito wrote:
> > > Next we will be doing an experiment attempting to use the SELinux RBAC
> > > functionality to separate users instead of SELinux TE.  What this means
> > > is that the role field will start being used more substantially than it
> > > currently is.  In a nutshell, this means that all user objects will have
> > > the user's role rather than object_r.  Then the separate types will be
> > > collapsed into one type where possible.  This will result in per-role
> > > types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
> > > (mozilla_t).
> [...]
> > > The above example rule utilizes a role attribute, which doesn't exist.
> > > In the absence of role attributes, role dominance can be used, but its
> > > unclear if the dominance code works, since no one uses it.
> 
> Turns out that I can't use role dominance because dom and domby in
> constraints only seem to work (syntax error) between r1 and r2, rather
> than r1 and a specific role.

Ah, yes.  And that's true not only of checkpolicy but the constraint
evaluator in libsepol and the kernel too.  Only supports == and != for
comparing against a specific value or membership within a specific type
attribute, and the dominance operators are limited to comparing source
and target.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.