Alternative user management approach

Alternative user management approach

[Karl MacMillan]

We've been kicking around the best way to handle users in the future here at
Tresys and have an alternative suggestion.

This starts with some basic assertions:
1) Reloading the kernel policy on user change just seems . . . wrong.
2) Having the users in the kernel can be problematic for large numbers of users.
3) These problems get much worse if we are talking about large, distributed user
databases. Are sites with 10,000 users going to force a policy reload on every
machine every time a user is added? Are all 10,000 users going to be stored in
the kernel?

We have a partial solution to this already with the concept of a generic user
(user_u). Our suggestion is to expand this concept to have multiple generalized
users with rich mappings from Linux users to SELinux users. This would mean that
specific users would no longer be a part of the SELinux policy, removing the
need for libsepol changes.

This makes the SELinux user more what we are calling a 'user role'. For example,
the policy could create 3 user roles with different role authorizations (which
become 'role capabilities'):

user role		role capabilities
------------------------------------
normal		user_r
staff			staff_r sysadm_r
sysadm		sysadm_r

Normal Linux users are then mapped to user roles by username or group membership
(this should be done by libselinux and not involve the kernel). For example, if
the primary group of the user is wheel then they could be assigned to staff,
root assigned to sysadm, and everyone else to normal. This makes the addition of
a user roughly equivalent to adding roles - something done by a policy developer
that does not need to be done as part of normal system administration.

In the future, this can be greatly expanded in the reference policy with more
fine-grained role capabilities. For example:

user role		role capabilities
-----------------------------------
normal		user_r
staff			staff_r webadmin_r logadmin_r genadmin_r
secadmin		staff_r genadmin_r secadmin_r
sysadm		webadmin_r logadmin_r genadmin_r

Questions/Thoughts?

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134 




--
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: Alternative user management approach

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@tresys.com> wrote:


> This starts with some basic assertions:
> 1) Reloading the kernel policy on user change just
> seems . . . wrong.

That's because it is wrong.

> ...
> We have a partial solution to this already
> with the concept of a generic user
> (user_u).

A good start.

> Our suggestion is to expand this concept
> to have multiple generalized users with
> rich mappings from Linux users to SELinux
> users.

How is the different from roles?
Oh, never mind, you answer below.

> This would mean that specific users would
> no longer be a part of the SELinux policy,
> removing the need for libsepol changes.
> 
> This makes the SELinux user more what we
> are calling a 'user role'. For example,
> the policy could create 3 user roles with
> different role authorizations (which
> become 'role capabilities'):
> 
> user role		role capabilities
> ------------------------------------
> normal		user_r
> staff			staff_r sysadm_r
> sysadm		sysadm_r
> 
> Normal Linux users are then mapped to user
> roles by username or group membership
> (this should be done by libselinux and not
> involve the kernel). For example, if
> the primary group of the user is wheel then
> they could be assigned to staff,
> root assigned to sysadm, and everyone else to
> normal.

I suggest a seperate "/etc/usrrole" or similar
rather than overloading an existing attribute.
The folks who did System V/MLS stole the group
membership and introduced a variety of issues
when the scheme was applied to systems with
multiple concurrent groups and the BSD file
system group ownership symantics. On a system
with capabilities enforced properly you may
not want root to have sysadm, too.

> This makes the addition of
> a user roughly equivalent to adding roles -
> something done by a policy developer
> that does not need to be done as part of normal
> system administration.

Not sure I quite parse your meaning here.

> In the future, this can be greatly expanded in the
> reference policy with more
> fine-grained role capabilities. For example:
> 
> user role		role capabilities
> -----------------------------------
> normal		user_r
> staff			staff_r webadmin_r logadmin_r genadmin_r
> secadmin		staff_r genadmin_r secadmin_r
> sysadm		webadmin_r logadmin_r genadmin_r
> 
> Questions/Thoughts?

I think you're on the right track to
seperate users from policy. The details
are most likely a matter of taste once
you establish that adding a normal user
doesn't need to update the policy.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Alternative user management approach

[Karl MacMillan]

> -----Original Message-----
> From: Casey Schaufler [mailto:casey@schaufler-ca.com]
> Sent: Friday, June 24, 2005 12:38 PM
> To: Karl MacMillan; selinux@tycho.nsa.gov
> Subject: Re: Alternative user management approach
> 
> 
> > This would mean that specific users would
> > no longer be a part of the SELinux policy,
> > removing the need for libsepol changes.
> >
> > This makes the SELinux user more what we
> > are calling a 'user role'. For example,
> > the policy could create 3 user roles with
> > different role authorizations (which
> > become 'role capabilities'):
> >
> > user role		role capabilities
> > ------------------------------------
> > normal		user_r
> > staff			staff_r sysadm_r
> > sysadm		sysadm_r
> >
> > Normal Linux users are then mapped to user
> > roles by username or group membership
> > (this should be done by libselinux and not
> > involve the kernel). For example, if
> > the primary group of the user is wheel then
> > they could be assigned to staff,
> > root assigned to sysadm, and everyone else to
> > normal.
> 
> I suggest a seperate "/etc/usrrole" or similar
> rather than overloading an existing attribute.
> The folks who did System V/MLS stole the group
> membership and introduced a variety of issues
> when the scheme was applied to systems with
> multiple concurrent groups and the BSD file
> system group ownership symantics. On a system
> with capabilities enforced properly you may
> not want root to have sysadm, too.
> 

To make my suggestion more concrete, I think a mapping file in
/etc/selinux/policyname that maps from users to SELinux users. The config would
be an ordered list of mappings that use username and group information. That
means that if the admin wants to use group info they can, otherwise it is
ignored. The first match in the ordered list would win. Maybe something like:

id:root	sysadm
group:wheel staff
default	normal

There are a lot of possibilities including boolean logic, wildcards, etc. Not
certain how much complexity is needed.

> > This makes the addition of
> > a user roughly equivalent to adding roles -
> > something done by a policy developer
> > that does not need to be done as part of normal
> > system administration.
> 
> Not sure I quite parse your meaning here.
> 

Overloaded use of user . . . probably a sign of problems to come in this
discussion. Adding an SELinux user role is done by the policy developer at
development time. Adding Linux users and mapping them to SELinux user roles is
runtime and done by the system administrator.

> > In the future, this can be greatly expanded in the
> > reference policy with more
> > fine-grained role capabilities. For example:
> >
> > user role		role capabilities
> > -----------------------------------
> > normal		user_r
> > staff			staff_r webadmin_r logadmin_r genadmin_r
> > secadmin		staff_r genadmin_r secadmin_r
> > sysadm		webadmin_r logadmin_r genadmin_r
> >
> > Questions/Thoughts?
> 
> I think you're on the right track to
> seperate users from policy. The details
> are most likely a matter of taste once
> you establish that adding a normal user
> doesn't need to update the policy.
> 
> 

Sounds about right to me.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> Casey Schaufler
> casey@schaufler-ca.com
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com



--
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: Alternative user management approach

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@tresys.com> wrote:


> To make my suggestion more concrete, I think a
> mapping file in
> /etc/selinux/policyname that maps from users to
> SELinux users. The config would
> be an ordered list of mappings that use username and
> group information. That
> means that if the admin wants to use group info they
> can, otherwise it is
> ignored. The first match in the ordered list would
> win. Maybe something like:
> 
> id:root	sysadm
> group:wheel staff
> default	normal
> 
> There are a lot of possibilities including boolean
> logic, wildcards, etc. Not
> certain how much complexity is needed.

As a thought, how about:

userid:grouplist:policyname

where userid or grouplist can be '*' (any) and
only exact matches count. Most explicit match
is used.

    root:*:sysadm
    fred:wheel:wand
    *:wheel:staff
    *:*:normal

Fred would be in "wand" if only in group wheel,
in "normal" if in groups wheel and dev. Fun.




Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 


--
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: Alternative user management approach

[Karl MacMillan]

> -----Original Message-----
> From: Casey Schaufler [mailto:casey@schaufler-ca.com]
> Sent: Friday, June 24, 2005 1:26 PM
> To: Karl MacMillan; selinux@tycho.nsa.gov
> Subject: RE: Alternative user management approach
> 
> 
> 
> --- Karl MacMillan <kmacmillan@tresys.com> wrote:
> 
> 
> > To make my suggestion more concrete, I think a
> > mapping file in
> > /etc/selinux/policyname that maps from users to
> > SELinux users. The config would
> > be an ordered list of mappings that use username and
> > group information. That
> > means that if the admin wants to use group info they
> > can, otherwise it is
> > ignored. The first match in the ordered list would
> > win. Maybe something like:
> >
> > id:root	sysadm
> > group:wheel staff
> > default	normal
> >
> > There are a lot of possibilities including boolean
> > logic, wildcards, etc. Not
> > certain how much complexity is needed.
> 
> As a thought, how about:
> 
> userid:grouplist:policyname
> 
> where userid or grouplist can be '*' (any) and
> only exact matches count. Most explicit match
> is used.
> 
>     root:*:sysadm
>     fred:wheel:wand
>     *:wheel:staff
>     *:*:normal
> 
> Fred would be in "wand" if only in group wheel,
> in "normal" if in groups wheel and dev. Fun.
> 
> 
> 

Looks reasonable to me - removes ordering which is nice (ordering is so fragile
and error prone). Now if we can just answer the hard question of whether the
whole concept makes sense . . .

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> Casey Schaufler
> casey@schaufler-ca.com
> 
> 
> 
> __________________________________
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour:
> http://tour.mail.yahoo.com/mailtour.html



--
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 13:04 -0400, Karl MacMillan wrote:
> To make my suggestion more concrete, I think a mapping file in
> /etc/selinux/policyname that maps from users to SELinux users. The config would
> be an ordered list of mappings that use username and group information. That
> means that if the admin wants to use group info they can, otherwise it is
> ignored. The first match in the ordered list would win. Maybe something like:
> 
> id:root	sysadm
> group:wheel staff
> default	normal

Default group?  Supplemental groups?

This only happens at login time (or su), not newgrp.

-- 
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: Alternative user management approach

[Brian T. Sniffen]

"Karl MacMillan" <kmacmillan@tresys.com> writes:

> This makes the SELinux user more what we are calling a 'user
> role'. For example, the policy could create 3 user roles with
> different role authorizations (which become 'role capabilities'):

This seems like a great innovation.  But it does inherit one problem
of generic user_u: there's no longer any MAC separating users.  If I'm
a normal user, my shell has exactly the same security context as your
shell---right?

-Brian


--
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 14:09 -0400, Brian T. Sniffen wrote:
> "Karl MacMillan" <kmacmillan@tresys.com> writes:
> 
> > This makes the SELinux user more what we are calling a 'user
> > role'. For example, the policy could create 3 user roles with
> > different role authorizations (which become 'role capabilities'):
> 
> This seems like a great innovation.  But it does inherit one problem
> of generic user_u: there's no longer any MAC separating users.  If I'm
> a normal user, my shell has exactly the same security context as your
> shell---right?

Yes, but SELinux doesn't isolate those shells even if they have
different SELinux user identities if they have the same role and domain.
In fact, you only get real isolation in SELinux between domains (or MLS
levels, if using MLS).  

-- 
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: Alternative user management approach

[James Morris]

On Fri, 24 Jun 2005, Stephen Smalley wrote:

> Yes, but SELinux doesn't isolate those shells even if they have
> different SELinux user identities if they have the same role and domain.
> In fact, you only get real isolation in SELinux between domains (or MLS
> levels, if using MLS).  

But how would this change impact MLS, given that levels are associated 
with SELinux users?


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 15:50 -0400, James Morris wrote:
> On Fri, 24 Jun 2005, Stephen Smalley wrote:
> 
> > Yes, but SELinux doesn't isolate those shells even if they have
> > different SELinux user identities if they have the same role and domain.
> > In fact, you only get real isolation in SELinux between domains (or MLS
> > levels, if using MLS).  
> 
> But how would this change impact MLS, given that levels are associated 
> with SELinux users?

Ok, so instead of just "role class", the SELinux user identity becomes a
"role/level class", and you just have an extra level of indirection
between Linux users and levels, just as you would have between Linux
users and roles.  So you can map a set of Linux users who are authorized
for a given range to a single SELinux user identity if you want.  But
you still have the freedom to maintain separate SELinux user identities
per Linux uid if you truly want that; that would all be controlled by
the new config file that specifies the mappings.

-- 
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: Alternative user management approach

[James Morris]

On Fri, 24 Jun 2005, Stephen Smalley wrote:

> > But how would this change impact MLS, given that levels are associated 
> > with SELinux users?
> 
> Ok, so instead of just "role class", the SELinux user identity becomes a
> "role/level class", and you just have an extra level of indirection
> between Linux users and levels, just as you would have between Linux
> users and roles.  So you can map a set of Linux users who are authorized
> for a given range to a single SELinux user identity if you want.  But
> you still have the freedom to maintain separate SELinux user identities
> per Linux uid if you truly want that; that would all be controlled by
> the new config file that specifies the mappings.

Ok, this sounds quite flexible for MLS (cd'd Chad in case he has some
input).


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: Alternative user management approach

[Russell Coker]

On Saturday 25 June 2005 05:50, James Morris <jmorris@redhat.com> wrote:
> On Fri, 24 Jun 2005, Stephen Smalley wrote:
> > Yes, but SELinux doesn't isolate those shells even if they have
> > different SELinux user identities if they have the same role and domain.
> > In fact, you only get real isolation in SELinux between domains (or MLS
> > levels, if using MLS).
>
> But how would this change impact MLS, given that levels are associated
> with SELinux users?

Why would it have any impact on MLS?  The proposed change just changes the 
mapping from Unix UID/GID to SE Linux identity.  What role/level/category is 
assigned to the identity is a separate issue.  So I don't see MLS or the lack 
thereof making any impact on this decision.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Ivan Gyurdiev]

