[RFC]{Patch 0/5] Polyinstantation

[RFC]{Patch 0/5] Polyinstantation

[Chad Sellers]

This patch us a userspace patch to provide polyinstantiation support in
SELinux.  I am including a patch to libselinux to provide this, as well
as patches to login, su, gdm, and policy to make this work.  These
patches will follow in separate emails.  Comments are appreciated
(usually, at least).

OVERVIEW
This code provides polyinstantiation support for directories in SELinux
systems.  It creates multiple instances of a directory as dictated by
policy.  These instances are actually subdirectories, named using a MD5
hash of the context of the member directory, that are used in place of
the parent directory.  To interface with policy, the code utilizes
the /selinux/member interface to read how directories should be
polyinstantiated according to policy.

In order to specify how directories should be instantiated in type
enforcement policy, a type_member rule is used.  MLS polyinstantiation
policy is implicit (i.e. the directory should be polyinstantiated to the
level of the user).  This code queries the /selinux/member interface to
see what member of a polyinstantiated directory should be used for a
given subject context.

To replace the original directory with the appropriate member directory,
per-process namespaces and bind mounts are used.  More specifically, an
entrypoint program (say login) calls this library to see if any
polyinstantiation is necessary.  If so, it calls clone() instead of fork
with the CLONE_NEWNS flag to get a new namespace.  Then, the library can
bind mount member directories over the originals.  Additionally, the
library remounts the original directory elsewhere (e.g. /tmp is
remounted to /.tmp-poly-orig) for security-aware (and allowed) programs
to utilize it.

USING THE LIBRARY
The library exports 2 functions, security_setupns(), the main function,
and security_set_setupns_printf(), a support function to change where
printf's go. security_setupns() sets up a namespace for the user being
processed.  It takes one argument - commit, which is an integer that can
be 0 or 1.  If commit=0, the function does not actually set up the
namespace, but just checks to see if any modifications to the namespace
are necessary.  If commit=1, those modifications are actually made.  The
function returns the number of changes (i.e. directories needing
polyinstantiation).  security_set_setupns_printf is used to replace the
printf function (which defaults to logging to stderr) the same way that
set_matchpathcon_printf() does.

CONFIG FILE
There is one config file, which is stored in /etc/selinux/polydirs.  The
first line contains the default context to use for directories that
originals are remounted to (e.g. /.tmp-poly-orig), which only matters
before the bind mount happens.  The rest of the file is a newline-
delimited list of candidate directories to be polyinstantiated.  Each of
these directories will be checked to see if polyinstantiation is
necessary according to the policy.  Additionally, the library supports
the special directory $HOME to indicate the home directory of the user
who's environment we're setting up.

POLICY
Policy is fairly straightforward.  Just write a type_member rule.  The
syntax is:
type_member <source type> <target type>:<target class> <member type>
<source type> is the type of the user logging in, <target type> is the
type of the directory being polyinstantiated, <target class> is dir
(since this patch only works for directories), and <member type> is what
you want the member directory context to be.  So, the rule
type_member user_t tmp_t:dir user_tmp_t
says use member directory user_tmp_t for a directory labeled tmp_t for
user_t.  Of course, for this query to take place at all, you have to
have a directory in the config file that is labeled tmp_t.
Note that you also need appropriate policy (TE allow rules and mls
priveleges) to allow programs such as login, su, and gdm to perform the
appropriate functions.  I've included a patch to policy to provide this.

BUILDING AND INSTALLING
The code is in the form of patches to the current cvs libselinux
(1.23.10-1), and the current rpms found in rawhide.  I've enclosed both
patches to source and patches to the spec files.  So, the easiest way to
install them, is to
1) Patch and rebuild your libselinux.
Build and install the SRPM -or-
tar xzf libselinux-x.y.z.tgz
cd libselinux-x.y.z
patch -p1 < libselinux-x.y.z-poly.patch
make install relabel

2) Apply the provided patch to your policy, build, and load it.
cd /etc/selinux/(strict|targeted|mls)/src/policy
patch -p1 < policy.diff
make load
Note:  This includes domains/misc/test.te, which has example type member
rules.  You may want to customize these to rules appropriate to your
install.

3) Install polydirs configuration file and edit for desired
configuration (which should match up with the type member rules above).
cp polydirs /etc/selinux/polydirs

