Groups in the alternative user solution

Groups in the alternative user solution

[Ivan Gyurdiev]

So, how will groups work.

In particular,

a user belongs to multiple groups, each of which
may have a selinux user mapping, in addition to
the user herself possibly having a corresponding
selinux user. Also, there's the default mapping.

- How should the selection work?
- What would be the useradd interface for mapping
a user to a selinux user?
- What would be the interface for mapping a group
to a selinux user?





--
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: Groups in the alternative user solution

[Stephen Smalley]

On Tue, 2005-06-28 at 13:34 -0400, Ivan Gyurdiev wrote:
> So, how will groups work.
> 
> In particular,
> 
> a user belongs to multiple groups, each of which
> may have a selinux user mapping, in addition to
> the user herself possibly having a corresponding
> selinux user. Also, there's the default mapping.
> 
> - How should the selection work?
> - What would be the useradd interface for mapping
> a user to a selinux user?
> - What would be the interface for mapping a group
> to a selinux user?

I'd actually suggest that we not try to map Unix/Linux groups to SELinux
users at all, and require explicit Linux user -> SELinux user mappings.
Unix groups and SELinux user identities serve very different purposes,
and I can't see a good reason to link them together (and definite danger
in doing so).  Better to require them to manage that mapping
separately.  

-- 
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: Groups in the alternative user solution

[Ivan Gyurdiev]

> I'd actually suggest that we not try to map Unix/Linux groups to SELinux
> users at all, and require explicit Linux user -> SELinux user mappings.
> Unix groups and SELinux user identities serve very different purposes,

I thought they both served the purpose of grouping together
things that should have the same security properties, and 
isolating things that should have different ones.

> and I can't see a good reason to link them together (and definite danger
> in doing so).

Why is that?

>   Better to require them to manage that mapping
> separately.  

Well, that's certainly the easier approach...



--
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: Groups in the alternative user solution

[Stephen Smalley]

On Tue, 2005-06-28 at 15:50 -0400, Ivan Gyurdiev wrote:
> > I'd actually suggest that we not try to map Unix/Linux groups to SELinux
> > users at all, and require explicit Linux user -> SELinux user mappings.
> > Unix groups and SELinux user identities serve very different purposes,
> 
> I thought they both served the purpose of grouping together
> things that should have the same security properties, and 
> isolating things that should have different ones.

Groups are still fundamentally discretionary (group membership is
usually administratively-defined, but assigning group ownership or group
ACLs to files is at the discretion of the user or any program he runs).

> > and I can't see a good reason to link them together (and definite danger
> > in doing so).
> 
> Why is that?

Because people are already using groups for a variety of purposes, and
will tend to just re-use existing groups and map them onto SELinux user
identities/roles blindly without really considering what is appropriate,
e.g. the assumption that everyone in group wheel should be mapped to
staff/sysadm is dangerous.

> >   Better to require them to manage that mapping
> > separately.  
> 
> Well, that's certainly the easier approach...

Yes.  Of course, ultimately such a mapping has to allow for distributed
management too.

-- 
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: Groups in the alternative user solution

[Ivan Gyurdiev]

> Groups are still fundamentally discretionary (group membership is
> usually administratively-defined, but assigning group ownership or group
> ACLs to files is at the discretion of the user or any program he runs).

Yes, but assigning group ownership to files does not translate to
the selinux user corresponding to that group getting access to the
files... Essentially the same group maps to both MAC and DAC access
control.

That groups are already used for various purposes seems beneficial to me
- you can refit your existing grouping system to deal with SELinux
without going through each user individually.

It's true that your group requirements for DAC may not be the same
as for selinux... but we don't know if that's the case.

> > >   Better to require them to manage that mapping
> > > separately.  
> > 
> > Well, that's certainly the easier approach...
> 
> Yes.  Of course, ultimately such a mapping has to allow for distributed
> management too.

That requires writing a different backend for manging those records.
How would the interface work for this - would the caller have to specify
backend, or would the selinux library determine what's appropriate?


--
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: Groups in the alternative user solution

[Stephen Smalley]