On Fri, 2005-06-24 at 14:09 -0400, Brian T. Sniffen wrote:
> "Karl MacMillan" <kmacmillan@tresys.com> writes:
> 
> > This makes the SELinux user more what we are calling a 'user
> > role'. For example, the policy could create 3 user roles with
> > different role authorizations (which become 'role capabilities'):
> 
> This seems like a great innovation.  But it does inherit one problem
> of generic user_u: there's no longer any MAC separating users.  If I'm
> a normal user, my shell has exactly the same security context as your
> shell---right?

Is the user info used for anything besides rbac?
I don't think it is...




--
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: Alternative user management approach

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 24, 2005 2:33 PM
> To: Brian T. Sniffen
> Cc: Karl MacMillan; selinux@tycho.nsa.gov
> Subject: Re: Alternative user management approach
> 
> On Fri, 2005-06-24 at 14:09 -0400, Brian T. Sniffen wrote:
> > "Karl MacMillan" <kmacmillan@tresys.com> writes:
> >
> > > This makes the SELinux user more what we are calling a 'user
> > > role'. For example, the policy could create 3 user roles with
> > > different role authorizations (which become 'role capabilities'):
> >
> > This seems like a great innovation.  But it does inherit one problem
> > of generic user_u: there's no longer any MAC separating users.  If I'm
> > a normal user, my shell has exactly the same security context as your
> > shell---right?
> 
> Is the user info used for anything besides rbac?
> I don't think it is...
> 

It can be used for constraints. There have been some suggested uses for this,
but none are currently implemented in real policies. User separation seems
better left to DAC.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Alternative user management approach

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Fri, 24 Jun 2005 14:41:45 EDT, Karl MacMillan said:
> > -----Original Message-----
> > From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> > Sent: Friday, June 24, 2005 2:33 PM
> > To: Brian T. Sniffen
> > Cc: Karl MacMillan; selinux@tycho.nsa.gov
> > Subject: Re: Alternative user management approach
> > 
> > On Fri, 2005-06-24 at 14:09 -0400, Brian T. Sniffen wrote:
> > > "Karl MacMillan" <kmacmillan@tresys.com> writes:
> > >
> > > > This makes the SELinux user more what we are calling a 'user
> > > > role'. For example, the policy could create 3 user roles with
> > > > different role authorizations (which become 'role capabilities'):
> > >
> > > This seems like a great innovation.  But it does inherit one problem
> > > of generic user_u: there's no longer any MAC separating users.  If I'm
> > > a normal user, my shell has exactly the same security context as your
> > > shell---right?
> > 
> > Is the user info used for anything besides rbac?
> > I don't think it is...
> > 
> 
> It can be used for constraints. There have been some suggested uses for this,
> but none are currently implemented in real policies. User separation seems
> better left to DAC.

I think I was the guy who started the whole constraints discussion ;)

And for the most part, yes DAC is sufficient - but there's a few things I'd
like to apply at the MAC level using constraints.  I'd much rather have one
user_u with 20-30 locally added ($u1 != $u2) constraints than have to drag
around user1_u..user1000_u with corresponding ruleset explosion....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Alternative user management approach

[Casey Schaufler]

--- Valdis.Kletnieks@vt.edu wrote:


> And for the most part, yes DAC is sufficient - but
> there's a few things I'd
> like to apply at the MAC level using constraints. 
> I'd much rather have one
> user_u with 20-30 locally added ($u1 != $u2)
> constraints than have to drag
> around user1_u..user1000_u with corresponding
> ruleset explosion....

I'm probably missing something, but it looks to
me like the user seperation issue is handled quite
nicely by a well implemented B&L category set.
There are may places using MLS systems in that 
way today.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
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: Alternative user management approach

[Daniel J Walsh]

Ok this all sounds good, but how do we come to a consensus. 

Do we need an "role attribute" to define "user" roles.

roleattribute staff_r user;
roleattribute user_r user;
roleattribute sysadm_r user;

Then do we need a mechanism in policy to associate roles with "user" roles?

How does all this work with MLS ranges?

Should we have a brainstorming session?  It is important to us (Red Hat) 
that we get this settled soon.

Do we have a new file which associates uids to user roles?

Dan


-- 



--
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: Alternative user management approach

[Joshua Brindle]

Daniel J Walsh wrote:

> Ok this all sounds good, but how do we come to a consensus.
> Do we need an "role attribute" to define "user" roles.
>
> roleattribute staff_r user;
> roleattribute user_r user;
> roleattribute sysadm_r user;
>
> Then do we need a mechanism in policy to associate roles with "user" 
> roles?

no language changes are necessary

> How does all this work with MLS ranges?
>
> Should we have a brainstorming session?  It is important to us (Red 
> Hat) that we get this settled soon.
>
> Do we have a new file which associates uids to user roles?
>
yes, from the policy language and kernel perspectives there need not be 
any changes, basically instead of creating specific users:

user jbrindle { staff_r sysadm_r }

you create generic users:

user admin { staff_r sysadm_r }
user user_u { user_r }

and then associate linux logins (or groups!) with those generic users: 
(libselinux will read this file instead of using the implicit login name 
-> selinux name mapping)

group:wheel   admin
default            user_u

MLS would work the same way, the only difference being that you may need 
more generic users to sufficiently cover all the role + level 
combinations you need.

To make this backend independant the same mapping info could be sitting 
in ldap or some other database.

The biggest challenge after this is labeling, how to label home 
directories (Probably should only be done at useradd time, or when you 
log into a computer the first time with LDAP, the utilities will have to 
be a bit smarter about labeling)

Joshua Brindle


--
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: Alternative user management approach

[Casey Schaufler]

--- Joshua Brindle <jbrindle@tresys.com> wrote:


> The biggest challenge after this is labeling,
> how to label home directories (Probably should
> only be done at useradd time, or when you 
> log into a computer the first time with LDAP, the
> utilities will have to 
> be a bit smarter about labeling)

Unix MLS systems require that the home directory
be labeled upon creation, usually by the useradd
utility or the local equivalent, but sometimes
by hand. Spontainious creation of home directories
on first login was never on anyone's high priority
todo list, so it remains an unsolved problem.
There are systems that will automount your
home directory, but that requires MLS aware NFS.

Unix MLS systems keep a default label as well as
a clearance, using the default label for the user
as label for the home directory. It is of course
possible to muck things up by have a default label
that is not dominated by all labels in your
clearance, but most sysadmins figure that out
very quickly.

Of course, on Unix MLS systems all files have
labels attached, per the TCSEC requirements,
unless an entire file system in unlabeled in
which case all files are treated at the same
sensitivity. I don't know if y'all plan to
label all files for SELinux MLS or what you
might do instead.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Alternative user management approach

[Ivan Gyurdiev]

> The biggest challenge after this is labeling, how to label home 
> directories 

How to label the home directories?
Will directories keep their role-dependent contexts?

Sounds like:

useradd---->
(add a linux user)
	-------> security_create_policydb_default()	
		(map file, load bools, load users, create policydb)

	-------> sepol_user_suser_map_file()
	(writes to user->suser map (file backend))

		--------> sepol_suser_get_defrole_file(suser)
		(gets def. context (and thus ROLE) for user's suser)

		--------> sepol_fscon_user_add()
		(writes user's file contexts based on this)
		(uses template...)

	-------> security_destroy_policydb();

suseradd----> 
(add a selinux user/class)
	
	-------> security_create_policydb_default()
		(map file, load bools, load users, create policydb)

	-------> sepol_suser_add_file()
	(sepol function to do that using file backend)
	(writes to suser->roles map)

		----------> sepol_suser_add_policy()
		(add suser to binary policy)

	-------> security_load_policydb();

	-------> security_destroy_policydb();


Please note that none of this addresses the speed issue.
A policydb still needs to be constructed for validation purposes.

However, it does address the scalability concern of not
loading every user into the kernel policy.



--
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: Alternative user management approach

[Ivan Gyurdiev]

> Please note that none of this addresses the speed issue.
> A policydb still needs to be constructed for validation purposes.

I could use libselinux for validation, but it's not clear
that I should do that...

In other words if I'm adding permanent policy changes (like
writing file contexts in a file for future use)
it's not clear that I should be querying the runtime
policy (libselinux), instead of the on-disk policy (libsepol)
to check their validity.

The latter requires a policydb object...which takes 5 seconds 
to construct and load on a slow laptop, 2 seconds my athlon3k
at home, and probably 3 seconds on a laptop if you only
read it, and not write it back out (for purposes of loading).

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Alternative user management approach

[Russell Coker]

On Sunday 26 June 2005 05:37, Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > The biggest challenge after this is labeling, how to label home
> > directories
>
> How to label the home directories?
> Will directories keep their role-dependent contexts?

Yes.  Only the identity of the home directories will have to change.  This 
means of course that genhomedircon needs to be updated to know how to map 
Unix account names to SE Linux identities, that shouldn't be difficult.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Ivan Gyurdiev]

On Mon, 2005-06-27 at 02:38 +1000, Russell Coker wrote:
> On Sunday 26 June 2005 05:37, Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> > > The biggest challenge after this is labeling, how to label home
> > > directories
> >
> > How to label the home directories?
> > Will directories keep their role-dependent contexts?
> 
> Yes.  Only the identity of the home directories will have to change. This 
> means of course that genhomedircon needs to be updated to know how to map 
> Unix account names to SE Linux identities, that shouldn't be difficult.

We're moving to a libsepol solution written in C, automatically
invoked from useradd - so nothing's as easy as it seems. Once finished,
however, the C solution should be smarter, and more capable than
the python tool.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Alternative user management approach

[Daniel J Walsh]

Joshua Brindle wrote:

> Daniel J Walsh wrote:
>
>> Ok this all sounds good, but how do we come to a consensus.
>> Do we need an "role attribute" to define "user" roles.
>>
>> roleattribute staff_r user;
>> roleattribute user_r user;
>> roleattribute sysadm_r user;
>>
>> Then do we need a mechanism in policy to associate roles with "user" 
>> roles?
>
>
> no language changes are necessary
>
>> How does all this work with MLS ranges?
>>
>> Should we have a brainstorming session?  It is important to us (Red 
>> Hat) that we get this settled soon.
>>
>> Do we have a new file which associates uids to user roles?
>>
> yes, from the policy language and kernel perspectives there need not 
> be any changes, basically instead of creating specific users:
>
> user jbrindle { staff_r sysadm_r }
>
> you create generic users:
>
> user admin { staff_r sysadm_r }
> user user_u { user_r }
>
> and then associate linux logins (or groups!) with those generic users: 
> (libselinux will read this file instead of using the implicit login 
> name -> selinux name mapping)
>
> group:wheel   admin
> default            user_u
>
> MLS would work the same way, the only difference being that you may 
> need more generic users to sufficiently cover all the role + level 
> combinations you need.
>
> To make this backend independant the same mapping info could be 
> sitting in ldap or some other database.
>
> The biggest challenge after this is labeling, how to label home 
> directories (Probably should only be done at useradd time, or when you 
> log into a computer the first time with LDAP, the utilities will have 
> to be a bit smarter about labeling)
>
> Joshua Brindle
>
Ok what does a third party vendor then do.  Say they create a role of 
nurse_r, doctor_r, labtech_r?

-- 



--
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: Alternative user management approach

[Joshua Brindle]

On Saturday 25 June 2005 16:02, Daniel J Walsh wrote:
<snip>
> Ok what does a third party vendor then do.  Say they create a role of
> nurse_r, doctor_r, labtech_r?

I don't think I understand the question. This is about user management, adding 
roles would entail the same things it does now. 

--
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: Alternative user management approach

[Russell Coker]

On Saturday 25 June 2005 20:28, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Ok this all sounds good, but how do we come to a consensus.
>
> Do we need an "role attribute" to define "user" roles.

I think we need a role attribute to solve the problem of the ugly 
in_user_role() macro.

> roleattribute staff_r user;
> roleattribute user_r user;
> roleattribute sysadm_r user;
>
> Then do we need a mechanism in policy to associate roles with "user" roles?

Firstly I think we should stick to the established terminology for the moment.  
We have SE Linux identities which determine the roles that are permitted, and 
we have a mapping mechanism to determine the SE Linux identity from the Unix 
UID.  The current mapping mechanism is to look for a match between the Unix 
account name and a SE Linux identity and use that identity if it exists, 
otherwise use "user_u".  We are talking about having a config file using 
user-name and group-name.

The group-name thing could become fun if we have multiple names for the same 
GID (it's not recommended but it works at the moment) and the GID is the 
primary group for some users.  The Unix user-name is unambiguous as we start 
with the name for every operation AFAIK.

> How does all this work with MLS ranges?

How does it cause problems with MLS?

> Do we have a new file which associates uids to user roles?

Unix account names not UIDs.  I think a mapping file is the only way.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Casey Schaufler]

--- Russell Coker <russell@coker.com.au> wrote:


> The group-name thing could become fun if we have
> multiple names for the same 
> GID (it's not recommended but it works at the
> moment) and the GID is the 
> primary group for some users.  The Unix user-name is
> unambiguous as we start 
> with the name for every operation AFAIK.
> 
> > How does all this work with MLS ranges?
> 
> How does it cause problems with MLS?

Maybe it doesn't. On the other hand, can you
explain how it might work if you have a user
(I'll call him Barney today) who is cleared
to Secret in compartment A17 and B43? Do we
have to have a seperate role for Secret,A17
and Secret,B32 or do we need SELinux users

   Barney,Unclassified
   Barney,Secret
   Barney,Secret,A17
   Barnet,Secret,B43
   Barney,Secret,A17,B43

I could see arguments put forth for either
of these schemes as well as a number of others.
Just as multiple groups can muddy the waters
so to can clearance ranges result in issues of
attribute permutation.

> > Do we have a new file which associates uids to
> user roles?
> 
> Unix account names not UIDs. I think a mapping file
> is the only way.

Names not numbers, definitly.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

--
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: Alternative user management approach

[Russell Coker]

On Monday 27 June 2005 03:46, Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > How does all this work with MLS ranges?
> >
> > How does it cause problems with MLS?
>
> Maybe it doesn't. On the other hand, can you
> explain how it might work if you have a user
> (I'll call him Barney today) who is cleared
> to Secret in compartment A17 and B43? Do we
> have to have a seperate role for Secret,A17
> and Secret,B32 or do we need SELinux users
>
>    Barney,Unclassified
>    Barney,Secret
>    Barney,Secret,A17
>    Barnet,Secret,B43
>    Barney,Secret,A17,B43

So the issue that you are raising is that the number of combinations of MLS 
clearance is potentially 2^(number of categories) * (number of levels) which 
is much greater than 2^(number of roles in strict policy), and that the 
number of such combinations which is desired in MLS may be significantly 
greater than the number of role combinations which are desired with a strict 
policy.

This will make management a little more complex, but I don't imagine that the 
situation of having the number of SE Linux identities approaching the number 
of Unix accounts will be common.  I expect that in most real systems they 
usually choose a category of access to grant each user as assigning access 
individually to each user is more effort.

For the case where each Unix user has a discrete set of access rights the 
administrator would just do exactly what they do today.  Their security 
policy merely prevents them from taking advantage of the new feature which we 
are designing.  It's not a problem of the feature, just a fact that it won't 
be useful for everyone.

> > Unix account names not UIDs. I think a mapping file
> > is the only way.
>
> Names not numbers, definitly.

Although there is something to be said for using GID numbers.  If you have 
number 500 in your GID field in /etc/passwd and there are two entries for 500 
in /etc/group then things can be ambiguous if using the group name.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Casey Schaufler]

--- Russell Coker <russell@coker.com.au> wrote:


> So the issue that you are raising is that the number
> of combinations of MLS 
> clearance is potentially 2^(number of categories) *
> (number of levels) which 
> is much greater than 2^(number of roles in strict
> policy), and that the 
> number of such combinations which is desired in MLS
> may be significantly 
> greater than the number of role combinations which
> are desired with a strict 
> policy.

I don't intend to raise number-of-policy issues.
I said that I wouldn't do that.
I am curious how MLS is going to interact with the
rest of the policy rules.
 
> This will make management a little more complex, but
> I don't imagine that the 
> situation of having the number of SE Linux
> identities approaching the number 
> of Unix accounts will be common.

That's handy.

> I expect that in
> most real systems they 
> usually choose a category of access to grant each
> user as assigning access 
> individually to each user is more effort.

I'm not sure I understand your meaning.

> For the case where each Unix user has a discrete set
> of access rights the 
> administrator would just do exactly what they do
> today.

Well, they need to add the MLS charactoristics.

> Their security 
> policy merely prevents them from taking advantage of
> the new feature which we 
> are designing.  

This I don't understand 'tall.

> It's not a problem of the feature,
> just a fact that it won't 
> be useful for everyone.

> Although there is something to be said for using GID
> numbers.  

Agreed in practice if not principle.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
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: Alternative user management approach

[Russell Coker]

On Monday 27 June 2005 12:43, Casey Schaufler <casey@schaufler-ca.com> wrote:
> --- Russell Coker <russell@coker.com.au> wrote:
> > So the issue that you are raising is that the number
> > of combinations of MLS
> > clearance is potentially 2^(number of categories) *
> > (number of levels) which
> > is much greater than 2^(number of roles in strict
> > policy), and that the
> > number of such combinations which is desired in MLS
> > may be significantly
> > greater than the number of role combinations which
> > are desired with a strict
> > policy.
>
> I don't intend to raise number-of-policy issues.

It's not the number of policies, but the number of MLS category combinations 
that may be used.  We have 10 sensitivity levels in the default MLS policy at 
the moment and 128 categories.  Therefore there are 10*2^128 possible MLS 
combinations that may be assigned to a user identity.  Naturally a single 
policy won't contain a small fraction of them, but it's still likely to 
contain a much larger number of combinations than with the strict policy 
which only has membership of three roles (of which only five combinations are 
sensible).

> I said that I wouldn't do that.
> I am curious how MLS is going to interact with the
> rest of the policy rules.

But surely that has nothing to do with the issue of mapping Unix account names 
to SE Linux access which is the topic of this thread.

> > This will make management a little more complex, but
> > I don't imagine that the
> > situation of having the number of SE Linux
> > identities approaching the number
> > of Unix accounts will be common.
>
> That's handy.
>
> > I expect that in
> > most real systems they
> > usually choose a category of access to grant each
> > user as assigning access
> > individually to each user is more effort.
>
> I'm not sure I understand your meaning.

In a company you will have an administrator, department heads, and within each 
department you will have access granted to middle managers and non-managers.  
The access granted to non-management employees will be the same for large 
numbers of employees.  If each middle manager is given a different category 
for them and their staff then the number of different sets of access rights 
will be 2*(number of middle managers)+(number of senior managers).  In such a 
scheme all managers would need separate entries in the users file and all 
non-managers would be mapped into a group depending on who they report to.

> > For the case where each Unix user has a discrete set
> > of access rights the
> > administrator would just do exactly what they do
> > today.
>
> Well, they need to add the MLS charactoristics.

Yes, but let's not get hung up on that.  We are talking about what has to be 
done to manage users.

At the moment with the strict policy you have to add a line to the users file 
and recompile and load the policy.  With MLS the operation is essentially the 
same, you just need some extra data in the line added to the users file.

> > Their security
> > policy merely prevents them from taking advantage of
> > the new feature which we
> > are designing.
>
> This I don't understand 'tall.

If the organization policy requires that each Unix user has a separate set of 
SE Linux access rights then every time a Unix user is added a change will 
have to be made to the SE Linux policy database on every machine.  The new 
feature is designed to dramatically reduce the number of changes to the 
policy database, but it won't be useful for everyone.  It should be a no-cost 
option though so anyone who doesn't want it can just not use it.

> > It's not a problem of the feature,
> > just a fact that it won't
> > be useful for everyone.
> >
> > Although there is something to be said for using GID
> > numbers.
>
> Agreed in practice if not principle.

Absolutely.  Using GID numbers sucks badly, and I am not seriously pushing for 
using it.  Just noting the fact that group names have some potential issues.  
But I guess we can just say "don't do that".  The groupadd program refuses to 
create such groups, so you have to use vigr to add them and then the groupdel 
program won't remove any of the groups in question if the GID is the primary 
GID for some user.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Casey Schaufler]

--- Russell Coker <russell@coker.com.au> wrote:

 > It's not the number of policies, but the number of
> MLS category combinations 
> that may be used.  We have 10 sensitivity levels in
> the default MLS policy at 
> the moment and 128 categories.  Therefore there are
> 10*2^128 possible MLS 
> combinations that may be assigned to a user
> identity.

In the 15 years I've been dealing with MLS systems I
have never seen anyone encounter the problems of
category permutations. A given user will be in a
single
category, and usually a single level. In truth, a site
will usually use levels or catagories, but almost
never
both. Further, a given site will usually use
system-high,
system-low, and two or three others.

>  Naturally a single 
> policy won't contain a small fraction of them, but
> it's still likely to 
> contain a much larger number of combinations than
> with the strict policy 
> which only has membership of three roles (of which
> only five combinations are 
> sensible).
> 
> > I said that I wouldn't do that.
> > I am curious how MLS is going to interact with the
> > rest of the policy rules.
> 
> But surely that has nothing to do with the issue of
> mapping Unix account names 
> to SE Linux access which is the topic of this
> thread.

Okay, if you say so, I'll believe you. I really can't
say  that I understand the intended implementation
well enough to come to that conclusion. That's
why I asked.


> > I'm not sure I understand your meaning.
> 
> In a company you will have an administrator,
> department heads, and within each 
> department you will have access granted to middle
> managers and non-managers.  
> The access granted to non-management employees will
> be the same for large 
> numbers of employees.  If each middle manager is
> given a different category 
> for them and their staff then the number of
> different sets of access rights 
> will be 2*(number of middle managers)+(number of
> senior managers).  In such a 
> scheme all managers would need separate entries in
> the users file and all 
> non-managers would be mapped into a group depending
> on who they report to.

Yes, I can see how that might result in issues.
I'll refer back to the marketplace experience, which
indicates that it is not likely you will see MLS taken
advantage of to this granularity.
 
> > Well, they need to add the MLS charactoristics.
> 
> Yes, but let's not get hung up on that.  We are
> talking about what has to be 
> done to manage users.

Of course. Users with a degenerate clearance (one MLS
level+category-set) are strait forward. Users with
large
or discontiguous clearance (six levels and multiple
categories, with combinations) may require more
attention, especially regrading home directories and
mailboxes.

> At the moment with the strict policy you have to add
> a line to the users file 
> and recompile and load the policy.  With MLS the
> operation is essentially the 
> same, you just need some extra data in the line
> added to the users file.

That's reassuring.

> > This I don't understand 'tall.
> 
> If the organization policy requires that each Unix
> user has a separate set of 
> SE Linux access rights then every time a Unix user
> is added a change will 
> have to be made to the SE Linux policy database on
> every machine.  The new 
> feature is designed to dramatically reduce the
> number of changes to the 
> policy database, but it won't be useful for
> everyone.  It should be a no-cost 
> option though so anyone who doesn't want it can just
> not use it.

Where the feature is MLS, right?

> > Agreed in practice if not principle.
> 
> Absolutely.  Using GID numbers sucks badly, and I am
> not seriously pushing for 
> using it.  Just noting the fact that group names
> have some potential issues.  
> But I guess we can just say "don't do that".  The
> groupadd program refuses to 
> create such groups, so you have to use vigr to add
> them and then the groupdel 
> program won't remove any of the groups in question
> if the GID is the primary 
> GID for some user.

Anyhow, thanks for the clarifications. I'm still
trying to
wrap my brittle old whits around the SELinux MLS
implementation.




Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
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: Alternative user management approach

[Russell Coker]

On Tuesday 28 June 2005 01:32, Casey Schaufler <casey@schaufler-ca.com> wrote:
> > MLS category combinations
> > that may be used.  We have 10 sensitivity levels in
> > the default MLS policy at
> > the moment and 128 categories.  Therefore there are
> > 10*2^128 possible MLS
> > combinations that may be assigned to a user
> > identity.
>
> In the 15 years I've been dealing with MLS systems I
> have never seen anyone encounter the problems of
> category permutations. A given user will be in a
> single
> category, and usually a single level. In truth, a site
> will usually use levels or catagories, but almost
> never
> both. Further, a given site will usually use
> system-high,
> system-low, and two or three others.

That will make things easier for us.

> > senior managers).  In such a
> > scheme all managers would need separate entries in
> > the users file and all
> > non-managers would be mapped into a group depending
> > on who they report to.
>
> Yes, I can see how that might result in issues.
> I'll refer back to the marketplace experience, which
> indicates that it is not likely you will see MLS taken
> advantage of to this granularity.