4) Verify basic operation via setupns test utility (part of libselinux
patch).
su -
ls -al /tmp /home/<username>
setupns <username> <usercontext>
	e.g. setupns jdoe user_u:user_r:user_t
ls -al /tmp /home/<username>
cat /proc/mounts
exit
setupns -X <username> <usercontext>
ls -al /tmp /home/<username>

5) Build and install the modified util-linux, coreutils, and gdm
Build and install the SRPMs -or-
Try applying patches to source from somewhere else.  I have only tested
these patches with rawhide srpms, but they should be fairly easy to
apply to other source assuming that source already has the appropriate
SELinux patches.

6) Try logging into different roles at the console, via gdm, and using
su to switch between different users/roles, looking at your /tmp and
$HOME before and after, as well as /proc/mounts.


-- 
Chad Sellers
cdselle@tycho.nsa.gov


--
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: [RFC]{Patch 0/5] Polyinstantation

[Casey Schaufler]

--- Chad Sellers <cdselle@tycho.nsa.gov> wrote:

> This patch us a userspace patch to provide
> polyinstantiation support in
> SELinux.  ...

Clever.

Suppose a user logs in at UNCLASSIFIED (to read email)
and while she's there she looks at /tmp/foo. She
logs off, then logs in at SECRET to do some secret
work, during which she looks at (a different)
/tmp/foo. The Powers That Be later decide that
this user may have been up to no good, and want
to examine the audit trail associated with her.
How will the two instances of /tmp/foo be
differentiated in the audit trail?

In existing MLS systems many trusted programs
use "label flipping" to access resources at
multiple labels. This practice is abhorent and
decried by MLS system vendors, but common
nonetheless. These programs are going to have
trouble moving to your scheme. Not that I
think that's necessarily bad, but it will come
up as an issue because the existing MLS systems
have polyinstantiation mechanisms that handle
that case.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

--
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: [RFC]{Patch 0/5] Polyinstantation

[Janak Desai]

Casey Schaufler wrote:

> --- Chad Sellers <cdselle@tycho.nsa.gov> wrote:
> 
> 
>>This patch us a userspace patch to provide
>>polyinstantiation support in
>>SELinux.  ...
> 
> 
> Clever.
> 
> Suppose a user logs in at UNCLASSIFIED (to read email)
> and while she's there she looks at /tmp/foo. She
> logs off, then logs in at SECRET to do some secret
> work, during which she looks at (a different)
> /tmp/foo. The Powers That Be later decide that
> this user may have been up to no good, and want
> to examine the audit trail associated with her.
> How will the two instances of /tmp/foo be
> differentiated in the audit trail?
> 

In addition to the pathname, the audit record
will contain the user's sensitivity level.

> In existing MLS systems many trusted programs
> use "label flipping" to access resources at
> multiple labels. This practice is abhorent and
> decried by MLS system vendors, but common
> nonetheless. These programs are going to have
> trouble moving to your scheme. Not that I
> think that's necessarily bad, but it will come
> up as an issue because the existing MLS systems
> have polyinstantiation mechanisms that handle
> that case.
> 

-Janak



--
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: [RFC]{Patch 0/5] Polyinstantation

[Chad Sellers]

On Wed, 2005-05-11 at 10:41 -0700, Casey Schaufler wrote:
> --- Chad Sellers <cdselle@tycho.nsa.gov> wrote:
> 
> > This patch us a userspace patch to provide
> > polyinstantiation support in
> > SELinux.  ...
> 
> Clever.
> 
> Suppose a user logs in at UNCLASSIFIED (to read email)
> and while she's there she looks at /tmp/foo. She
> logs off, then logs in at SECRET to do some secret
> work, during which she looks at (a different)
> /tmp/foo. The Powers That Be later decide that
> this user may have been up to no good, and want
> to examine the audit trail associated with her.
> How will the two instances of /tmp/foo be
> differentiated in the audit trail?
> 
The two instances of /tmp/foo have different contexts (that's the
reason /tmp was polyinstantiated in the first place).  Any audit
messages (avc messages do this now) should include the context of the
file (as well as device and inode), not just the filename.  So, the two
instances can be differentiated.  Additionally, auditing based on
filename is unreliable to begin with.