On Wed, 2005-06-29 at 11:05 -0400, Ivan Gyurdiev wrote:
> Yes, but assigning group ownership to files does not translate to
> the selinux user corresponding to that group getting access to the
> files... Essentially the same group maps to both MAC and DAC access
> control.

Right, such overloading could yield confusion and improper granting of
MAC access.  That's my concern.

> That groups are already used for various purposes seems beneficial to me
> - you can refit your existing grouping system to deal with SELinux
> without going through each user individually.

Possibly.  More likely you will just map whatever groups you already
have defined to SELinux.

> It's true that your group requirements for DAC may not be the same
> as for selinux... but we don't know if that's the case.

Seems unlikely to me, given the difference between DAC and MAC.
But I'm open to other opinions on the subject.

> That requires writing a different backend for manging those records.
> How would the interface work for this - would the caller have to specify
> backend, or would the selinux library determine what's appropriate?

Ideally libselinux would hide it, much as existing interfaces for
looking up users, groups, and hosts hide what backend is used to obtain
that information.  Another service in /etc/nsswitch.conf?

-- 
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: Groups in the alternative user solution

[Ivan Gyurdiev]

> Seems unlikely to me, given the difference between DAC and MAC.
> But I'm open to other opinions on the subject.

What about Casey's suggestion in this thread:

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

Not sure I understand... 
So if Fred is in more groups other than wheel, 
he maps to normal? What's the rationale for that?
Controlling information disclosure? Does that * 
take precedence to fred? What about conflicts? 
This seems complicated..

============

Should this idea be dropped? More opinions?




--
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: Groups in the alternative user solution

[Stephen Smalley]

On Thu, 2005-06-30 at 09:27 -0400, Ivan Gyurdiev wrote:
> What about Casey's suggestion in this thread:
> 
> > 
> >     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.
> 
> Not sure I understand... 
> So if Fred is in more groups other than wheel, 
> he maps to normal? What's the rationale for that?

I didn't understand the reasoning there either, particularly as we
aren't dealing with the effective GID but the entire authorized group
list for the user since we are only doing this once at login/su time.

> Controlling information disclosure? Does that * 
> take precedence to fred? What about conflicts? 
> This seems complicated..

I was originally thinking more along the lines of just selecting the
first matching entry (order-dependent), and group match just required
membership in the listed group, not an exact match (if you are going to
support group-based matching).

-- 
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: Groups in the alternative user solution

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Thu, 2005-06-30 at 09:27 -0400, Ivan Gyurdiev
> wrote:
> > What about Casey's suggestion in this thread:
> > 
> > > 
> > >     root:*:sysadm
> > >     fred:wheel:wand
> > >     *:wheel:staff
> > >     *:*:normal

Since this small example led to confusion
in great minds, let me expand a touch.

Let's say that Fred is allowed groups:
    wheel,lever,pulley
And Barney is allowed groups:
    hoop,stick,gameboy

    root:*:sysadm
    fred:wheel:wand
    fred:wheel,lever:sword
    fred:wheel,pulley:sword
    fred:wheel,pulley,lever:blunderbus
    fred:pulley,lever:dagger
    fred:pulley:club
    fred:lever:club
    barney:hoop,stick,gameboy:gamer
    barney:stick:player
    barney:*:bored
    *:wheel:staff
    *.*:normal

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

> > Not sure I understand... 
> > So if Fred is in more groups other than wheel, 
> > he maps to normal? What's the rationale for that?

If there is an entry that exactly
matches it is used. In the revised
list above all the permutations of
Fred's group lists are explicitly
defined. For Fred, it is not ambiguous.
Barney has two entries that are exact
and one with a wildcard for the group.
If Barney is in all three of his groups
he gets one context, if in exactly the
one specified group he gets another,
and a third in all other cases.

> I didn't understand the reasoning there either,
> particularly as we
> aren't dealing with the effective GID but the entire
> authorized group
> list for the user since we are only doing this once
> at login/su time.

I hope this has clarified the group vs.
group list confusion.
 