That's interesting to know.

> > > Well, they need to add the MLS charactoristics.
> >
> > Yes, but let's not get hung up on that.  We are
> > talking about what has to be
> > done to manage users.
>
> Of course. Users with a degenerate clearance (one MLS
> level+category-set) are strait forward. Users with
> large
> or discontiguous clearance (six levels and multiple
> categories, with combinations) may require more
> attention, especially regrading home directories and
> mailboxes.

Yes, home directory labeling for users with multiple clearance levels will be 
an issue.

> > > This I don't understand 'tall.
> >
> > If the organization policy requires that each Unix
> > user has a separate set of
> > SE Linux access rights then every time a Unix user
> > is added a change will
> > have to be made to the SE Linux policy database on
> > every machine.  The new
> > feature is designed to dramatically reduce the
> > number of changes to the
> > policy database, but it won't be useful for
> > everyone.  It should be a no-cost
> > option though so anyone who doesn't want it can just
> > not use it.
>
> Where the feature is MLS, right?

In the context of this discussion when I say "the new feature" I mean the 
ability to have arbitrary mappings between Unix user-names and SE Linux 
identities.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Frank Mayer]

>> In the 15 years I've been dealing with MLS systems I have never seen
>> anyone encounter the problems of category permutations. A given user
>> will be in a single category, and usually a single level. In truth, a
>> site will usually use levels or catagories, but almost never both.
>> Further, a given site will usually use system-high, system-low, and
>> two or three others.
> 
> That will make things easier for us.