> In existing MLS systems many trusted programs
> use "label flipping" to access resources at
> multiple labels. This practice is abhorent and
> decried by MLS system vendors, but common
> nonetheless. These programs are going to have
> trouble moving to your scheme. Not that I
> think that's necessarily bad, but it will come
> up as an issue because the existing MLS systems
> have polyinstantiation mechanisms that handle
> that case.
> 
I agree that this is a bad practice, but these programs could move to my
scheme.  MLS applications that use "label flipping" have to be security
aware in order to perform that flipping (meaning they have to call
security functions to flip their label).  So, they could include a call
to my library function to modify their namespace appropriately when
flipping labels.  Of course, this requires the entrypoint program
starting the application to have setup a new namespace for the
application in the first place.  If the application flips so frequently
that this affects performance, then I'd say the application is flipping
labels a little too frequently.

> 
> Casey Schaufler
> casey@schaufler-ca.com
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/ 
-- 
Chad Sellers
cdselle@tycho.nsa.gov


--
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: [RFC]{Patch 0/5] Polyinstantation

[Casey Schaufler]

--- Chad Sellers <cdselle@tycho.nsa.gov> wrote:

> The two instances of /tmp/foo have different
> contexts (that's the
> reason /tmp was polyinstantiated in the first
> place).  Any audit
> messages (avc messages do this now) should include
> the context of the
> file (as well as device and inode), not just the
> filename.  So, the two
> instances can be differentiated.  Additionally,
> auditing based on
> filename is unreliable to begin with.

So long as the mapping from context to pathname
(via the mountpoint) can be reconstructed at a
later date this ought to work fine.


> I agree that this is a bad practice, but these
> programs could move to my
> scheme.  MLS applications that use "label flipping"
> have to be security
> aware in order to perform that flipping (meaning
> they have to call
> security functions to flip their label).  So, they
> could include a call
> to my library function to modify their namespace
> appropriately when
> flipping labels.

Hum. Yes, they could do that. I don't see
such a requirement being very popular.

> Of course, this requires the
> entrypoint program
> starting the application to have setup a new
> namespace for the
> application in the first place.  If the application
> flips so frequently
> that this affects performance, then I'd say the
> application is flipping
> labels a little too frequently.

Consider a MLS version of sendmail as your worst
case scenario.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

--
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: [RFC]{Patch 0/5] Polyinstantation

[Timothy R. Chavez]

On Wednesday 11 May 2005 12:41, you wrote:

> Suppose a user logs in at UNCLASSIFIED (to read email)
> and while she's there she looks at /tmp/foo. She
> logs off, then logs in at SECRET to do some secret
> work, during which she looks at (a different)
> /tmp/foo. The Powers That Be later decide that
> this user may have been up to no good, and want
> to examine the audit trail associated with her.
> How will the two instances of /tmp/foo be
> differentiated in the audit trail?

I'm not too familiar with MLS, but is it really necessary to audit every thing 
the user is  accessing?  What if /tmp/foo maps to something uninteresting in 
both SECRET and UNCLASSIFIED, do we really care?  If /tmp/foo maps to 
something security-critical and interesting, I'd suspect it will be audited 
(irrespective of namespace, at the inode level), in which case a record will 
be generated with a security context, loginuid, etc.

-tim

--
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: [RFC]{Patch 0/5] Polyinstantation

[Casey Schaufler]

--- "Timothy R. Chavez" <tinytim@us.ibm.com> wrote:

> I'm not too familiar with MLS, but is it really
> necessary to audit every thing 
> the user is  accessing?

In the usual case accessing files in /tmp
will be completely uninteresting to any
sane security officer. In unusual cases,
or in the presence of an insane security
officer it must be possible to do so.
Polyinstantiated directories have driven
any number of otherwise rational admins
over the edge.

> What if /tmp/foo maps to
> something uninteresting in 
> both SECRET and UNCLASSIFIED, do we really care?

Nope. We don't care. The user who is being watched
may care a lot if difficulty in differentiation
lands her in jail. It can happen.

> If
> /tmp/foo maps to 
> something security-critical and interesting, I'd
> suspect it will be audited 
> (irrespective of namespace, at the inode level), in
> which case a record will 
> be generated with a security context, loginuid, etc.

This is only going to be true if it's known in
advance by the admins that /tmp/foo will contain
important stuff, and which /tmp/foo that's going
to be.


Unix MLS systems address polyinstantiated
directories in the pathname resolution code
rather than remapping process mount spaces.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

--
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: [RFC]{Patch 0/5] Polyinstantation

[Daniel J Walsh]

Chad Sellers wrote:

>This patch us a userspace patch to provide polyinstantiation support in
>SELinux.  I am including a patch to libselinux to provide this, as well
>as patches to login, su, gdm, and policy to make this work.  These
>patches will follow in separate emails.  Comments are appreciated
>(usually, at least).
>
>OVERVIEW
>This code provides polyinstantiation support for directories in SELinux
>systems.  It creates multiple instances of a directory as dictated by
>policy.  These instances are actually subdirectories, named using a MD5
>hash of the context of the member directory, that are used in place of
>the parent directory.  To interface with policy, the code utilizes
>the /selinux/member interface to read how directories should be
>polyinstantiated according to policy.
>
>In order to specify how directories should be instantiated in type
>enforcement policy, a type_member rule is used.  MLS polyinstantiation
>policy is implicit (i.e. the directory should be polyinstantiated to the
>level of the user).  This code queries the /selinux/member interface to
>see what member of a polyinstantiated directory should be used for a
>given subject context.
>
>To replace the original directory with the appropriate member directory,
>per-process namespaces and bind mounts are used.  More specifically, an
>entrypoint program (say login) calls this library to see if any
>polyinstantiation is necessary.  If so, it calls clone() instead of fork
>with the CLONE_NEWNS flag to get a new namespace.  Then, the library can
>bind mount member directories over the originals.  Additionally, the
>library remounts the original directory elsewhere (e.g. /tmp is
>remounted to /.tmp-poly-orig) for security-aware (and allowed) programs
>to utilize it.
>
>USING THE LIBRARY
>The library exports 2 functions, security_setupns(), the main function,
>and security_set_setupns_printf(), a support function to change where
>printf's go. security_setupns() sets up a namespace for the user being
>processed.  It takes one argument - commit, which is an integer that can
>be 0 or 1.  If commit=0, the function does not actually set up the
>namespace, but just checks to see if any modifications to the namespace
>are necessary.  If commit=1, those modifications are actually made.  The
>function returns the number of changes (i.e. directories needing
>polyinstantiation).  security_set_setupns_printf is used to replace the
>printf function (which defaults to logging to stderr) the same way that
>set_matchpathcon_printf() does.
>
>CONFIG FILE
>There is one config file, which is stored in /etc/selinux/polydirs.  The
>first line contains the default context to use for directories that
>originals are remounted to (e.g. /.tmp-poly-orig), which only matters
>before the bind mount happens.  The rest of the file is a newline-
>delimited list of candidate directories to be polyinstantiated.  Each of
>these directories will be checked to see if polyinstantiation is
>necessary according to the policy.  Additionally, the library supports
>the special directory $HOME to indicate the home directory of the user
>who's environment we're setting up.
>
>POLICY
>Policy is fairly straightforward.  Just write a type_member rule.  The
>syntax is:
>type_member <source type> <target type>:<target class> <member type>
><source type> is the type of the user logging in, <target type> is the
>type of the directory being polyinstantiated, <target class> is dir
>(since this patch only works for directories), and <member type> is what
>you want the member directory context to be.  So, the rule
>type_member user_t tmp_t:dir user_tmp_t
>says use member directory user_tmp_t for a directory labeled tmp_t for
>user_t.  Of course, for this query to take place at all, you have to
>have a directory in the config file that is labeled tmp_t.
>Note that you also need appropriate policy (TE allow rules and mls
>priveleges) to allow programs such as login, su, and gdm to perform the
>appropriate functions.  I've included a patch to policy to provide this.
>
>BUILDING AND INSTALLING
>The code is in the form of patches to the current cvs libselinux
>(1.23.10-1), and the current rpms found in rawhide.  I've enclosed both
>patches to source and patches to the spec files.  So, the easiest way to
>install them, is to
>1) Patch and rebuild your libselinux.
>Build and install the SRPM -or-
>tar xzf libselinux-x.y.z.tgz
>cd libselinux-x.y.z
>patch -p1 < libselinux-x.y.z-poly.patch
>make install relabel
>
>2) Apply the provided patch to your policy, build, and load it.
>cd /etc/selinux/(strict|targeted|mls)/src/policy
>patch -p1 < policy.diff
>make load
>Note:  This includes domains/misc/test.te, which has example type member
>rules.  You may want to customize these to rules appropriate to your
>install.
>
>3) Install polydirs configuration file and edit for desired
>configuration (which should match up with the type member rules above).
>cp polydirs /etc/selinux/polydirs
>
>4) Verify basic operation via setupns test utility (part of libselinux
>patch).
>su -
>ls -al /tmp /home/<username>
>setupns <username> <usercontext>
>	e.g. setupns jdoe user_u:user_r:user_t
>ls -al /tmp /home/<username>
>cat /proc/mounts
>exit
>setupns -X <username> <usercontext>
>ls -al /tmp /home/<username>
>
>5) Build and install the modified util-linux, coreutils, and gdm
>Build and install the SRPMs -or-
>Try applying patches to source from somewhere else.  I have only tested
>these patches with rawhide srpms, but they should be fairly easy to
>apply to other source assuming that source already has the appropriate
>SELinux patches.
>
>6) Try logging into different roles at the console, via gdm, and using
>su to switch between different users/roles, looking at your /tmp and
>$HOME before and after, as well as /proc/mounts.
>
>
>  
>
Why are you still sharing the /tmp directory within the same roles.  I 
think it would be preferable to
not share at all.  This would protect one user_u from another.   How are 
you handling system sockets?
/tmp/.X11-unix/
/tmp/.X0-lock
I think postrgres also puts stuff out there.