> > Controlling information disclosure? Does that * 
> > take precedence to fred? What about conflicts? 
> > This seems complicated..

I don't think there are any conflicts.
If you have an exact match, you
use it. Otherwise if there is a match
on the UID and a wildcard match
for the group, you use that. If there
is no UID match but a group list
match you use that.

The same mindset as POSIX ACLs.




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: Groups in the alternative user solution

[Ivan Gyurdiev]

> > I didn't understand the reasoning there either,
> > particularly as we
> > aren't dealing with the effective GID but the entire
> > authorized group
> > list for the user since we are only doing this once
> > at login/su time.
> 
> I hope this has clarified the group vs.
> group list confusion.

Yes, I understand how it would work.
What's not clear is why you want to match on group
list as opposed to matching on group membership alone.
How is that helpful to the sysadmin - seems awfully 
fragile. What happens to this file if I add the user 
to another group?




--
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: Groups in the alternative user solution

[Casey Schaufler]

--- Ivan Gyurdiev <gyurdiev@redhat.com> wrote:

> 
> > > I didn't understand the reasoning there either,
> > > particularly as we
> > > aren't dealing with the effective GID but the
> entire
> > > authorized group
> > > list for the user since we are only doing this
> once
> > > at login/su time.
> > 
> > I hope this has clarified the group vs.
> > group list confusion.
> 
> Yes, I understand how it would work.
> What's not clear is why you want to match on group
> list as opposed to matching on group membership
> alone.

The question with multiple concurrent
groups has always been "which group?".
In the example of Fred you have to
ask if, from a security perspective,
Fred,wheel is the same as Fred,lever
or Fred,wheel,lever. Strictly speaking
the answer is no. Now, is the difference
significant in the SELinux context?
In Unix MLS systems (except for
SystemV/MLS) clearances are
associated only with users and the
group is completely ignored. 
But the Unix MLS systems make
no attempt at the wholistic
user/application/data/transform
worldview of domain enforcement.

> How is that helpful to the sysadmin - seems awfully 
> fragile. What happens to this file if I add the user
> to another group?

That's one good reason for the wildcards.

I don't know that the scheme I
suggests solves all or even any
of the problems. Use it or not.



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: Groups in the alternative user solution

[Daniel J Walsh]

Ok we are actually  trying to code something up to deal with this 
discussion.  This is our current thoughts on
handling users.  We have not come to a decent way of handling 
file_contexts.    We are attempting in this
example to limit the number of file_context/user files.

Example policy for a hospital would have 5 types of SELinux users.

cat /etc/selinux/strict/users/local.users
user doctor_u { user_r nurse_r labtech_r doctor_r };
user labtech_u { user_r labtech_r };
user nurse_u { user_r nurse_r };
user user_u { user_r };
user staff_u { staff_r sysadm_r secadm_r };


Then we create a file called map.users

cat /etc/selinux/strict/users/map.users
staff_u: dwalsh,ivan
doctor_u: green,welby,spock
nurse_u: cratchet,nightengale
labtech_u: grissom
user_u:  *


As far as file_context files are concerned, only dwalsh and ivan would 
need to
have user specific file_context.homedir files be created, since all 
other users
on the system would map to the "user" type.

Some how we need to make the system smart enough to know that SELINUX 
Users map
to a default role/type;

So when "grissom" logs in his id -Z will show

labtech_u:user_r:user_t

He then can:

newrole -r labtech_r

And can run labtech applications.

Dr. Green would login as

doctor_u:user_r:user_t

He could then run newrole and change to any of doctor_r, nurse_r, or 
labtech_r
and run the associated applications.

The only time home directory file context would need to change would be 
if the
user became an admin.

This would potentially eliminate the 1000's of file contexts files problem,
since almost all users would map to the default user_r and user_home_t...
for his home dir file context.



-- 



--
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: Groups in the alternative user solution

[Colin Walters]

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

On Tue, 2005-07-05 at 15:15 -0400, Daniel J Walsh wrote:

> 
> This would potentially eliminate the 1000's of file contexts files problem,
> since almost all users would map to the default user_r and user_home_t...
> for his home dir file context.