The problem is building a general mechanism that can handle nearly any
situation. I agree that over the past 20+ years, most MLS applications I've
seen use a small portion of the possible lattice supported. However they use
differing portions. And some applications, in particular compartmented mode
applications, can use many categories with the potential for a large number
of points in the lattice being assigned to specific users. Worse users can
be granted and removed access to lattice points (i.e., categories) now and
then. 

Nonetheless I agree with Steve's earlier suggestions that we just have to
figure a way to build a number of "roles mapping users", potentially on the
fly, to account for any set of levels that a site may want to assign to a
user. MLS will be a small % of the SELinux systems used, and a small % of
those will use more than a few security levels. Most of the traditional uses
of MLS systems are better addressed by type enforcement, as our application
experience shows us every day. So a little pain for MLS SELinux boxes is not
unjustified for increased benefit of our suggested new user management
approach IMHO. Frank



--
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: Alternative user management approach

[Casey Schaufler]

--- Frank Mayer <mayerf@tresys.com> wrote:


> The problem is building a general mechanism that can
> handle nearly any situation.

It usually is. I wanted to point out particulars that
might
help out when y'all are making some of those tougher
tradeoff decisions.

> I agree that over the past 20+ years,
> most MLS applications I've
> seen use a small portion of the possible lattice
> supported. However they use
> differing portions.

Yes, that's true. The Military tends to use levels,
while
civilian supercomputer sites use categories. I can't
recall
a single instance where both were used on the same
site.

> And some applications, in
> particular compartmented mode
> applications, can use many categories with the
> potential for a large number
> of points in the lattice being assigned to specific
> users. Worse users can
> be granted and removed access to lattice points
> (i.e., categories) now and
> then. 

I have rarely seen anyone in more than one category
at a time.

> Nonetheless I agree with Steve's earlier suggestions
> that we just have to
> figure a way to build a number of "roles mapping
> users", potentially on the
> fly, to account for any set of levels that a site
> may want to assign to a
> user. 

I think that I like the concept. It may have other
applications for policy simplification as well.