-- 



--
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: [RFC]{Patch 0/5] Polyinstantation

[Chad Sellers]

On Wed, 2005-05-11 at 16:13 -0400, Daniel J Walsh wrote:

> Why are you still sharing the /tmp directory within the same roles.  I 
> think it would be preferable to
> not share at all.  This would protect one user_u from another.   
This code does polyinstantiation by context, thereby separating one
context from another.  Are you suggesting separating entities within the
same context from one another?  Meaning that the member directory chosen
would be dependent on the source user, role, type, level, compartment,
and uid/unix username?

> How are 
> you handling system sockets?
> /tmp/.X11-unix/
> /tmp/.X0-lock
> I think postrgres also puts stuff out there.
Yes, this is a pain.  The problem with directories like /tmp and $HOME
is that they have become global dumping places.  The problem with
breaking them up is that programs use that global dumping place as a
convenient way to connect to other programs.  So, you have sockfiles and
pipes that need to persist in multiple (but not all) member directories.
The library doesn't handle this stuff, and so I handle it in the
entrypoint patches (see the gdm patch or what happens if you pass -X to
the setupns command line utility).  This is one reason that I remount
the original directory elsewhere for security-aware (and allowed) apps
to access it.  The entrypoint program (say gdm) symlinks the necessary
files into the member directory.  If unionfs gets some upstream support,
it would provide a much more elegant way to do this.

I've only patched this to make X work.  I'm sure other programs (such as
postgres) might require similar modifications in order to work.

> 
> 
-- 
Chad Sellers
cdselle@tycho.nsa.gov


--
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: [RFC]{Patch 0/5] Polyinstantation

[Daniel J Walsh]

Chad Sellers wrote:

>On Wed, 2005-05-11 at 16:13 -0400, Daniel J Walsh wrote:
>
>  
>
>>Why are you still sharing the /tmp directory within the same roles.  I 
>>think it would be preferable to
>>not share at all.  This would protect one user_u from another.   
>>    
>>
>This code does polyinstantiation by context, thereby separating one
>context from another.  Are you suggesting separating entities within the
>same context from one another?  Meaning that the member directory chosen
>would be dependent on the source user, role, type, level, compartment,
>and uid/unix username?
>  
>
Not sure what you mean by context.  Are you saying that all user_r would 
share the same /tmp?
I would prefer that the directories be separated by UID/ROLE.  One of 
the shortcomings
of SELinux is that you really do not separate users into different 
roles.  So most systems will
have only limited user roles, maybe user_r, staff_r and sysadm_r.  So if 
I give each user their
own /tmp directory, you eliminate users attacking each other, or at 
least make it more difficult.

I think the users /tmp directory should be the same for all logins.  So 
if I copy a file to /tmp
and then go to another machine and scp it off, the file will be there.   

This would then work on all Linux systems with or without SELinux and 
independant of the policy.

Dan