But isn't a large part of the point of this to ensure that e.g. grissom
can never access medical records stored in welby's home directory, even
if welby accidentally sets the DAC permissions to allow it?  Or is
something else in this scheme preventing that?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Groups in the alternative user solution

[Daniel J Walsh]

Colin Walters wrote:

>On Tue, 2005-07-05 at 15:15 -0400, Daniel J Walsh wrote:
>
>  
>
>>This would potentially eliminate the 1000's of file contexts files problem,
>>since almost all users would map to the default user_r and user_home_t...
>>for his home dir file context.
>>    
>>
>
>But isn't a large part of the point of this to ensure that e.g. grissom
>can never access medical records stored in welby's home directory, even
>if welby accidentally sets the DAC permissions to allow it?  Or is
>something else in this scheme preventing that?
>
>  
>
I would argue that medical records should never be stored in a users 
home directory.

The idea here is that the application to view medical records would not 
be able to be run
by the ordinary user.


-- 



--
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: Groups in the alternative user solution

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Daniel J Walsh
> Sent: Tuesday, July 05, 2005 3:40 PM
> To: Colin Walters
> Cc: selinux@tycho.nsa.gov
> Subject: Re: Groups in the alternative user solution
> 
> Colin Walters wrote:
> 
> >On Tue, 2005-07-05 at 15:15 -0400, Daniel J Walsh wrote:
> >
> >
> >
> >>This would potentially eliminate the 1000's of file contexts files problem,
> >>since almost all users would map to the default user_r and user_home_t...
> >>for his home dir file context.
> >>
> >>
> >
> >But isn't a large part of the point of this to ensure that e.g. grissom
> >can never access medical records stored in welby's home directory, even
> >if welby accidentally sets the DAC permissions to allow it?  Or is
> >something else in this scheme preventing that?
> >
> >
> >
> I would argue that medical records should never be stored in a users
> home directory.
> 
> The idea here is that the application to view medical records would not
> be able to be run
> by the ordinary user.
> 

The derived home directory types are there to separate contents by role - which
seems important to me (at least today). I think that the primary reason for this
is integrity (.bashrc), but there is no reason that it can't be used for
confidentiality as well. What if that medical record viewing application can
create files in the home directory? If the home directory data is separated by
role then normal users still can't see the data from the records in the event
the viewer app incorrectly saves data to the home directory.

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.



--
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: Groups in the alternative user solution

[Daniel J Walsh]

Karl MacMillan wrote:

>>-----Original Message-----
>>From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
>>Behalf Of Daniel J Walsh
>>Sent: Tuesday, July 05, 2005 3:40 PM
>>To: Colin Walters
>>Cc: selinux@tycho.nsa.gov
>>Subject: Re: Groups in the alternative user solution
>>
>>Colin Walters wrote:
>>
>>    
>>

But this does not scale.

If the patient app is allow to write a medical record to the users 
homedir it should be labeled medical_record and not be allowed
to be viewed by the user unless he is in running the app.  This should 
not be protected by the homedir file context, it will never scale.

In the case of the doctor being able to assume multiple roles, what 
context would the patient record app write to the home dir.

RBAC being tied to TE in the homedirs is broken. 

Currently if we switch a user from user_r to staff_r, he looses access 
to all his files until a magic relabel happens.  If we allow
an expansion of roles available to the user, the problem explodes.

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: Groups in the alternative user solution

[Ivan Gyurdiev]

> The derived home directory types are there to separate contents by role - which
> seems important to me (at least today). I think that the primary reason for this
> is integrity (.bashrc), but there is no reason that it can't be used for
> confidentiality as well. What if that medical record viewing application can
> create files in the home directory? If the home directory data is separated by
> role then normal users still can't see the data from the records in the event
> the viewer app incorrectly saves data to the home directory.

I think rbac simply does not work today, because of those per role
directory types. Apps can't read .bashrc, can't read .bash_profile,
can't read .xauth files, and you end up with a nonfunctional system
if you try to manage multiple roles with the same user.



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