> MLS will be a small % of the SELinux systems
> used, and a small % of
> those will use more than a few security levels.

It was a glorious day when MLS made the
transition from Lunitic Fringe to Fringe.

> Most of the traditional uses
> of MLS systems are better addressed by type
> enforcement, as our application
> experience shows us every day.

I don't buy that yet, but I'm willing to
leave open the possibility that it could
be true.

> So a little pain for
> MLS SELinux boxes is not
> unjustified for increased benefit of our suggested
> new user management
> approach IMHO. Frank

If y'all can keep it to a "little" pain
I doubt you'll see many complaints.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
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: Alternative user management approach

[Russell Coker]

On Saturday 25 June 2005 04:41, "Karl MacMillan" <kmacmillan@tresys.com> 
wrote:
> > Is the user info used for anything besides rbac?
> > I don't think it is...
>
> It can be used for constraints. There have been some suggested uses for
> this, but none are currently implemented in real policies. User separation
> seems better left to DAC.

Currently the identity is only really used for constraints on file relabeling.

Some people were talking on #selinux about using constraints to restrict the 
ability to see processes in "ps" output based on role, if that was 
implemented then it seems a natural extension to add an identity check at the 
same time.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Alternative user management approach

[Ivan Gyurdiev]

> 1) Reloading the kernel policy on user change just seems . . . wrong.
> 2) Having the users in the kernel can be problematic for large numbers of users.
> 3) These problems get much worse if we are talking about large, distributed user
> databases. Are sites with 10,000 users going to force a policy reload on every
> machine every time a user is added? Are all 10,000 users going to be stored in
> the kernel?

> Normal Linux users are then mapped to user roles by username or group membership
> (this should be done by libselinux and not involve the kernel). For example, if
> the primary group of the user is wheel then they could be assigned to staff,
> root assigned to sysadm, and everyone else to normal. This makes the addition of
> a user roughly equivalent to adding roles - something done by a policy developer
> that does not need to be done as part of normal system administration.

So you're taking away the sysadmin's ability to define fine-grained
role membership, and replace it with giving the sysadmin the ability
to define coarse-grained "role class" membership, and each "role class"
is determined by the policy developer...hmm 

Not sure I like this...although I see the scalability concern.



--
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: Alternative user management approach

[Ivan Gyurdiev]

On Fri, 2005-06-24 at 14:10 -0400, Ivan Gyurdiev wrote:
> > 1) Reloading the kernel policy on user change just seems . . . wrong.
> > 2) Having the users in the kernel can be problematic for large numbers of users.
> > 3) These problems get much worse if we are talking about large, distributed user
> > databases. Are sites with 10,000 users going to force a policy reload on every
> > machine every time a user is added? Are all 10,000 users going to be stored in
> > the kernel?
> 
> > Normal Linux users are then mapped to user roles by username or group membership
> > (this should be done by libselinux and not involve the kernel). For example, if
> > the primary group of the user is wheel then they could be assigned to staff,
> > root assigned to sysadm, and everyone else to normal. This makes the addition of
> > a user roughly equivalent to adding roles - something done by a policy developer
> > that does not need to be done as part of normal system administration.
> 
> So you're taking away the sysadmin's ability to define fine-grained
> role membership, and replace it with giving the sysadmin the ability
> to define coarse-grained "role class" membership, and each "role class"
> is determined by the policy developer...hmm 
> 
> Not sure I like this...although I see the scalability concern.

Also, what's to stop you from implementing this with the current
mechanism?

The "role class" could be the SElinux user. 

Then useradd could be changed to only reload policy if you're adding
new SElinux users ("role classes"). Better - useradd would stay
unchanged, and a new application would be written called
classadd or something.

Then you'd still need to map users to their SELinux users/classes
though..


--
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: Alternative user management approach

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 24, 2005 2:29 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov
> Subject: Re: Alternative user management approach
> 
> On Fri, 2005-06-24 at 14:10 -0400, Ivan Gyurdiev wrote:
> > > 1) Reloading the kernel policy on user change just seems . . . wrong.
> > > 2) Having the users in the kernel can be problematic for large numbers of
> users.
> > > 3) These problems get much worse if we are talking about large,
> distributed user
> > > databases. Are sites with 10,000 users going to force a policy reload on
> every
> > > machine every time a user is added? Are all 10,000 users going to be
> stored in
> > > the kernel?
> >
> > > Normal Linux users are then mapped to user roles by username or group
> membership
> > > (this should be done by libselinux and not involve the kernel). For
> example, if
> > > the primary group of the user is wheel then they could be assigned to
> staff,
> > > root assigned to sysadm, and everyone else to normal. This makes the
> addition of
> > > a user roughly equivalent to adding roles - something done by a policy
> developer
> > > that does not need to be done as part of normal system administration.
> >
> > So you're taking away the sysadmin's ability to define fine-grained
> > role membership, and replace it with giving the sysadmin the ability
> > to define coarse-grained "role class" membership, and each "role class"
> > is determined by the policy developer...hmm
> >
> > Not sure I like this...although I see the scalability concern.
> 
> Also, what's to stop you from implementing this with the current
> mechanism?
> 
> The "role class" could be the SElinux user.
> 
> Then useradd could be changed to only reload policy if you're adding
> new SElinux users ("role classes"). Better - useradd would stay
> unchanged, and a new application would be written called
> classadd or something.
> 

That sounds good to me, actually. No need to remove the local.users
infrastructure - we can just use it for the role users.

> Then you'd still need to map users to their SELinux users/classes
> though..

Which will be done by login processes through libselinux. Haven't looked, but it
may not even need an api change.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Alternative user management approach

[Ivan Gyurdiev]

cc-ed Dan Walsh...

Please take a look at this proposal.
The suggestion is that we use more generic "SELinux users"
instead of creating an selinux user for every user.

> > Also, what's to stop you from implementing this with the current
> > mechanism?
> > 
> > The "role class" could be the SElinux user.
> > 
> > Then useradd could be changed to only reload policy if you're adding
> > new SElinux users ("role classes"). Better - useradd would stay
> > unchanged, and a new application would be written called
> > classadd or something.
> > 
> 
> That sounds good to me, actually. No need to remove the local.users
> infrastructure - we can just use it for the role users.
> 
> > Then you'd still need to map users to their SELinux users/classes
> > though..
> 
> Which will be done by login processes through libselinux. Haven't looked, but it
> may not even need an api change.

How exactly would this be done.
Currently there's a 1:1 maping from user to selinux user. I assumed this
is hardcoded - is this not the case? I'm not sure what login utilities
do..

If it is hardcoded, it needs to
be made configurable, and integrated w/ useradd utilities.


--
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 14:52 -0400, Ivan Gyurdiev wrote:
> How exactly would this be done.
> Currently there's a 1:1 maping from user to selinux user. I assumed this
> is hardcoded - is this not the case? I'm not sure what login utilities
> do..
> 
> If it is hardcoded, it needs to
> be made configurable, and integrated w/ useradd utilities.