>  
>
>>How are 
>>you handling system sockets?
>>/tmp/.X11-unix/
>>/tmp/.X0-lock
>>I think postrgres also puts stuff out there.
>>    
>>
>Yes, this is a pain.  The problem with directories like /tmp and $HOME
>is that they have become global dumping places.  The problem with
>breaking them up is that programs use that global dumping place as a
>convenient way to connect to other programs.  So, you have sockfiles and
>pipes that need to persist in multiple (but not all) member directories.
>The library doesn't handle this stuff, and so I handle it in the
>entrypoint patches (see the gdm patch or what happens if you pass -X to
>the setupns command line utility).  This is one reason that I remount
>the original directory elsewhere for security-aware (and allowed) apps
>to access it.  The entrypoint program (say gdm) symlinks the necessary
>files into the member directory.  If unionfs gets some upstream support,
>it would provide a much more elegant way to do this.
>
>I've only patched this to make X work.  I'm sure other programs (such as
>postgres) might require similar modifications in order to work.
>
>  
>
>>    
>>


-- 



--
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: [selinux] [RFC]{Patch 0/5] Polyinstantation

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Chad Sellers a következőeket írta:
> This patch us a userspace patch to provide polyinstantiation support in
> SELinux.  

Hi!

Thanks, a long-awaited feature.
(A bit too complicated, I think rsbac's "append role to end of symlynk target"
is more elegant, but at least we have it.)

-- 
GNU GPL: csak tiszta forrásból


--
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: [RFC]{Patch 0/5] Polyinstantation

[Stephen Smalley]

On Wed, 2005-05-11 at 21:30 -0400, Daniel J Walsh wrote:
> Not sure what you mean by context.  Are you saying that all user_r would 
> share the same /tmp?
> I would prefer that the directories be separated by UID/ROLE.

The latter (separation by uid/role/level) is what Chad was suggesting in
response to your posting.  His current implementation is just separation
by role/level, since that is what concerns us for mandatory access
control, but it could be extended to also incorporate the Linux uid in
the computation/selection of a member subdirectory.

>   So most systems will
> have only limited user roles, maybe user_r, staff_r and sysadm_r.  So if 
> I give each user their
> own /tmp directory, you eliminate users attacking each other, or at 
> least make it more difficult.

One thing to note is that the current implementation is bind mounting
the original top-level /tmp directory elsewhere so that security-aware
applications can access other member subdirectories if they are allowed
to do so by policy.  This is necessary e.g. so that su and newrole can
re-bind to a different /tmp member when switching users/roles/levels and
so that trusted applications that operate on multiple levels can access
data at other levels.  Hence, we'll have to be careful about the policy
and the mode bits on the top-level directory and on the member
subdirectories to prevent such attacks.

> I think the users /tmp directory should be the same for all logins.  So 
> if I copy a file to /tmp
> and then go to another machine and scp it off, the file will be there.

Yes, it will be the same if the user is operating at the same role and
level.  Otherwise, it will not be visible by default, although security-
aware applications may be able to access it via the bind mount of the
original top-level directory if policy permits them to do so.

> This would then work on all Linux systems with or without SELinux and 
> independant of the policy.

Possibly his implementation could fall back to just per-uid
polyinstantiation if SELinux is disabled.  But when SELinux is enabled,
we do want it to be based on policy, so that we can provide proper
separation among roles and levels even for a single user.

-- 
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: [RFC]{Patch 0/5] Polyinstantation

[Chad Sellers]

On Thu, 2005-05-12 at 07:22 -0400, Stephen Smalley wrote:
> On Wed, 2005-05-11 at 21:30 -0400, Daniel J Walsh wrote:
> > Not sure what you mean by context.  Are you saying that all user_r would 
> > share the same /tmp?
> > I would prefer that the directories be separated by UID/ROLE.
> 
> The latter (separation by uid/role/level) is what Chad was suggesting in
> response to your posting.  His current implementation is just separation
> by role/level, since that is what concerns us for mandatory access
> control, but it could be extended to also incorporate the Linux uid in
> the computation/selection of a member subdirectory.
> 
Yes.

> >   So most systems will
> > have only limited user roles, maybe user_r, staff_r and sysadm_r.  So if 
> > I give each user their
> > own /tmp directory, you eliminate users attacking each other, or at 
> > least make it more difficult.
> 
> One thing to note is that the current implementation is bind mounting
> the original top-level /tmp directory elsewhere so that security-aware
> applications can access other member subdirectories if they are allowed
> to do so by policy.  This is necessary e.g. so that su and newrole can
> re-bind to a different /tmp member when switching users/roles/levels and
> so that trusted applications that operate on multiple levels can access
> data at other levels.  Hence, we'll have to be careful about the policy
> and the mode bits on the top-level directory and on the member
> subdirectories to prevent such attacks.
> 
> > I think the users /tmp directory should be the same for all logins.  So 
> > if I copy a file to /tmp
> > and then go to another machine and scp it off, the file will be there.
> 
This is how it works right now for security contexts.  So if I add
support for uid as well, that's how it would work.

> 
> > This would then work on all Linux systems with or without SELinux and 
> > independant of the policy.
> 
> Possibly his implementation could fall back to just per-uid
> polyinstantiation if SELinux is disabled.  But when SELinux is enabled,
> we do want it to be based on policy, so that we can provide proper
> separation among roles and levels even for a single user.
> 
I could make this a config file option.  Per directory, you could
specify whether to polyinstantiate based on policy, uid, or both.  Would
that work for you?

Have you tried implementing per-user /tmp directories yet?  I'm curious
if it breaks anything (at least anything more than per security context
does)?

-- 
Chad Sellers
cdselle@tycho.nsa.gov


--
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: [RFC]{Patch 0/5] Polyinstantation

[Russell Coker]

On Thursday 12 May 2005 23:22, Chad Sellers <cdselle@tycho.nsa.gov> wrote:
> Have you tried implementing per-user /tmp directories yet?  I'm curious
> if it breaks anything (at least anything more than per security context
> does)?

Per user /tmp directories break the typical uses of Unix systems.  On Unix 
multi-user systems it's expected that you can copy a file to /tmp and give it 
mode 0644 to share it with other people.  Failing that the ways of giving 
files to other users on the same machine will be email and web.  Email gives 
delays and sharing via the web can lead to unintended consequences (IE data 
may not need to be kept secret from other local users but may need to be kept 
secret from the global Internet).

Then there's the issue of globally visible mounts.  If I am administering a 
multi-user system then I will need to be able to login remotely and 
mount/umount file systems.  If the shell for my login session uses the NEWNS 
option for clone then I can't do this (any mounts I do won't be visible to 
system processes or new user logins).  To alleviate this we want to allow 
logins by administrators without NEWNS.

If an administrator umounts a file system then any currently running user 
sessions created with NEWNS will still see it.  How do we solve this?

-- 
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: [RFC]{Patch 0/5] Polyinstantation

[Valdis.Kletnieks]

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

On Fri, 13 May 2005 14:40:39 +1000, Russell Coker said:
> Per user /tmp directories break the typical uses of Unix systems.  On Unix 
> multi-user systems it's expected that you can copy a file to /tmp and give it
> mode 0644 to share it with other people.

Right. Unfortunately, we're swimming upstream against a quarter century
of common practice that happens to be almost "couldn't design a worse security
model if we *tried*". A shared /tmp makes sense when everybody's in the same
security domain, is essentially root anyhow, and file ownerships/permissions
are there mostly to limit friendly-fire accidents to ones *own* feet, and not
the co-workers as well.  Of course, if you're deploying SELinux, you're no
longer in Kansas anymore....

Is the polyinstantation addressing:

1) the fact that userB may be able to see/interfere with what userA is doing
in /tmp, when userA may not desire userB doing so? (If we give userA his own
instance of /tmp, userB can't interfere).

2) The problem of userA intentionally using /tmp as a zone to pass sensitive
data to userB, when the site security officer has other ideas? (If we give
userA his own instance of /tmp, he can't drop a file where userB can get it).

3) Attempting to solve both problems at the same time?

And Russell is correct - although it *does* work when A and B *shouldn't*
communicate, we *do* need to make *some* provision for the case where users A
and B are cooperating and allowed to do so by site policy. I suspect that
"share via /tmp" won't be easily workable, but "share via other file system
means" will be (we're already looking at a '~/Downloads' type of directory - a
~/Shared perhaps?)




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

Re: [RFC]{Patch 0/5] Polyinstantation

[Daniel J Walsh]

Valdis.Kletnieks@vt.edu wrote:

>On Fri, 13 May 2005 14:40:39 +1000, Russell Coker said:
>  
>
>>Per user /tmp directories break the typical uses of Unix systems.  On Unix 
>>multi-user systems it's expected that you can copy a file to /tmp and give it
>>mode 0644 to share it with other people.
>>    
>>
>
>  
>