It is handled by libselinux get_ordered_context_list(3), which first
attempts to obtain a list of reachable security contexts for the user,
and if that fails (due to the user not being defined in the policy), it
falls back to user_u as the default.  So you just need to implement the
user mapping logic in that function based on some new config file, and
adjust a few programs that explicitly try to use or manipulate SELinux
user identity.  The latter includes:
- newrole, run_init (try to re-authenticate the user based on the
SELinux user identity rather than the Linux uid, should be changed to
use the audit uid if possible),
- sudo, usermode (try to transition to a security context for "root").
In general, we need to reconsider how su/sudo/userhelper work in this
environment.  Original SELinux kept su and newrole as separate,
independent steps with su only dealing with Linux uid, not context, and
newrole preserving the user identity across role changes.  Fedora
integrated user context transitions into su (via pam_selinux), sudo, and
userhelper. 

-- 
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 14:36 -0400, Karl MacMillan wrote:
> Which will be done by login processes through libselinux. Haven't looked, but it
> may not even need an api change.

get_ordered_context_list(3) and friends.  login and su use
get_ordered_context_list(3) via pam_selinux.
Most other programs just use get_default_context(3), which is
implemented internally via get_ordered_context_list(3), just taking the
first one.  sshd also uses get_default_context_with_role(3) if a role
was specified, which just takes the first one with a matching role if it
exists.

In each case, the input is just the Linux username, and it returns the
security context(s) to use for the user's process.  You'd have to
internally determine the group set if you wanted to base decisions on
that as well.

-- 
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: Alternative user management approach

[Ivan Gyurdiev]

On Fri, 2005-06-24 at 15:01 -0400, Stephen Smalley wrote:
> On Fri, 2005-06-24 at 14:36 -0400, Karl MacMillan wrote:
> > Which will be done by login processes through libselinux. Haven't looked, but it
> > may not even need an api change.
> 
> get_ordered_context_list(3) and friends.  login and su use
> get_ordered_context_list(3) via pam_selinux.
> Most other programs just use get_default_context(3), which is
> implemented internally via get_ordered_context_list(3), just taking the
> first one.  sshd also uses get_default_context_with_role(3) if a role
> was specified, which just takes the first one with a matching role if it
> exists.
> 
> In each case, the input is just the Linux username, and it returns the
> security context(s) to use for the user's process.  You'd have to
> internally determine the group set if you wanted to base decisions on
> that as well.

So... would this be accomplished by changing security_compute_user
to map between DAC uid and selinux uid before writing
to /selinux/user ?

Where would the remap occur...



--
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 15:21 -0400, Ivan Gyurdiev wrote:
> So... would this be accomplished by changing security_compute_user
> to map between DAC uid and selinux uid before writing
> to /selinux/user ?
> 
> Where would the remap occur...

In get_ordered_context_list, prior to calling security_compute_user.
get_ordered_context_list would look up the username (or some combination
of the username and its associated group set) in the new config file to
find the SELinux username aka role class, and then call
security_compute_user with that role class.  You'd then drop the
hardcoded fallback to SELINUX_DEFAULTUSER aka user_u, as that could be
specified in the config file instead.

-- 
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: Alternative user management approach

[Stephen Smalley]

On Fri, 2005-06-24 at 12:02 -0400, Karl MacMillan wrote:
> This makes the SELinux user more what we are calling a 'user role'. For example,
> the policy could create 3 user roles with different role authorizations (which
> become 'role capabilities'):
> 
> user role		role capabilities
> ------------------------------------
> normal		user_r
> staff			staff_r sysadm_r
> sysadm		sysadm_r
> 
> Normal Linux users are then mapped to user roles by username or group membership
> (this should be done by libselinux and not involve the kernel). For example, if
> the primary group of the user is wheel then they could be assigned to staff,
> root assigned to sysadm, and everyone else to normal. This makes the addition of
> a user roughly equivalent to adding roles - something done by a policy developer
> that does not need to be done as part of normal system administration.

Yes, the idea of performing generalized user mapping in libselinux has
been suggested previously on the list.  One concern we had with it
originally was that the SELinux user identity provided stronger
accountability than the Linux uid, but the audit uid can serve that
purpose now, and you are still using the SELinux user identity aka "user
role" (likely to create confusion due with SELinux roles, maybe role
group or role set) above to bound the possible range of reachable
SELinux roles aka "role capabilities" (likely to create confusion with
POSIX/Linux capabilities) for programs like newrole (although how
su/sudo/userhelper fit into this new scheme remains unclear).  So I
agree that this makes sense.

-- 
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: Alternative user management approach

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Friday, June 24, 2005 2:20 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov
> Subject: Re: Alternative user management approach
> 
> On Fri, 2005-06-24 at 12:02 -0400, Karl MacMillan wrote:
> > This makes the SELinux user more what we are calling a 'user role'. For
> example,
> > the policy could create 3 user roles with different role authorizations
> (which
> > become 'role capabilities'):
> >
> > user role		role capabilities
> > ------------------------------------
> > normal		user_r
> > staff			staff_r sysadm_r
> > sysadm		sysadm_r
> >
> > Normal Linux users are then mapped to user roles by username or group
> membership
> > (this should be done by libselinux and not involve the kernel). For example,
> if
> > the primary group of the user is wheel then they could be assigned to staff,
> > root assigned to sysadm, and everyone else to normal. This makes the
> addition of
> > a user roughly equivalent to adding roles - something done by a policy
> developer
> > that does not need to be done as part of normal system administration.
> 
> Yes, the idea of performing generalized user mapping in libselinux has
> been suggested previously on the list.  One concern we had with it
> originally was that the SELinux user identity provided stronger
> accountability than the Linux uid, but the audit uid can serve that
> purpose now, and you are still using the SELinux user identity aka "user
> role" (likely to create confusion due with SELinux roles, maybe role
> group or role set) above to bound the possible range of reachable
> SELinux roles aka "role capabilities" (likely to create confusion with
> POSIX/Linux capabilities) for programs like newrole (although how
> su/sudo/userhelper fit into this new scheme remains unclear).  So I
> agree that this makes sense.
> 

No idea about better names, though I agree that both are prone to confusion.
Anyone have any ideas?

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> --
> 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: Alternative user management approach

[Chad Hanson]

First, I would like to state a method for limiting the need to reload the
policy and make it work in a distributed environment is certainly needed.

> 
> The problem is building a general mechanism that can handle nearly any
> situation. I agree that over the past 20+ years, most MLS applications
I've
> seen use a small portion of the possible lattice supported. 

It is true that a small subset of labels are used in a number of
environments, there are special cases where people create and use dynamic
labels on the fly thus utilizing a large number of categories.


> However they use differing portions. And some applications, in particular 
> compartmented mode applications, can use many categories with the
potential for 
> a large number of points in the lattice being assigned to specific users. 
> Worse users can be granted and removed access to lattice points (i.e., 
> categories) now and then. 
> 

It is very true that different user's will have different clearances.
Depending on the number of levels (usually a couple) and categories (can
vary from a few to many) you could require alot of different combinations. 

Another factor in the potential increase of mappings would the increased use
of roles. Currently, their use is very limited, but if you increase the
roles to allow users to perform different actions, you increase the number
of combinations as well. 

-Chad

--
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.