>Right. Unfortunately, we're swimming upstream against a quarter century
>of common practice that happens to be almost "couldn't design a worse security
>model if we *tried*". A shared /tmp makes sense when everybody's in the same
>security domain, is essentially root anyhow, and file ownerships/permissions
>are there mostly to limit friendly-fire accidents to ones *own* feet, and not
>the co-workers as well.  Of course, if you're deploying SELinux, you're no
>longer in Kansas anymore....
>
>Is the polyinstantation addressing:
>
>1) the fact that userB may be able to see/interfere with what userA is doing
>in /tmp, when userA may not desire userB doing so? (If we give userA his own
>instance of /tmp, userB can't interfere).
>
>2) The problem of userA intentionally using /tmp as a zone to pass sensitive
>data to userB, when the site security officer has other ideas? (If we give
>userA his own instance of /tmp, he can't drop a file where userB can get it).
>
>3) Attempting to solve both problems at the same time?
>
>And Russell is correct - although it *does* work when A and B *shouldn't*
>communicate, we *do* need to make *some* provision for the case where users A
>and B are cooperating and allowed to do so by site policy. I suspect that
>"share via /tmp" won't be easily workable, but "share via other file system
>means" will be (we're already looking at a '~/Downloads' type of directory - a
>~/Shared perhaps?)
>
>
>
>  
>

None of this stuff will work until we have the ability for the 
administrator to change every users view
of the file system.  So some kind of shared file system will be 
required.   I think the idea of the  required
shared /tmp is fairly old idea, and not needed much any more,  and can 
be easily be done using other means. 
I figure the ability to use a non shared /tmp should be configurable.  
And as Valdis can easily be worked
around by creating another directory for cross machine sharing.   

-- 



--
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: [RFC]{Patch 0/5] Polyinstantation

[Stephen Smalley]

On Fri, 2005-05-13 at 14:40 +1000, Russell Coker wrote:
> Per user /tmp directories break the typical uses of Unix systems.  On Unix 
> multi-user systems it's expected that you can copy a file to /tmp and give it 
> mode 0644 to share it with other people.  Failing that the ways of giving 
> files to other users on the same machine will be email and web.  Email gives 
> delays and sharing via the web can lead to unintended consequences (IE data 
> may not need to be kept secret from other local users but may need to be kept 
> secret from the global Internet).

Hmmm....then I'm a little worried about Chad incorporating per-user
polyinstantiation into his existing implementation of context-based
polyinstantiation.  He was going to make it part of the configuration
file (i.e. for a given directory like /tmp, one could specify per-user,
per-context, or both for polyinstantiation), but that wouldn't let you
express concepts like "I want user A and B to share the same /tmp but
user C to have a separate one."  Note that we can express such concepts
for the context-based polyinstantiation via the type_member rules, e.g.
type_member A tmp_t:dir A_tmp_t; type_member B tmp_t:dir A_tmp_t;
type_member C tmp_t:dir C_tmp_t;, but we would have to invent a similar
language and engine for user-based polyinstantiation and that really
isn't a goal for SELinux.

> Then there's the issue of globally visible mounts.  If I am administering a 
> multi-user system then I will need to be able to login remotely and 
> mount/umount file systems.  If the shell for my login session uses the NEWNS 
> option for clone then I can't do this (any mounts I do won't be visible to 
> system processes or new user logins).  To alleviate this we want to allow 
> logins by administrators without NEWNS.
> 
> If an administrator umounts a file system then any currently running user 
> sessions created with NEWNS will still see it.  How do we solve this?

There is already ongoing work to allow shared subtrees, see the
discussions on linux-fsdevel and linux-kernel.

-- 
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: [RFC]{Patch 0/5] Polyinstantation

[Chad Sellers]

I have updated the library in response to Dan's interest in per-user
/tmp directories.  I'll be sending updated versions of the patches along
in another string of emails.

The library now handles polyinstantiation based on selinux policy (as
before), uid, or both.  To accomplish this, security_setupns now takes
an additional argument, the uid.  The choice between these three modes
is made on a per directory basis and specified in the config file.
Additionally, the config file allows specification of a default mode
for member directories, as well as users that are exempt from uid-based
polyinstantiation.  Since the config file is a little more useful now,
I formatted it a little better.  The global options go at the top in
name-value pair format, and the directories with their modes go at the
bottom.

Thanks,
Chad

-- 
Chad Sellers
cdselle@tycho.nsa.gov


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