pam_namespace

pam_namespace

[Russell Coker]

I was just playing with pam_namespace.  It seems to me that the current setup 
of having tmp/tmp.inst-$USER- does not provide adequate protection.  A 
process that is hostile to the user and which runs in the system name space 
(EG any cracked daemon) can access the user's instance of /tmp.

If we had tmp/tmp.inst-$USER-/tmp (or something similar) and 
gave /tmp/tmp.inst-$USER- permission mode 000 (and something equivalent in 
terms of SE Linux access) then processes in the global name space would not 
be able to try anything.


PS  I am posting here because I am no longer subscribed to the LSPP list.

-- 
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: pam_namespace

[Valdis.Kletnieks]

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

On Fri, 05 May 2006 16:23:22 +1000, Russell Coker said:
> I was just playing with pam_namespace.  It seems to me that the current setup
> of having tmp/tmp.inst-$USER- does not provide adequate protection.  A 
> process that is hostile to the user and which runs in the system name space 
> (EG any cracked daemon) can access the user's instance of /tmp.

Not if /tmp/tmp.inst-$USER has an SELinux context on it that the daemon
isn't able to read.  Of course, this has it's own issues, since the parent
and instance directories have different SELinux contexts.

I've been corresponding with Janak Desai about several issues related to this
one - it turns out to be trickier than expected if you need any setup above
and beyond what pam_namespace does.  If anybody has good ideas on how the
namespace.init script should work, please let Janak know.  We already decided
that where the Fedora RPM put the script was a Bad Idea - now it's in /etc/
security where it's easier to protect.  Still an issue - I tried to get it to
play nice with gdm, and discovered it didn't work when the X socket wasn't
there. So I added to the script:

case $1 in
     /tmp)
        if [ ! -d ${2}/.X11-unix ];
        then
                mkdir ${2}/.X11-unix
                chcon --reference=${1}/.X11-unix  ${2}/.X11-unix
        fi

(and then hardlink the socket already open by GDM into that directory so
the user's X session can find it).  This however still loses, because at
this point we're already running in the user's SELinux context, so we
probably can't do the chcon.  Janak was going to look at setexeccon() games
so the script can do setup that the user can't....

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

Re: pam_namespace

[Russell Coker]

On Friday 05 May 2006 17:50, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 05 May 2006 16:23:22 +1000, Russell Coker said:
> > I was just playing with pam_namespace.  It seems to me that the current
> > setup of having tmp/tmp.inst-$USER- does not provide adequate protection.
> >  A process that is hostile to the user and which runs in the system name
> > space (EG any cracked daemon) can access the user's instance of /tmp.
>
> Not if /tmp/tmp.inst-$USER has an SELinux context on it that the daemon
> isn't able to read.  Of course, this has it's own issues, since the parent
> and instance directories have different SELinux contexts.

Yes, which of course means that programs the user runs in different domains 
will need modified policy to allow creation of temp files.  This isn't 
impossible but does have other issues including the fact that such programs 
will be able to create /tmp/dir/file where /tmp/dir is a directory created by 
the user, this may not be desired.

Setting a range on the per-user tmp directory that matches the range of their 
login process makes some sense.  But using a type other than tmp_t does not 
make sense to me.

Also we want the namespace feature to work on non-SE systems where the option 
of a different SE Linux context is not available.

Why do you object to the idea of using a sub-directory for this?

> case $1 in
>      /tmp)
>         if [ ! -d ${2}/.X11-unix ];
>         then
>                 mkdir ${2}/.X11-unix
>                 chcon --reference=${1}/.X11-unix  ${2}/.X11-unix
>         fi
>
> (and then hardlink the socket already open by GDM into that directory so
> the user's X session can find it).  This however still loses, because at
> this point we're already running in the user's SELinux context, so we
> probably can't do the chcon.  Janak was going to look at setexeccon() games
> so the script can do setup that the user can't....

Why can't we have a script run in system context?

-- 
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: pam_namespace

[Valdis.Kletnieks]

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

On Fri, 05 May 2006 19:14:20 +1000, Russell Coker said:
> Yes, which of course means that programs the user runs in different domains
> will need modified policy to allow creation of temp files.  This isn't
> impossible but does have other issues including the fact that such programs
> will be able to create /tmp/dir/file where /tmp/dir is a directory created by
> the user, this may not be desired.
> 
> Setting a range on the per-user tmp directory that matches the range of their
> login process makes some sense.  But using a type other than tmp_t does not
> make sense to me.

There's already code in there to support per-user, per-context, and even
per-user-and-context-pair.  Adding ranges may make sense for some systems -
the problems start when we have to allow for various policy types - strict,
targeted, and each with MLS and MCS variants.  We need:

a) a way to specify what the system policy is - what's acceptable to me
may not be to others, and vice versa.

b) A check that we fail in a sane manner if the SELinux policy and the
pam_namespace config aren't compatible.  This may be tricky - for a system
that's in strict/MLS mode, failing to config may be grounds for failing totally
in a noisy manner (refusing the logon, for instance) - while for targeted
we may want to just ignore an attempt to specify MLS features..

> Also we want the namespace feature to work on non-SE systems where the option 
> of a different SE Linux context is not available.

See the above - I think we're in agreement here.  But I admit I don't know what
"proper" behavior is if the threat model is "a non-SE system, and a 0wned
uid=0 daemon getting into /tmp/$USER" - how do we stop that (ugly hacks like
cd'ing into the directory, and then mount --bind an empty dir over it?)

> Why do you object to the idea of using a sub-directory for this?

I don't - I just want to be *really* sure that the sub-directory is set up right. ;)

> > (and then hardlink the socket already open by GDM into that directory so
> > the user's X session can find it).  This however still loses, because at
> > this point we're already running in the user's SELinux context, so we
> > probably can't do the chcon.  Janak was going to look at setexeccon() games
> > so the script can do setup that the user can't....
> 
> Why can't we have a script run in system context?

That's the goal of the setexeccon() that Janak was going to look into.  The
problem is that we're already in a user context - what happens if that context
isn't *allowed* to setexeccon() to a system context?



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

Re: pam_namespace

[Russell Coker]

On Friday 05 May 2006 20:06, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 05 May 2006 19:14:20 +1000, Russell Coker said:
> > Yes, which of course means that programs the user runs in different
> > domains will need modified policy to allow creation of temp files.  This
> > isn't impossible but does have other issues including the fact that such
> > programs will be able to create /tmp/dir/file where /tmp/dir is a
> > directory created by the user, this may not be desired.
> >
> > Setting a range on the per-user tmp directory that matches the range of
> > their login process makes some sense.  But using a type other than tmp_t
> > does not make sense to me.
>
> There's already code in there to support per-user, per-context, and even
> per-user-and-context-pair.  Adding ranges may make sense for some systems -
> the problems start when we have to allow for various policy types - strict,
> targeted, and each with MLS and MCS variants.  We need:

Why is it a problem?

We already have $USER and $HOME as variables that can be used by the namespace 
module, all we need to do is add $DOMAIN, $HIGH, and $LOW (so that the 
instance directory name can be based on the SE Linux domain of the process, 
the high end of the MLS range, or the low end of the MLS range).

For MCS we want the high end of the MLS range to be used as part of the 
directory name, for MLS we probably want the low end of the range to be used 
(but both would be an option).

> a) a way to specify what the system policy is - what's acceptable to me
> may not be to others, and vice versa.

Of course.  Adding suitable configuration options 
to /etc/security/namespace.conf will solve this.

> b) A check that we fail in a sane manner if the SELinux policy and the
> pam_namespace config aren't compatible.  This may be tricky - for a system
> that's in strict/MLS mode, failing to config may be grounds for failing
> totally in a noisy manner (refusing the logon, for instance) - while for
> targeted we may want to just ignore an attempt to specify MLS features..

In what way do the require_selinux and the ignore_config_error command-line 
options to the pam_namespace.so module not do what you desire in this regard?

> > Also we want the namespace feature to work on non-SE systems where the
> > option of a different SE Linux context is not available.
>
> See the above - I think we're in agreement here.  But I admit I don't know
> what "proper" behavior is if the threat model is "a non-SE system, and a
> 0wned uid=0 daemon getting into /tmp/$USER" - how do we stop that (ugly
> hacks like cd'ing into the directory, and then mount --bind an empty dir
> over it?)

On a non-SE system "0wned uid=0 daemon" is considered to be game-over.

However a uid>0 daemon on a non-SE system should not be able to interfere with 
regular users, but this is the case currently!

Also there's the potential situation of a UID=0 daemon on a SE Linux system 
that is permitted some access to user types.

Of course there's nothing stopping us from modifying a program such as runuser 
or run_init to set up a namespace for a daemon.  In fact we should probably 
make the default behavior of run_init and runuser be the creation of a 
namespace.  It would be easy to create a config file for runuser that allows 
excluding daemons on the basis of executable name, UID, or other factors.

> > Why do you object to the idea of using a sub-directory for this?
>
> I don't - I just want to be *really* sure that the sub-directory is set up
> right. ;)

It seems that we agree that there is a need for an intermediate directory and 
that the only area of uncertainty is regarding the context and mode of it.

> > > (and then hardlink the socket already open by GDM into that directory
> > > so the user's X session can find it).  This however still loses,
> > > because at this point we're already running in the user's SELinux
> > > context, so we probably can't do the chcon.  Janak was going to look at
> > > setexeccon() games so the script can do setup that the user can't....
> >
> > Why can't we have a script run in system context?
>
> That's the goal of the setexeccon() that Janak was going to look into.  The
> problem is that we're already in a user context - what happens if that
> context isn't *allowed* to setexeccon() to a system context?

How are we already in a user context?  sys_unshare() can only be called from a 
system context...

-- 
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: pam_namespace

[Valdis.Kletnieks]

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

On Sun, 07 May 2006 19:28:19 +1000, Russell Coker said:

> > There's already code in there to support per-user, per-context, and even
> > per-user-and-context-pair.  Adding ranges may make sense for some systems -
> > the problems start when we have to allow for various policy types - strict,
> > targeted, and each with MLS and MCS variants.  We need:
> 
> Why is it a problem?

I didn't say it was a problem. I said it was needed additional functionality
if you want to support it.

> We already have $USER and $HOME as variables that can be used by the namespace 
> module, all we need to do is add $DOMAIN, $HIGH, and $LOW (so that the 
> instance directory name can be based on the SE Linux domain of the process, 
> the high end of the MLS range, or the low end of the MLS range).
> 
> For MCS we want the high end of the MLS range to be used as part of the 
> directory name, for MLS we probably want the low end of the range to be used 
> (but both would be an option).

More code, more options, more complexity...

> > a) a way to specify what the system policy is - what's acceptable to me
> > may not be to others, and vice versa.
> 
> Of course.  Adding suitable configuration options 
> to /etc/security/namespace.conf will solve this.

The trick is fining a set of options that cover all the bases, but
are still comprehensible to the average sysadmin..

> > b) A check that we fail in a sane manner if the SELinux policy and the
> > pam_namespace config aren't compatible.  This may be tricky - for a system
> > that's in strict/MLS mode, failing to config may be grounds for failing
> > totally in a noisy manner (refusing the logon, for instance) - while for
> > targeted we may want to just ignore an attempt to specify MLS features..
> 
> In what way do the require_selinux and the ignore_config_error command-line 
> options to the pam_namespace.so module not do what you desire in this regard?

ignore_config_error is only sufficient if there is no possibility of
any option misbehaving - in particular, we can't have an option 'both'
that works in MCS/MLS environments as well - we'll need to have a both_mcs
if the mcs label is to be included, and a both_no_mcs if it should behave
in the same way as the non-mcs 'both'.

> > > Also we want the namespace feature to work on non-SE systems where the
> > > option of a different SE Linux context is not available.
> >
> > See the above - I think we're in agreement here.  But I admit I don't know
> > what "proper" behavior is if the threat model is "a non-SE system, and a
> > 0wned uid=0 daemon getting into /tmp/$USER" - how do we stop that (ugly
> > hacks like cd'ing into the directory, and then mount --bind an empty dir
> > over it?)
> 
> On a non-SE system "0wned uid=0 daemon" is considered to be game-over.

So you're saying that on a non-SE system, namespaces are *not* in the
least expected to slow down a rogue daemon.  OK, as long as we make a
note of that..


> > > > (and then hardlink the socket already open by GDM into that directory
> > > > so the user's X session can find it).  This however still loses,
> > > > because at this point we're already running in the user's SELinux
> > > > context, so we probably can't do the chcon.  Janak was going to look at
> > > > setexeccon() games so the script can do setup that the user can't....
> > >
> > > Why can't we have a script run in system context?
> >
> > That's the goal of the setexeccon() that Janak was going to look into.  The
> > problem is that we're already in a user context - what happens if that
> > context isn't *allowed* to setexeccon() to a system context?
>
> How are we already in a user context?  sys_unshare() can only be called from a
> system context...

OK, you tell me what's going on here:

# head /etc/security/namespace.init
#!/bin/bash
logger -i -p authpriv.info "called with args $1 $2" `id`

produces:

May  7 21:03:57 turing-police login: pam_namespace(login:session): Inst context system_u:object_r:staff_tmp_t Orig context system_u:object_r:tmp_t
May  7 21:03:57 turing-police login: pam_namespace(login:session): instance_dir /tmp/tmp.system_u:object_r:staff_tmp_t_valdis
May  7 21:03:57 turing-police LOGIN[7584]: called with args /tmp /tmp/tmp.system_u:object_r:staff_tmp_t_valdis uid=0(root) gid=0(root) groups=10(wheel),967(valdis) context=valdis:staff_r:staff_t

The problem is that the pam_namespace is still running in a system context,
but since an earlier pam_selinux called setexeccon(), when namespace
does an exec, it gets parked in the user context that pam_selinux intended
to inflict on the actual user login....

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

Re: pam_namespace

[Russell Coker]

On Monday 08 May 2006 11:07, Valdis.Kletnieks@vt.edu wrote:
> > > b) A check that we fail in a sane manner if the SELinux policy and the
> > > pam_namespace config aren't compatible.  This may be tricky - for a
> > > system that's in strict/MLS mode, failing to config may be grounds for
> > > failing totally in a noisy manner (refusing the logon, for instance) -
> > > while for targeted we may want to just ignore an attempt to specify MLS
> > > features..
> >
> > In what way do the require_selinux and the ignore_config_error
> > command-line options to the pam_namespace.so module not do what you
> > desire in this regard?
>
> ignore_config_error is only sufficient if there is no possibility of
> any option misbehaving - in particular, we can't have an option 'both'
> that works in MCS/MLS environments as well - we'll need to have a both_mcs
> if the mcs label is to be included, and a both_no_mcs if it should behave
> in the same way as the non-mcs 'both'.

Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to 
have "user" and "context" as separate items to replace "both" and then 
support a fourth option as "range", "high" or "low".

> > > See the above - I think we're in agreement here.  But I admit I don't
> > > know what "proper" behavior is if the threat model is "a non-SE system,
> > > and a 0wned uid=0 daemon getting into /tmp/$USER" - how do we stop that
> > > (ugly hacks like cd'ing into the directory, and then mount --bind an
> > > empty dir over it?)
> >
> > On a non-SE system "0wned uid=0 daemon" is considered to be game-over.
>
> So you're saying that on a non-SE system, namespaces are *not* in the
> least expected to slow down a rogue daemon.  OK, as long as we make a
> note of that..

Not at all!  I'm saying that on a non-SE system a uid=0 process can do 
anything it wants so there's no point even attempting to constrain such a 
process.  However nowadays most daemons never run as root, and the ones that 
do run as root drop their privs for as much code as possible.

Attack by a non-root daemon on a non-SE system is something we want to 
prevent.

> > > > Why can't we have a script run in system context?
> > >
> > > That's the goal of the setexeccon() that Janak was going to look into. 
> > > The problem is that we're already in a user context - what happens if
> > > that context isn't *allowed* to setexeccon() to a system context?
> >
> > How are we already in a user context?  sys_unshare() can only be called
> > from a system context...
>
> OK, you tell me what's going on here:
>
> # head /etc/security/namespace.init
> #!/bin/bash
> logger -i -p authpriv.info "called with args $1 $2" `id`

Firstly, what is this /etc/security/namespace.init?  Pam version 
pam-0.99.3.0-4 doesn't have this, are you running some different version?

One thing that concerns me about the pam-0.99.3.0-4 code base is that it 
appears to want to run a script from the polydir.  As I can't seem to 
exercise that code I can't be sure that it's doing the wrong thing, but the 
concept seems bad.

> The problem is that the pam_namespace is still running in a system context,
> but since an earlier pam_selinux called setexeccon(), when namespace
> does an exec, it gets parked in the user context that pam_selinux intended
> to inflict on the actual user login....

That's easy to solve, just call setexeccon(NULL) before doing the exec.  As a 
child process is used for this (if exec fails it calls exit(1)) there is not 
even any need to save the old value of the execcon.

-- 
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: pam_namespace

[Janak Desai]

Russell Coker wrote:

>On Monday 08 May 2006 11:07, Valdis.Kletnieks@vt.edu wrote:
>  
>
>>>>b) A check that we fail in a sane manner if the SELinux policy and the
>>>>pam_namespace config aren't compatible.  This may be tricky - for a
>>>>system that's in strict/MLS mode, failing to config may be grounds for
>>>>failing totally in a noisy manner (refusing the logon, for instance) -
>>>>while for targeted we may want to just ignore an attempt to specify MLS
>>>>features..
>>>>        
>>>>
>>>In what way do the require_selinux and the ignore_config_error
>>>command-line options to the pam_namespace.so module not do what you
>>>desire in this regard?
>>>      
>>>
>>ignore_config_error is only sufficient if there is no possibility of
>>any option misbehaving - in particular, we can't have an option 'both'
>>that works in MCS/MLS environments as well - we'll need to have a both_mcs
>>if the mcs label is to be included, and a both_no_mcs if it should behave
>>in the same way as the non-mcs 'both'.
>>    
>>
>
>Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to 
>have "user" and "context" as separate items to replace "both" and then 
>support a fourth option as "range", "high" or "low".
>
>  
>
I am not sure I understand. We have "user", "context" and "both", where type
in the context can be controlled through type-member policy rules and 
the mls
range is inherited from the process. Can you give an example of what context
the instance would have with "range" or "high" or "low"?

In general I am not sure about the intermidiate directory itself. To me, 
it complicates
the mechanism and mixes it with policy. When using polyinstantiation 
with SELinux,
you can tighten up access to instances by type-member rules and by 
inheriting mls
label of the process. In non-SELinux use, an admin can seperate users 
from each
other by configuring the instance to be a subdirectory of the 
polyinstantiated directory.
We can get additional protection from non-root daemons by creating an 
intermdiate
directory. However, is it really worth the trouble to protect a user's 
instance of
/tmp or /var/tmp beyond what will be protected by sticky bits? Since 
instances
inherit the polyinstantiated directory's mode, $HOME etc are already 
protected
from non-root daemons.

>>>>See the above - I think we're in agreement here.  But I admit I don't
>>>>know what "proper" behavior is if the threat model is "a non-SE system,
>>>>and a 0wned uid=0 daemon getting into /tmp/$USER" - how do we stop that
>>>>(ugly hacks like cd'ing into the directory, and then mount --bind an
>>>>empty dir over it?)
>>>>        
>>>>
>>>On a non-SE system "0wned uid=0 daemon" is considered to be game-over.
>>>      
>>>
>>So you're saying that on a non-SE system, namespaces are *not* in the
>>least expected to slow down a rogue daemon.  OK, as long as we make a
>>note of that..
>>    
>>
>
>Not at all!  I'm saying that on a non-SE system a uid=0 process can do 
>anything it wants so there's no point even attempting to constrain such a 
>process.  However nowadays most daemons never run as root, and the ones that 
>do run as root drop their privs for as much code as possible.
>
>Attack by a non-root daemon on a non-SE system is something we want to 
>prevent.
>  
>
Again, this attack, valid only on non-SELinux mode, would only 
consititute the
daemon creating files in user's instance of /tmp or /var/tmp. Because of 
the sticky bit,
the daemon will not be able delete any files there, right?

>  
>
>>>>>Why can't we have a script run in system context?
>>>>>          
>>>>>
>>>>That's the goal of the setexeccon() that Janak was going to look into. 
>>>>The problem is that we're already in a user context - what happens if
>>>>that context isn't *allowed* to setexeccon() to a system context?
>>>>        
>>>>
>>>How are we already in a user context?  sys_unshare() can only be called
>>>from a system context...
>>>      
>>>
>>OK, you tell me what's going on here:
>>
>># head /etc/security/namespace.init
>>#!/bin/bash
>>logger -i -p authpriv.info "called with args $1 $2" `id`
>>    
>>
>
>Firstly, what is this /etc/security/namespace.init?  Pam version 
>pam-0.99.3.0-4 doesn't have this, are you running some different version?
>
>One thing that concerns me about the pam-0.99.3.0-4 code base is that it 
>appears to want to run a script from the polydir.  As I can't seem to 
>exercise that code I can't be sure that it's doing the wrong thing, but the 
>concept seems bad.
>
>  
>
Yes, this was pointed out Valdis and Stephen. Valdis created a bugzilla 
for it and
the patch posted there moves the instance initialization from polydir to 
/etc/security/namespace.init

>>The problem is that the pam_namespace is still running in a system context,
>>but since an earlier pam_selinux called setexeccon(), when namespace
>>does an exec, it gets parked in the user context that pam_selinux intended
>>to inflict on the actual user login....
>>    
>>
>
>That's easy to solve, just call setexeccon(NULL) before doing the exec.  As a 
>child process is used for this (if exec fails it calls exit(1)) there is not 
>even any need to save the old value of the execcon.
>  
>

Yes, that's exactly what I was going to do. Late last week, I was 
distracted by non pam_namespace
related tasks, but hopefully I can test and post an updated patch today.

-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: pam_namespace

[Valdis.Kletnieks]

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

On Mon, 08 May 2006 09:44:24 EDT, Janak Desai said:
> >>The problem is that the pam_namespace is still running in a system context,
> >>but since an earlier pam_selinux called setexeccon(), when namespace
> >>does an exec, it gets parked in the user context that pam_selinux intended
> >>to inflict on the actual user login...
> >That's easy to solve, just call setexeccon(NULL) before doing the exec.  As a
> >child process is used for this (if exec fails it calls exit(1)) there is not
> >even any need to save the old value of the execcon.
> Yes, that's exactly what I was going to do. Late last week, I was 
> distracted by non pam_namespace
> related tasks, but hopefully I can test and post an updated patch today.

I grabbed the updated patch, and tested.  The script now runs in local_login_t for logins from
the console:

May  8 16:21:38 turing-police LOGIN[30328]: called with args /tmp /tmp/tmp.system_u:object_r:staff_tmp_t_valdis uid=0(root) gid=0(root) groups=10(wheel),967(valdis) context=system_u:system_r:local_login_t:SystemLow-SystemHigh

I still need to test my script with gdm - that was broken (my fault) last time
I tried it...

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

Re: pam_namespace

[Russell Coker]

On Monday 08 May 2006 23:44, Janak Desai <janak@us.ibm.com> wrote:
> >>ignore_config_error is only sufficient if there is no possibility of
> >>any option misbehaving - in particular, we can't have an option 'both'
> >>that works in MCS/MLS environments as well - we'll need to have a
> >> both_mcs if the mcs label is to be included, and a both_no_mcs if it
> >> should behave in the same way as the non-mcs 'both'.
> >
> >Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to
> >have "user" and "context" as separate items to replace "both" and then
> >support a fourth option as "range", "high" or "low".
>
> I am not sure I understand. We have "user", "context" and "both", where
> type in the context can be controlled through type-member policy rules and
> the mls range is inherited from the process. Can you give an example of what
> context the instance would have with "range" or "high" or "low"?

My idea is that the range, high, and low values would be candidates for the 
file name.

The current code in rawhide does not inherit the range from the process, are 
you referring to a newer version of pam_namespace.c?  If so where can I find 
a copy?

For inheriting the range to be viable then we need to support names for the 
temporary directory based on the range so that different ranges for the 
current user can be supported.  I am not sure whether we will support 
choosing a range at login time, if we do then we must support this.  If we 
will never support choosing the range at login time there is the case of su 
which may be run after a newrole command and therefore be used to enter the 
same user role in different contexts.  Another case is that of a user who has 
their default range changed by the sys-admin while they are logged in (this 
may be uncommon in the case of MLS use but for MCS I expect it to be regular 
system use).

Probably the easiest thing to do is to default to including the entire 
security context of the process in the directory name.

> In general I am not sure about the intermidiate directory itself. To me,
> it complicates the mechanism and mixes it with policy. When using
> polyinstantiation with SELinux, you can tighten up access to instances by
> type-member rules and by inheriting mls label of the process.

For the case of strict and mls policy, yes.  For targeted policy we don't have 
such protections.

> In non-SELinux use, an admin can seperate users from each
> other by configuring the instance to be a subdirectory of the
> polyinstantiated directory.
> We can get additional protection from non-root daemons by creating an
> intermdiate directory. However, is it really worth the trouble to protect a
> user's instance of /tmp or /var/tmp beyond what will be protected by sticky
> bits? Since instances inherit the polyinstantiated directory's mode, $HOME
> etc are already protected from non-root daemons.

$HOME is protected, but as $HOME will only be PI on a strict or MLS system 
this isn't an issue.

Sticky bits provide no protection, the entire purpose of PI for /tmp is that 
the sticky bits don't do an adequate job!  Substituting a race condition 
attack on /tmp for a race condition attack on /tmp/tmp.inst-user-user is no 
gain!

Also while we are on the topic, the namespace module needs to handle the case 
of a directory existing with the wrong permissions or having a file with the 
name existing.

Currently with pam_namespace.so configured I can prevent a user from logging 
in by creating a file named /tmp/tmp.inst-user-user.  I can create a 
directory of that name as another user to take over ownership of another 
user's instance of /tmp.  I can make /tmp/tmp.inst-user-user a sym-link 
to /etc which then makes /tmp a copy of /etc for the user who logs in (I'm 
sure that there is potential for an exploit here).

There are two algorithms that occur to me to deal with these issues, one is 
that if there is an existing directory of the name in question then we first 
check the ownership, permissions, and context against what we would create, 
if they don't match (or if the name is taken by something other than a 
directory) then we append ".1" to the name and try again, we keep either 
incrementing the number we append until we find a directory that has 
appropriate perms or which does not exist.  The other algorithm is to have a 
specific subdirectory created with a name such as /tmp/.inst that has 
restrictive permissions under both Unix and SE Linux and then create all 
directories under that.  This second algorithm also removes the need to 
create two levels of directory each time a user logs in (saves 4K of disk 
space per session and a tiny amount of CPU time).

The first algorithm doesn't deal well with DOS attacks.  The second algorithm 
has the creation of a permanent directory under /tmp with the need to create 
the directory very early in the boot process for systems with tmpfs on /tmp 
(not SE Linux as we don't have policy support for tmpfs on /tmp).  Creating a 
directory in such a manner is messy, but there is precedent for it 
in /tmp/.X11-unix, /tmp/.ICE-unix, and /tmp/.font-unix.

> >>>On a non-SE system "0wned uid=0 daemon" is considered to be game-over.
> >>
> >>So you're saying that on a non-SE system, namespaces are *not* in the
> >>least expected to slow down a rogue daemon.  OK, as long as we make a
> >>note of that..
> >
> >Not at all!  I'm saying that on a non-SE system a uid=0 process can do
> >anything it wants so there's no point even attempting to constrain such a
> >process.  However nowadays most daemons never run as root, and the ones
> > that do run as root drop their privs for as much code as possible.
> >
> >Attack by a non-root daemon on a non-SE system is something we want to
> >prevent.
>
> Again, this attack, valid only on non-SELinux mode, would only
> consititute the
> daemon creating files in user's instance of /tmp or /var/tmp. Because of
> the sticky bit,
> the daemon will not be able delete any files there, right?

The attack is not only valid on non-SE Linux mode.  Such attacks that work on 
non-SE Linux will also mostly work on targeted systems.  On strict systems 
bugs and design flaws that permit integrity attacks on non-SE and targeted 
systems will generally be expected to become DOS attacks.

I think that generally deleting files is the last thing we are concerned 
about.  Some systems use a ram disk for /tmp by default (Solaris), some 
systems clean out /tmp on boot by default (Debian).  Generally /tmp should be 
considered as transient.  The concerns for /tmp are race condition attacks on 
system integrity (causing a process to expose or corrupt data when it is 
operating on files other than the ones the programmer or the user intended it 
to use) and exposing secret data through revealing sensitive file names.  The 
current operation of the pam_namespace.so module fails on the issue of 
protecting secret file names and doesn't do very well on the issue of 
protecting integrity against race conditions.

-- 
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: pam_namespace

[Russell Coker]

On Tuesday 09 May 2006 22:57, Russell Coker <russell@coker.com.au> wrote:
> > >Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to
> > >have "user" and "context" as separate items to replace "both" and then
> > >support a fourth option as "range", "high" or "low".
> >
> > I am not sure I understand. We have "user", "context" and "both", where
> > type in the context can be controlled through type-member policy rules
> > and the mls range is inherited from the process. Can you give an example
> > of what context the instance would have with "range" or "high" or "low"?
>
> My idea is that the range, high, and low values would be candidates for the
> file name.
[...]
> Probably the easiest thing to do is to default to including the entire
> security context of the process in the directory name.

One thing that I consider to be necessary is to allow the administrator to 
determine in which situations the PI directories should be shared.  Using a 
default that has the full context including range will work, but many admins 
will want finer grained control.

For example if the aim is to separate MLS ranges such that file names can not 
be used to accidentally reveal secret data then there may not be a need for 
separate Unix UIDs to have different directories, and directory names could 
be based on range alone.

Another possibility is when running the strict policy a user might have 
multiple roles but not want to have a different copy of /tmp for each one.  
For example if I scp a file to the /tmp directory used for role A then after 
running newrole to change to role B I will still want to see the file in 
question (assuming of course that the policy allows access to it).

Then for MCS the issue of whether it's most desirable to base instance 
directory names on the high or the low level is something that we probably 
won't ever get an agreement on.

-- 
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: pam_namespace

[Janak Desai]

Russell Coker wrote:

>On Tuesday 09 May 2006 22:57, Russell Coker <russell@coker.com.au> wrote:
>  
>
>>>>Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to
>>>>have "user" and "context" as separate items to replace "both" and then
>>>>support a fourth option as "range", "high" or "low".
>>>>        
>>>>
>>>I am not sure I understand. We have "user", "context" and "both", where
>>>type in the context can be controlled through type-member policy rules
>>>and the mls range is inherited from the process. Can you give an example
>>>of what context the instance would have with "range" or "high" or "low"?
>>>      
>>>
>>My idea is that the range, high, and low values would be candidates for the
>>file name.
>>    
>>
>[...]
>  
>
>>Probably the easiest thing to do is to default to including the entire
>>security context of the process in the directory name.
>>    
>>
>
>One thing that I consider to be necessary is to allow the administrator to 
>determine in which situations the PI directories should be shared.  Using a 
>default that has the full context including range will work, but many admins 
>will want finer grained control.
>
>For example if the aim is to separate MLS ranges such that file names can not 
>be used to accidentally reveal secret data then there may not be a need for 
>separate Unix UIDs to have different directories, and directory names could 
>be based on range alone.
>
>Another possibility is when running the strict policy a user might have 
>multiple roles but not want to have a different copy of /tmp for each one.  
>For example if I scp a file to the /tmp directory used for role A then after 
>running newrole to change to role B I will still want to see the file in 
>question (assuming of course that the policy allows access to it).
>
>Then for MCS the issue of whether it's most desirable to base instance 
>directory names on the high or the low level is something that we probably 
>won't ever get an agreement on.
>
>  
>
Just to clarify, it is the instance security context that is important 
from the
perspective of access to it. The inclusion of context in the directory 
name is
just so that the admin can correctly identify them. The earlier incarnation
of the pam namespace module put an md5 hash instead of the more useful
uid+context names.

As far as the ability to control which instances to share, I assume you
can do that with the policy. The namespace module just calls
security_compute_member() to get the context of the instance.
security_compute_member() looks at process context and the
target directory context to arrive at the context for the member(instance).
So you could setup the policy such that different process contexts
return different (or the same, if so desired) contexts for the instance.

-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: pam_namespace

[Janak Desai]

Russell Coker wrote:

>On Monday 08 May 2006 23:44, Janak Desai <janak@us.ibm.com> wrote:
>  
>
>>>>ignore_config_error is only sufficient if there is no possibility of
>>>>any option misbehaving - in particular, we can't have an option 'both'
>>>>that works in MCS/MLS environments as well - we'll need to have a
>>>>both_mcs if the mcs label is to be included, and a both_no_mcs if it
>>>>should behave in the same way as the non-mcs 'both'.
>>>>        
>>>>
>>>Having "both" and "both_no_mcs" is confusing.  Maybe it would be best to
>>>have "user" and "context" as separate items to replace "both" and then
>>>support a fourth option as "range", "high" or "low".
>>>      
>>>
>>I am not sure I understand. We have "user", "context" and "both", where
>>type in the context can be controlled through type-member policy rules and
>>the mls range is inherited from the process. Can you give an example of what
>>context the instance would have with "range" or "high" or "low"?
>>    
>>
>
>My idea is that the range, high, and low values would be candidates for the 
>file name.
>
>The current code in rawhide does not inherit the range from the process, are 
>you referring to a newer version of pam_namespace.c?  If so where can I find 
>a copy?
>  
>
Range inheritance is done in the kernel when type member rules are 
defined for
the type that is being polyinstantiated. So when pam_namespace calls 
security_compute_member()
to compute the context of the instance directory, the range in the 
context returned, will
be the same as the process range when polyinstantiation is being done 
for the associated type.
Basically, user space will just call security_compute_member() to arrive 
at the context
of the polyinstantiated instance.

>For inheriting the range to be viable then we need to support names for the 
>temporary directory based on the range so that different ranges for the 
>current user can be supported.  I am not sure whether we will support 
>choosing a range at login time, if we do then we must support this.  If we 
>will never support choosing the range at login time there is the case of su 
>which may be run after a newrole command and therefore be used to enter the 
>same user role in different contexts.  Another case is that of a user who has 
>their default range changed by the sys-admin while they are logged in (this 
>may be uncommon in the case of MLS use but for MCS I expect it to be regular 
>system use).
>
>Probably the easiest thing to do is to default to including the entire 
>security context of the process in the directory name.
>  
>
I believe, we are doing that now.

>  
>
>>In general I am not sure about the intermidiate directory itself. To me,
>>it complicates the mechanism and mixes it with policy. When using
>>polyinstantiation with SELinux, you can tighten up access to instances by
>>type-member rules and by inheriting mls label of the process.
>>    
>>
>
>For the case of strict and mls policy, yes.  For targeted policy we don't have 
>such protections.
>  
>
I am not sure I follow. Why can't you setup type member rules in 
targeted policy?

>  
>
>>In non-SELinux use, an admin can seperate users from each
>>other by configuring the instance to be a subdirectory of the
>>polyinstantiated directory.
>>We can get additional protection from non-root daemons by creating an
>>intermdiate directory. However, is it really worth the trouble to protect a
>>user's instance of /tmp or /var/tmp beyond what will be protected by sticky
>>bits? Since instances inherit the polyinstantiated directory's mode, $HOME
>>etc are already protected from non-root daemons.
>>    
>>
>
>$HOME is protected, but as $HOME will only be PI on a strict or MLS system 
>this isn't an issue.
>
>Sticky bits provide no protection, the entire purpose of PI for /tmp is that 
>the sticky bits don't do an adequate job!  Substituting a race condition 
>attack on /tmp for a race condition attack on /tmp/tmp.inst-user-user is no 
>gain!
>
>Also while we are on the topic, the namespace module needs to handle the case 
>of a directory existing with the wrong permissions or having a file with the 
>name existing.
>
>Currently with pam_namespace.so configured I can prevent a user from logging 
>in by creating a file named /tmp/tmp.inst-user-user.  I can create a 
>directory of that name as another user to take over ownership of another 
>user's instance of /tmp.  I can make /tmp/tmp.inst-user-user a sym-link 
>to /etc which then makes /tmp a copy of /etc for the user who logs in (I'm 
>sure that there is potential for an exploit here).
>  
>
yes, probably. However, remember, ordinary users will not see the "real" 
/tmp. So
for anyone who is trying to create directory/symlink with the same name 
as the
instance of another user, they will need permission to unmount their 
polyinstantiated
/tmp first. If a user has power to perform mount/unmount, they can 
really subvert
the polyinstanted mechanism because it is based on giving a user a 
namespace that
he/she cannot change.

>There are two algorithms that occur to me to deal with these issues, one is 
>that if there is an existing directory of the name in question then we first 
>check the ownership, permissions, and context against what we would create, 
>if they don't match (or if the name is taken by something other than a 
>directory) then we append ".1" to the name and try again, we keep either 
>incrementing the number we append until we find a directory that has 
>appropriate perms or which does not exist.  The other algorithm is to have a 
>specific subdirectory created with a name such as /tmp/.inst that has 
>restrictive permissions under both Unix and SE Linux and then create all 
>directories under that.  This second algorithm also removes the need to 
>create two levels of directory each time a user logs in (saves 4K of disk 
>space per session and a tiny amount of CPU time).
>
>The first algorithm doesn't deal well with DOS attacks.  The second algorithm 
>has the creation of a permanent directory under /tmp with the need to create 
>the directory very early in the boot process for systems with tmpfs on /tmp 
>(not SE Linux as we don't have policy support for tmpfs on /tmp).  Creating a 
>directory in such a manner is messy, but there is precedent for it 
>in /tmp/.X11-unix, /tmp/.ICE-unix, and /tmp/.font-unix.
>  
>
What about other directories that are being polyinstantiated? What if 
the admin decides
to add/delete a directory from the list to polyinstantiate? I do see 
your point that there
are exploits that we can address with this, but I am still not conviced 
that it's worth the
trouble to address them.

>  
>
>>>>>On a non-SE system "0wned uid=0 daemon" is considered to be game-over.
>>>>>          
>>>>>
>>>>So you're saying that on a non-SE system, namespaces are *not* in the
>>>>least expected to slow down a rogue daemon.  OK, as long as we make a
>>>>note of that..
>>>>        
>>>>
>>>Not at all!  I'm saying that on a non-SE system a uid=0 process can do
>>>anything it wants so there's no point even attempting to constrain such a
>>>process.  However nowadays most daemons never run as root, and the ones
>>>that do run as root drop their privs for as much code as possible.
>>>
>>>Attack by a non-root daemon on a non-SE system is something we want to
>>>prevent.
>>>      
>>>
>>Again, this attack, valid only on non-SELinux mode, would only
>>consititute the
>>daemon creating files in user's instance of /tmp or /var/tmp. Because of
>>the sticky bit,
>>the daemon will not be able delete any files there, right?
>>    
>>
>
>The attack is not only valid on non-SE Linux mode.  Such attacks that work on 
>non-SE Linux will also mostly work on targeted systems.  On strict systems 
>bugs and design flaws that permit integrity attacks on non-SE and targeted 
>systems will generally be expected to become DOS attacks.
>
>I think that generally deleting files is the last thing we are concerned 
>about.  Some systems use a ram disk for /tmp by default (Solaris), some 
>systems clean out /tmp on boot by default (Debian).  Generally /tmp should be 
>considered as transient.  The concerns for /tmp are race condition attacks on 
>system integrity (causing a process to expose or corrupt data when it is 
>operating on files other than the ones the programmer or the user intended it 
>to use) and exposing secret data through revealing sensitive file names.  The 
>current operation of the pam_namespace.so module fails on the issue of 
>protecting secret file names and doesn't do very well on the issue of 
>protecting integrity against race conditions.
>
>  
>
Yes, I agree that if you manage to get a shell as root through some 
application exploit,
pam_namespace will not contain the damage because you can manipulate your
namespace. However, it is quite possible that if you can mount/unmount, 
you can
also bypass standard dac checks on a more restrictive intermediate 
directory. Maybe
I can add more information to the man page regarding what pam_namespace
will or will not guard against.

-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: pam_namespace

[Russell Coker]

On Wednesday 10 May 2006 00:13, Janak Desai <janak@us.ibm.com> wrote:
> >My idea is that the range, high, and low values would be candidates for
> > the file name.
> >
> >The current code in rawhide does not inherit the range from the process,
> > are you referring to a newer version of pam_namespace.c?  If so where can
> > I find a copy?
>
> Range inheritance is done in the kernel when type member rules are
> defined for
> the type that is being polyinstantiated. So when pam_namespace calls
> security_compute_member()
> to compute the context of the instance directory, the range in the
> context returned, will
> be the same as the process range when polyinstantiation is being done
> for the associated type.

OK, this is going to break on MCS where ranged objects on disk are not 
permitted.

> >>In general I am not sure about the intermidiate directory itself. To me,
> >>it complicates the mechanism and mixes it with policy. When using
> >>polyinstantiation with SELinux, you can tighten up access to instances by
> >>type-member rules and by inheriting mls label of the process.
> >
> >For the case of strict and mls policy, yes.  For targeted policy we don't
> > have such protections.
>
> I am not sure I follow. Why can't you setup type member rules in
> targeted policy?

Sure you can, but when all user logins have unconfined_t as the domain SE 
Linux protections (other than MCS protections) won't apply.  MCS protections 
are a long way from what is required in this regard.

> >$HOME is protected, but as $HOME will only be PI on a strict or MLS system
> >this isn't an issue.
> >
> >Sticky bits provide no protection, the entire purpose of PI for /tmp is
> > that the sticky bits don't do an adequate job!  Substituting a race
> > condition attack on /tmp for a race condition attack on
> > /tmp/tmp.inst-user-user is no gain!
> >
> >Also while we are on the topic, the namespace module needs to handle the
> > case of a directory existing with the wrong permissions or having a file
> > with the name existing.
> >
> >Currently with pam_namespace.so configured I can prevent a user from
> > logging in by creating a file named /tmp/tmp.inst-user-user.  I can
> > create a directory of that name as another user to take over ownership of
> > another user's instance of /tmp.  I can make /tmp/tmp.inst-user-user a
> > sym-link to /etc which then makes /tmp a copy of /etc for the user who
> > logs in (I'm sure that there is potential for an exploit here).
>
> yes, probably. However, remember, ordinary users will not see the "real"
> /tmp.

Apart from users who are listed as exceptions in /etc/security/namespace.conf.

Also applying the "defense in depth" principle we want to make sure that it 
offers protection even in the case of misconfiguration or other situations 
that result in user sessions running in the global name space.

Imagine that an administrator misconfigures the system such that crond does 
not use unshared name spaces, that would then permit a hostile user to attack 
other users and daemons via race conditions and DOS attacks.

> So 
> for anyone who is trying to create directory/symlink with the same name
> as the
> instance of another user, they will need permission to unmount their
> polyinstantiated
> /tmp first.

Or merely login first.  Consider the case of a company that has a fixed scheme 
for allocating login names, anyone who hears of a new employee joining can 
guess the account name and start a DOS attack by creating such links or 
files.

> If a user has power to perform mount/unmount, they can 
> really subvert
> the polyinstanted mechanism because it is based on giving a user a
> namespace that
> he/she cannot change.

True, but it can be done with a lot less than that.

> >There are two algorithms that occur to me to deal with these issues, one
> > is that if there is an existing directory of the name in question then we
> > first check the ownership, permissions, and context against what we would
> > create, if they don't match (or if the name is taken by something other
> > than a directory) then we append ".1" to the name and try again, we keep
> > either incrementing the number we append until we find a directory that
> > has appropriate perms or which does not exist.  The other algorithm is to
> > have a specific subdirectory created with a name such as /tmp/.inst that
> > has restrictive permissions under both Unix and SE Linux and then create
> > all directories under that.  This second algorithm also removes the need
> > to create two levels of directory each time a user logs in (saves 4K of
> > disk space per session and a tiny amount of CPU time).
> >
> >The first algorithm doesn't deal well with DOS attacks.  The second
> > algorithm has the creation of a permanent directory under /tmp with the
> > need to create the directory very early in the boot process for systems
> > with tmpfs on /tmp (not SE Linux as we don't have policy support for
> > tmpfs on /tmp).  Creating a directory in such a manner is messy, but
> > there is precedent for it in /tmp/.X11-unix, /tmp/.ICE-unix, and
> > /tmp/.font-unix.
>
> What about other directories that are being polyinstantiated? What if
> the admin decides to add/delete a directory from the list to
> polyinstantiate? 

How are these problems with what I suggested?  /var/tmp/.inst and $HOME/.inst 
will work just as well as any other naming method.  If the admin deletes a 
directory from the list then there will be a .inst directory hanging around 
that they will have to manually remove, which incidentally should be easier 
than removing a bunch of "tmp.inst*" directories.

Adding ".1", ".2", etc to the end of the directory name may expand the list of 
directories to remove, but this is only in the case of attack (which will 
involve extra work for the sys-admin no matter how you look at it).

Adding a directory to the PI list is no big deal, with the second algorithm 
they just have to create the ".inst" directory first, with the first 
algorithm they don't need to do anything.

> I do see your point that there are exploits that we can address with this,
> but I am still not conviced that it's worth the trouble to address them.

I don't think that it's any great trouble.  I have already described how to 
solve every problem that I can imagine with each of these methods.

> >>>>>On a non-SE system "0wned uid=0 daemon" is considered to be game-over.
> >>>>
> >>>>So you're saying that on a non-SE system, namespaces are *not* in the
> >>>>least expected to slow down a rogue daemon.  OK, as long as we make a
> >>>>note of that..
> >>>
> >>>Not at all!  I'm saying that on a non-SE system a uid=0 process can do
> >>>anything it wants so there's no point even attempting to constrain such
> >>> a process.  However nowadays most daemons never run as root, and the
> >>> ones that do run as root drop their privs for as much code as possible.
> >>>
> >>>Attack by a non-root daemon on a non-SE system is something we want to
> >>>prevent.
> >>
> >>Again, this attack, valid only on non-SELinux mode, would only
> >>consititute the
> >>daemon creating files in user's instance of /tmp or /var/tmp. Because of
> >>the sticky bit,
> >>the daemon will not be able delete any files there, right?
> >
> >The attack is not only valid on non-SE Linux mode.  Such attacks that work
> > on non-SE Linux will also mostly work on targeted systems.  On strict
> > systems bugs and design flaws that permit integrity attacks on non-SE and
> > targeted systems will generally be expected to become DOS attacks.
> >
> >I think that generally deleting files is the last thing we are concerned
> >about.  Some systems use a ram disk for /tmp by default (Solaris), some
> >systems clean out /tmp on boot by default (Debian).  Generally /tmp should
> > be considered as transient.  The concerns for /tmp are race condition
> > attacks on system integrity (causing a process to expose or corrupt data
> > when it is operating on files other than the ones the programmer or the
> > user intended it to use) and exposing secret data through revealing
> > sensitive file names.  The current operation of the pam_namespace.so
> > module fails on the issue of protecting secret file names and doesn't do
> > very well on the issue of protecting integrity against race conditions.
>
> Yes, I agree that if you manage to get a shell as root through some
> application exploit,
> pam_namespace will not contain the damage because you can manipulate your
> namespace. However, it is quite possible that if you can mount/unmount,
> you can
> also bypass standard dac checks on a more restrictive intermediate
> directory. Maybe
> I can add more information to the man page regarding what pam_namespace
> will or will not guard against.

I'm not sure that you understood my previous messages.

Root shell on non-SE system is game-over.  Root shell on SE system is a 
situation we want to contain, and we can contain it.  In most cases with the 
strict and MLS policies a root process will not have the ability to umount 
anything and in some cases it won't have dac_override.

We want to have very restrictive Unix permissions on accessing the PI 
directories (I suggest making /tmp/.inst mode 000) so that a process must 
have dac_override to even get started as well as having restrictive 
permissions under the domain-type part of SE Linux.

Incidentally we can probably reduce the number of daemons with dac_override 
capability, in many cases such access was granted because it's easier than 
redesigning the application in a better manner.

-- 
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: pam_namespace

[Janak Desai]

Russell Coker wrote:

>On Wednesday 10 May 2006 00:13, Janak Desai <janak@us.ibm.com> wrote:
>  
>
>>>My idea is that the range, high, and low values would be candidates for
>>>the file name.
>>>
>>>The current code in rawhide does not inherit the range from the process,
>>>are you referring to a newer version of pam_namespace.c?  If so where can
>>>I find a copy?
>>>      
>>>
>>Range inheritance is done in the kernel when type member rules are
>>defined for
>>the type that is being polyinstantiated. So when pam_namespace calls
>>security_compute_member()
>>to compute the context of the instance directory, the range in the
>>context returned, will
>>be the same as the process range when polyinstantiation is being done
>>for the associated type.
>>    
>>
>
>OK, this is going to break on MCS where ranged objects on disk are not 
>permitted.
>  
>
Ok, I will have to read up on MCS to understand this breakage. I do want to
clarify though that type member rules are associated with the directory 
type.
So for example, tmp_t will have type member rules associated with it. The
mechanism does not require that /tmp be ranged.

>  
>
>>>>In general I am not sure about the intermidiate directory itself. To me,
>>>>it complicates the mechanism and mixes it with policy. When using
>>>>polyinstantiation with SELinux, you can tighten up access to instances by
>>>>type-member rules and by inheriting mls label of the process.
>>>>        
>>>>
>>>For the case of strict and mls policy, yes.  For targeted policy we don't
>>>have such protections.
>>>      
>>>
>>I am not sure I follow. Why can't you setup type member rules in
>>targeted policy?
>>    
>>
>
>Sure you can, but when all user logins have unconfined_t as the domain SE 
>Linux protections (other than MCS protections) won't apply.  MCS protections 
>are a long way from what is required in this regard.
>
>  
>
Agreed. Although targeted policy does constrain many daemons (that's what we
are concerned about, right?), I can see that there might be daemons that 
are running
in unconfined_t whose vulnarabilities can be exploited to gain a 
non-root shell
running in unconfined_t. Just wanted to point out that since we are 
concerned about
non-root daemons, that targeted does constrain many of them.

>>>$HOME is protected, but as $HOME will only be PI on a strict or MLS system
>>>this isn't an issue.
>>>
>>>Sticky bits provide no protection, the entire purpose of PI for /tmp is
>>>that the sticky bits don't do an adequate job!  Substituting a race
>>>condition attack on /tmp for a race condition attack on
>>>/tmp/tmp.inst-user-user is no gain!
>>>
>>>Also while we are on the topic, the namespace module needs to handle the
>>>case of a directory existing with the wrong permissions or having a file
>>>with the name existing.
>>>
>>>Currently with pam_namespace.so configured I can prevent a user from
>>>logging in by creating a file named /tmp/tmp.inst-user-user.  I can
>>>create a directory of that name as another user to take over ownership of
>>>another user's instance of /tmp.  I can make /tmp/tmp.inst-user-user a
>>>sym-link to /etc which then makes /tmp a copy of /etc for the user who
>>>logs in (I'm sure that there is potential for an exploit here).
>>>      
>>>
>>yes, probably. However, remember, ordinary users will not see the "real"
>>/tmp.
>>    
>>
>
>Apart from users who are listed as exceptions in /etc/security/namespace.conf.
>
>Also applying the "defense in depth" principle we want to make sure that it 
>offers protection even in the case of misconfiguration or other situations 
>that result in user sessions running in the global name space.
>
>Imagine that an administrator misconfigures the system such that crond does 
>not use unshared name spaces, that would then permit a hostile user to attack 
>other users and daemons via race conditions and DOS attacks.
>
>  
>
Users listed as exceptions in namespace.conf is an intentional action of 
the admin.
I agree that we should try and limit the damage from misconfiguration. 
However, there
is always a trade-off between how far you will go to protect against 
misconfiguration.
IMHO adding .inst with a very restrictive mode of 000 in the polydir 
does not
protect you a whole lot more against the type of attack that you are 
describing.
If we assume that the user has managed to gain access to the original 
/tmp (by
gaining unmount privs or by subverting an unconfined daemon running
in system namespace) then they can still write in /tmp. They can just move
.inst to junk.

>>So 
>>for anyone who is trying to create directory/symlink with the same name
>>as the
>>instance of another user, they will need permission to unmount their
>>polyinstantiated
>>/tmp first.
>>    
>>
>
>Or merely login first.  Consider the case of a company that has a fixed scheme 
>for allocating login names, anyone who hears of a new employee joining can 
>guess the account name and start a DOS attack by creating such links or 
>files.
>
>  
>
Again, it is not the question of guessing the name but having access to 
the original
polydir. Because the original polydir is obscured when they login, they 
won't be
able to create such files/links. If they can manage access to original 
polydir, not
having access to .inst won't stop them because they can just move it 
aside, and
continue with their attack.

>>If a user has power to perform mount/unmount, they can 
>>really subvert
>>the polyinstanted mechanism because it is based on giving a user a
>>namespace that
>>he/she cannot change.
>>    
>>
>
>True, but it can be done with a lot less than that.
>
>  
>
>>>There are two algorithms that occur to me to deal with these issues, one
>>>is that if there is an existing directory of the name in question then we
>>>first check the ownership, permissions, and context against what we would
>>>create, if they don't match (or if the name is taken by something other
>>>than a directory) then we append ".1" to the name and try again, we keep
>>>either incrementing the number we append until we find a directory that
>>>has appropriate perms or which does not exist.  The other algorithm is to
>>>have a specific subdirectory created with a name such as /tmp/.inst that
>>>has restrictive permissions under both Unix and SE Linux and then create
>>>all directories under that.  This second algorithm also removes the need
>>>to create two levels of directory each time a user logs in (saves 4K of
>>>disk space per session and a tiny amount of CPU time).
>>>
>>>The first algorithm doesn't deal well with DOS attacks.  The second
>>>algorithm has the creation of a permanent directory under /tmp with the
>>>need to create the directory very early in the boot process for systems
>>>with tmpfs on /tmp (not SE Linux as we don't have policy support for
>>>tmpfs on /tmp).  Creating a directory in such a manner is messy, but
>>>there is precedent for it in /tmp/.X11-unix, /tmp/.ICE-unix, and
>>>/tmp/.font-unix.
>>>      
>>>
>>What about other directories that are being polyinstantiated? What if
>>the admin decides to add/delete a directory from the list to
>>polyinstantiate? 
>>    
>>
>
>How are these problems with what I suggested?  /var/tmp/.inst and $HOME/.inst 
>will work just as well as any other naming method.  If the admin deletes a 
>directory from the list then there will be a .inst directory hanging around 
>that they will have to manually remove, which incidentally should be easier 
>than removing a bunch of "tmp.inst*" directories.
>
>Adding ".1", ".2", etc to the end of the directory name may expand the list of 
>directories to remove, but this is only in the case of attack (which will 
>involve extra work for the sys-admin no matter how you look at it).
>
>Adding a directory to the PI list is no big deal, with the second algorithm 
>they just have to create the ".inst" directory first, with the first 
>algorithm they don't need to do anything.
>  
>
True. I agree that managing .inst won't be too much of a trouble.

>  
>
>>I do see your point that there are exploits that we can address with this,
>>but I am still not conviced that it's worth the trouble to address them.
>>    
>>
>
>I don't think that it's any great trouble.  I have already described how to 
>solve every problem that I can imagine with each of these methods.
>
>  
>
>>>>>>>On a non-SE system "0wned uid=0 daemon" is considered to be game-over.
>>>>>>>              
>>>>>>>
>>>>>>So you're saying that on a non-SE system, namespaces are *not* in the
>>>>>>least expected to slow down a rogue daemon.  OK, as long as we make a
>>>>>>note of that..
>>>>>>            
>>>>>>
>>>>>Not at all!  I'm saying that on a non-SE system a uid=0 process can do
>>>>>anything it wants so there's no point even attempting to constrain such
>>>>>a process.  However nowadays most daemons never run as root, and the
>>>>>ones that do run as root drop their privs for as much code as possible.
>>>>>
>>>>>Attack by a non-root daemon on a non-SE system is something we want to
>>>>>prevent.
>>>>>          
>>>>>
>>>>Again, this attack, valid only on non-SELinux mode, would only
>>>>consititute the
>>>>daemon creating files in user's instance of /tmp or /var/tmp. Because of
>>>>the sticky bit,
>>>>the daemon will not be able delete any files there, right?
>>>>        
>>>>
>>>The attack is not only valid on non-SE Linux mode.  Such attacks that work
>>>on non-SE Linux will also mostly work on targeted systems.  On strict
>>>systems bugs and design flaws that permit integrity attacks on non-SE and
>>>targeted systems will generally be expected to become DOS attacks.
>>>
>>>I think that generally deleting files is the last thing we are concerned
>>>about.  Some systems use a ram disk for /tmp by default (Solaris), some
>>>systems clean out /tmp on boot by default (Debian).  Generally /tmp should
>>>be considered as transient.  The concerns for /tmp are race condition
>>>attacks on system integrity (causing a process to expose or corrupt data
>>>when it is operating on files other than the ones the programmer or the
>>>user intended it to use) and exposing secret data through revealing
>>>sensitive file names.  The current operation of the pam_namespace.so
>>>module fails on the issue of protecting secret file names and doesn't do
>>>very well on the issue of protecting integrity against race conditions.
>>>      
>>>
>>Yes, I agree that if you manage to get a shell as root through some
>>application exploit,
>>pam_namespace will not contain the damage because you can manipulate your
>>namespace. However, it is quite possible that if you can mount/unmount,
>>you can
>>also bypass standard dac checks on a more restrictive intermediate
>>directory. Maybe
>>I can add more information to the man page regarding what pam_namespace
>>will or will not guard against.
>>    
>>
>
>I'm not sure that you understood my previous messages.
>
>Root shell on non-SE system is game-over.  Root shell on SE system is a 
>situation we want to contain, and we can contain it.  In most cases with the 
>strict and MLS policies a root process will not have the ability to umount 
>anything and in some cases it won't have dac_override.
>
>We want to have very restrictive Unix permissions on accessing the PI 
>directories (I suggest making /tmp/.inst mode 000) so that a process must 
>have dac_override to even get started as well as having restrictive 
>permissions under the domain-type part of SE Linux.
>
>Incidentally we can probably reduce the number of daemons with dac_override 
>capability, in many cases such access was granted because it's easier than 
>redesigning the application in a better manner.
>  
>
Yes, but as long as the original polydir (/tmp for example) is writable 
by the
attacking process, they can move .inst aside.

-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: pam_namespace

[Russell Coker]

On Thursday 11 May 2006 00:10, Janak Desai <janak@us.ibm.com> wrote:
> >>>>In general I am not sure about the intermidiate directory itself. To
> >>>> me, it complicates the mechanism and mixes it with policy. When using
> >>>> polyinstantiation with SELinux, you can tighten up access to instances
> >>>> by type-member rules and by inheriting mls label of the process.
> >>>
> >>>For the case of strict and mls policy, yes.  For targeted policy we
> >>> don't have such protections.
> >>
> >>I am not sure I follow. Why can't you setup type member rules in
> >>targeted policy?
> >
> >Sure you can, but when all user logins have unconfined_t as the domain SE
> >Linux protections (other than MCS protections) won't apply.  MCS
> > protections are a long way from what is required in this regard.
>
> Agreed. Although targeted policy does constrain many daemons (that's what
> we are concerned about, right?), I can see that there might be daemons that
> are running
> in unconfined_t whose vulnarabilities can be exploited to gain a
> non-root shell
> running in unconfined_t. Just wanted to point out that since we are
> concerned about
> non-root daemons, that targeted does constrain many of them.

1) Attack by user on user
2) Attack by user on daemon
3.1) Attack by non-root daemon on user
3.2) Attack by root daemon on user (will always succeed without SE Linux)

I believe that the above are the attack scenarios we should consider and the 
below are the types of attack we should consider.

A) Race-condition attacks on the integrity of processes and data (sym-link 
attacks, race conditions on renaming objects, or pre-creating a file to take 
ownership of data)
B) Leaks of confidential data via secrets in file names
C) Denial Of Service (DOS) attacks based on race conditions and pre-allocating 
file/directory names

The current implementation of pam_namespace does not address attack scenario 
3.1 on non-SE systems and attack scenarios 3.1 and 3.2 on strict systems.  
Even on MLS systems there may be a vulnerability to attack C and possibly 
attack B as well.

> >>>Currently with pam_namespace.so configured I can prevent a user from
> >>>logging in by creating a file named /tmp/tmp.inst-user-user.  I can
> >>>create a directory of that name as another user to take over ownership
> >>> of another user's instance of /tmp.  I can make /tmp/tmp.inst-user-user
> >>> a sym-link to /etc which then makes /tmp a copy of /etc for the user
> >>> who logs in (I'm sure that there is potential for an exploit here).
> >>
> >>yes, probably. However, remember, ordinary users will not see the "real"
> >>/tmp.
> >
> >Apart from users who are listed as exceptions in
> > /etc/security/namespace.conf.
> >
> >Also applying the "defense in depth" principle we want to make sure that
> > it offers protection even in the case of misconfiguration or other
> > situations that result in user sessions running in the global name space.
> >
> >Imagine that an administrator misconfigures the system such that crond
> > does not use unshared name spaces, that would then permit a hostile user
> > to attack other users and daemons via race conditions and DOS attacks.
>
> Users listed as exceptions in namespace.conf is an intentional action of
> the admin.

Which does not mean that they are fully trusted users who should be permitted 
to override security measures that protect other users.

> I agree that we should try and limit the damage from misconfiguration.
> However, there
> is always a trade-off between how far you will go to protect against
> misconfiguration.
> IMHO adding .inst with a very restrictive mode of 000 in the polydir
> does not
> protect you a whole lot more against the type of attack that you are
> describing.
> If we assume that the user has managed to gain access to the original
> /tmp (by
> gaining unmount privs or by subverting an unconfined daemon running
> in system namespace) then they can still write in /tmp. They can just move
> .inst to junk.

If the user gains access to the real version of /tmp by calling umount() then 
you are probably correct.  If however the user gains access to the real 
version of /tmp by exploiting a buggy login program (maybe the login program 
has a bug that skips some PAM session modules), by being granted such access 
to the system by an intentional action of the sys-admin (just because the 
sys-admin gave them some privs that most users don't get that doesn't mean 
they are trusted), by remaining logged in since before the administrator 
enabled namespaces in the configuration, or any of the other possible methods 
then having a .inst directory with mode 000 will save you.

Also I believe that pam_namespace should offer as many benefits as possible to 
non-SE systems.  With the current code there is no protection against attack 
scenario 3.1.

> True. I agree that managing .inst won't be too much of a trouble.

I believe that in many situations a .inst directory would be less trouble than 
the alternative.

The current situation of having directories created for security purposes in a 
mode 1777 directory is far from optimal.  Having a .inst directory 
created/verified in single-user mode at boot time removes entire categories 
of race condition attacks from the threat list.

> >I'm not sure that you understood my previous messages.
> >
> >Root shell on non-SE system is game-over.  Root shell on SE system is a
> >situation we want to contain, and we can contain it.  In most cases with
> > the strict and MLS policies a root process will not have the ability to
> > umount anything and in some cases it won't have dac_override.
> >
> >We want to have very restrictive Unix permissions on accessing the PI
> >directories (I suggest making /tmp/.inst mode 000) so that a process must
> >have dac_override to even get started as well as having restrictive
> >permissions under the domain-type part of SE Linux.
> >
> >Incidentally we can probably reduce the number of daemons with
> > dac_override capability, in many cases such access was granted because
> > it's easier than redesigning the application in a better manner.
>
> Yes, but as long as the original polydir (/tmp for example) is writable
> by the
> attacking process, they can move .inst aside.

/tmp is owned by root so a root process can rename any object under Unix 
permissions.  Root on a non-SE system or as unconfined_t on a targeted system 
is game-over.  Root on a SE system running strict or mls policy will not be 
able to rename the .inst directory if we give it a suitable type and only 
permit the administrator and the login programs to have any access to it.

I think that this case is covered too.

-- 
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: pam_namespace

[Janak Desai]

Russell Coker wrote:

>On Thursday 11 May 2006 00:10, Janak Desai <janak@us.ibm.com> wrote:
>  
>
>>>>>>In general I am not sure about the intermidiate directory itself. To
>>>>>>me, it complicates the mechanism and mixes it with policy. When using
>>>>>>polyinstantiation with SELinux, you can tighten up access to instances
>>>>>>by type-member rules and by inheriting mls label of the process.
>>>>>>            
>>>>>>
>>>>>For the case of strict and mls policy, yes.  For targeted policy we
>>>>>don't have such protections.
>>>>>          
>>>>>
>>>>I am not sure I follow. Why can't you setup type member rules in
>>>>targeted policy?
>>>>        
>>>>
>>>Sure you can, but when all user logins have unconfined_t as the domain SE
>>>Linux protections (other than MCS protections) won't apply.  MCS
>>>protections are a long way from what is required in this regard.
>>>      
>>>
>>Agreed. Although targeted policy does constrain many daemons (that's what
>>we are concerned about, right?), I can see that there might be daemons that
>>are running
>>in unconfined_t whose vulnarabilities can be exploited to gain a
>>non-root shell
>>running in unconfined_t. Just wanted to point out that since we are
>>concerned about
>>non-root daemons, that targeted does constrain many of them.
>>    
>>
>
>1) Attack by user on user
>2) Attack by user on daemon
>3.1) Attack by non-root daemon on user
>3.2) Attack by root daemon on user (will always succeed without SE Linux)
>
>I believe that the above are the attack scenarios we should consider and the 
>below are the types of attack we should consider.
>
>A) Race-condition attacks on the integrity of processes and data (sym-link 
>attacks, race conditions on renaming objects, or pre-creating a file to take 
>ownership of data)
>B) Leaks of confidential data via secrets in file names
>C) Denial Of Service (DOS) attacks based on race conditions and pre-allocating 
>file/directory names
>
>The current implementation of pam_namespace does not address attack scenario 
>3.1 on non-SE systems and attack scenarios 3.1 and 3.2 on strict systems.  
>Even on MLS systems there may be a vulnerability to attack C and possibly 
>attack B as well.
>
>  
>
>>>>>Currently with pam_namespace.so configured I can prevent a user from
>>>>>logging in by creating a file named /tmp/tmp.inst-user-user.  I can
>>>>>create a directory of that name as another user to take over ownership
>>>>>of another user's instance of /tmp.  I can make /tmp/tmp.inst-user-user
>>>>>a sym-link to /etc which then makes /tmp a copy of /etc for the user
>>>>>who logs in (I'm sure that there is potential for an exploit here).
>>>>>          
>>>>>
>>>>yes, probably. However, remember, ordinary users will not see the "real"
>>>>/tmp.
>>>>        
>>>>
>>>Apart from users who are listed as exceptions in
>>>/etc/security/namespace.conf.
>>>
>>>Also applying the "defense in depth" principle we want to make sure that
>>>it offers protection even in the case of misconfiguration or other
>>>situations that result in user sessions running in the global name space.
>>>
>>>Imagine that an administrator misconfigures the system such that crond
>>>does not use unshared name spaces, that would then permit a hostile user
>>>to attack other users and daemons via race conditions and DOS attacks.
>>>      
>>>
>>Users listed as exceptions in namespace.conf is an intentional action of
>>the admin.
>>    
>>
>
>Which does not mean that they are fully trusted users who should be permitted 
>to override security measures that protect other users.
>
>  
>
>>I agree that we should try and limit the damage from misconfiguration.
>>However, there
>>is always a trade-off between how far you will go to protect against
>>misconfiguration.
>>IMHO adding .inst with a very restrictive mode of 000 in the polydir
>>does not
>>protect you a whole lot more against the type of attack that you are
>>describing.
>>If we assume that the user has managed to gain access to the original
>>/tmp (by
>>gaining unmount privs or by subverting an unconfined daemon running
>>in system namespace) then they can still write in /tmp. They can just move
>>.inst to junk.
>>    
>>
>
>If the user gains access to the real version of /tmp by calling umount() then 
>you are probably correct.  If however the user gains access to the real 
>version of /tmp by exploiting a buggy login program (maybe the login program 
>has a bug that skips some PAM session modules), by being granted such access 
>to the system by an intentional action of the sys-admin (just because the 
>sys-admin gave them some privs that most users don't get that doesn't mean 
>they are trusted), by remaining logged in since before the administrator 
>enabled namespaces in the configuration, or any of the other possible methods 
>then having a .inst directory with mode 000 will save you.
>  
>
How? If an ordinary user is able to get access to real /tmp he or she 
will be able rename
the .inst directory that is owned by root (or anyone else for that 
matter) even if it is 000.
rename only checks the write persmission against the parent directory.

>Also I believe that pam_namespace should offer as many benefits as possible to 
>non-SE systems.  With the current code there is no protection against attack 
>scenario 3.1.
>
>  
>
>>True. I agree that managing .inst won't be too much of a trouble.
>>    
>>
>
>I believe that in many situations a .inst directory would be less trouble than 
>the alternative.
>
>The current situation of having directories created for security purposes in a 
>mode 1777 directory is far from optimal.  Having a .inst directory 
>created/verified in single-user mode at boot time removes entire categories 
>of race condition attacks from the threat list.
>
>  
>
>>>I'm not sure that you understood my previous messages.
>>>
>>>Root shell on non-SE system is game-over.  Root shell on SE system is a
>>>situation we want to contain, and we can contain it.  In most cases with
>>>the strict and MLS policies a root process will not have the ability to
>>>umount anything and in some cases it won't have dac_override.
>>>
>>>We want to have very restrictive Unix permissions on accessing the PI
>>>directories (I suggest making /tmp/.inst mode 000) so that a process must
>>>have dac_override to even get started as well as having restrictive
>>>permissions under the domain-type part of SE Linux.
>>>
>>>Incidentally we can probably reduce the number of daemons with
>>>dac_override capability, in many cases such access was granted because
>>>it's easier than redesigning the application in a better manner.
>>>      
>>>
>>Yes, but as long as the original polydir (/tmp for example) is writable
>>by the
>>attacking process, they can move .inst aside.
>>    
>>
>
>/tmp is owned by root so a root process can rename any object under Unix 
>permissions.  Root on a non-SE system or as unconfined_t on a targeted system 
>is game-over.  Root on a SE system running strict or mls policy will not be 
>able to rename the .inst directory if we give it a suitable type and only 
>permit the administrator and the login programs to have any access to it.
>
>I think that this case is covered too.
>
>  
>


--
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: pam_namespace

[Rogelio Serrano]

On 5/11/06, Janak Desai <janak@us.ibm.com> wrote:
> Russell Coker wrote:
>
> >On Thursday 11 May 2006 00:10, Janak Desai <janak@us.ibm.com> wrote:
> >
> >
> >>>>>>In general I am not sure about the intermidiate directory itself. To
> >>>>>>me, it complicates the mechanism and mixes it with policy. When using
> >>>>>>polyinstantiation with SELinux, you can tighten up access to instances
> >>>>>>by type-member rules and by inheriting mls label of the process.
> >>>>>>
> >>>>>>
> >>>>>For the case of strict and mls policy, yes.  For targeted policy we
> >>>>>don't have such protections.
> >>>>>
> >>>>>
> >>>>I am not sure I follow. Why can't you setup type member rules in
> >>>>targeted policy?
> >>>>
> >>>>
> >>>Sure you can, but when all user logins have unconfined_t as the domain SE
> >>>Linux protections (other than MCS protections) won't apply.  MCS
> >>>protections are a long way from what is required in this regard.
> >>>
> >>>
> >>Agreed. Although targeted policy does constrain many daemons (that's what
> >>we are concerned about, right?), I can see that there might be daemons that
> >>are running
> >>in unconfined_t whose vulnarabilities can be exploited to gain a
> >>non-root shell
> >>running in unconfined_t. Just wanted to point out that since we are
> >>concerned about
> >>non-root daemons, that targeted does constrain many of them.
> >>
> >>
> >
> >1) Attack by user on user
> >2) Attack by user on daemon
> >3.1) Attack by non-root daemon on user
> >3.2) Attack by root daemon on user (will always succeed without SE Linux)
> >
> >I believe that the above are the attack scenarios we should consider and the
> >below are the types of attack we should consider.
> >
> >A) Race-condition attacks on the integrity of processes and data (sym-link
> >attacks, race conditions on renaming objects, or pre-creating a file to take
> >ownership of data)
> >B) Leaks of confidential data via secrets in file names
> >C) Denial Of Service (DOS) attacks based on race conditions and pre-allocating
> >file/directory names
> >
> >The current implementation of pam_namespace does not address attack scenario
> >3.1 on non-SE systems and attack scenarios 3.1 and 3.2 on strict systems.
> >Even on MLS systems there may be a vulnerability to attack C and possibly
> >attack B as well.
> >
> >
> >
> >>>>>Currently with pam_namespace.so configured I can prevent a user from
> >>>>>logging in by creating a file named /tmp/tmp.inst-user-user.  I can
> >>>>>create a directory of that name as another user to take over ownership
> >>>>>of another user's instance of /tmp.  I can make /tmp/tmp.inst-user-user
> >>>>>a sym-link to /etc which then makes /tmp a copy of /etc for the user
> >>>>>who logs in (I'm sure that there is potential for an exploit here).
> >>>>>
> >>>>>
> >>>>yes, probably. However, remember, ordinary users will not see the "real"
> >>>>/tmp.
> >>>>
> >>>>
> >>>Apart from users who are listed as exceptions in
> >>>/etc/security/namespace.conf.
> >>>
> >>>Also applying the "defense in depth" principle we want to make sure that
> >>>it offers protection even in the case of misconfiguration or other
> >>>situations that result in user sessions running in the global name space.
> >>>
> >>>Imagine that an administrator misconfigures the system such that crond
> >>>does not use unshared name spaces, that would then permit a hostile user
> >>>to attack other users and daemons via race conditions and DOS attacks.
> >>>
> >>>
> >>Users listed as exceptions in namespace.conf is an intentional action of
> >>the admin.
> >>
> >>
> >
> >Which does not mean that they are fully trusted users who should be permitted
> >to override security measures that protect other users.
> >
> >
> >
> >>I agree that we should try and limit the damage from misconfiguration.
> >>However, there
> >>is always a trade-off between how far you will go to protect against
> >>misconfiguration.
> >>IMHO adding .inst with a very restrictive mode of 000 in the polydir
> >>does not
> >>protect you a whole lot more against the type of attack that you are
> >>describing.
> >>If we assume that the user has managed to gain access to the original
> >>/tmp (by
> >>gaining unmount privs or by subverting an unconfined daemon running
> >>in system namespace) then they can still write in /tmp. They can just move
> >>.inst to junk.
> >>
> >>
> >
> >If the user gains access to the real version of /tmp by calling umount() then
> >you are probably correct.  If however the user gains access to the real
> >version of /tmp by exploiting a buggy login program (maybe the login program
> >has a bug that skips some PAM session modules), by being granted such access
> >to the system by an intentional action of the sys-admin (just because the
> >sys-admin gave them some privs that most users don't get that doesn't mean
> >they are trusted), by remaining logged in since before the administrator
> >enabled namespaces in the configuration, or any of the other possible methods
> >then having a .inst directory with mode 000 will save you.
> >
> >
> How? If an ordinary user is able to get access to real /tmp he or she
> will be able rename

How could ordinary user access real /tmp if /home/user/tmp is mounted
over the real /tmp and other entries of the /dev is also mounted over
by dummy entries and the user is not allowed to create new device
nodes?

> the .inst directory that is owned by root (or anyone else for that
> matter) even if it is 000.
> rename only checks the write persmission against the parent directory.
>
> >Also I believe that pam_namespace should offer as many benefits as possible to
> >non-SE systems.  With the current code there is no protection against attack
> >scenario 3.1.
> >
> >
> >
> >>True. I agree that managing .inst won't be too much of a trouble.
> >>
> >>
> >
> >I believe that in many situations a .inst directory would be less trouble than
> >the alternative.
> >
> >The current situation of having directories created for security purposes in a
> >mode 1777 directory is far from optimal.  Having a .inst directory
> >created/verified in single-user mode at boot time removes entire categories
> >of race condition attacks from the threat list.
> >
> >
> >
> >>>I'm not sure that you understood my previous messages.
> >>>
> >>>Root shell on non-SE system is game-over.  Root shell on SE system is a
> >>>situation we want to contain, and we can contain it.  In most cases with
> >>>the strict and MLS policies a root process will not have the ability to
> >>>umount anything and in some cases it won't have dac_override.
> >>>
> >>>We want to have very restrictive Unix permissions on accessing the PI
> >>>directories (I suggest making /tmp/.inst mode 000) so that a process must
> >>>have dac_override to even get started as well as having restrictive
> >>>permissions under the domain-type part of SE Linux.
> >>>
> >>>Incidentally we can probably reduce the number of daemons with
> >>>dac_override capability, in many cases such access was granted because
> >>>it's easier than redesigning the application in a better manner.
> >>>
> >>>
> >>Yes, but as long as the original polydir (/tmp for example) is writable
> >>by the
> >>attacking process, they can move .inst aside.
> >>
> >>
> >
> >/tmp is owned by root so a root process can rename any object under Unix
> >permissions.  Root on a non-SE system or as unconfined_t on a targeted system
> >is game-over.  Root on a SE system running strict or mls policy will not be
> >able to rename the .inst directory if we give it a suitable type and only
> >permit the administrator and the login programs to have any access to it.
> >
> >I think that this case is covered too.
> >
> >
> >
>
>
> --
> 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.
>


-- 
www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers


--
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: pam_namespace

[Russell Coker]

On Friday 12 May 2006 14:14, "Rogelio Serrano" <rogelio.serrano@gmail.com> 
wrote:
> > >If the user gains access to the real version of /tmp by calling umount()
> > > then you are probably correct.  If however the user gains access to the
> > > real version of /tmp by exploiting a buggy login program (maybe the
> > > login program has a bug that skips some PAM session modules), by being
> > > granted such access to the system by an intentional action of the
> > > sys-admin (just because the sys-admin gave them some privs that most
> > > users don't get that doesn't mean they are trusted), by remaining
> > > logged in since before the administrator enabled namespaces in the
> > > configuration, or any of the other possible methods then having a .inst
> > > directory with mode 000 will save you.
> >
> > How? If an ordinary user is able to get access to real /tmp he or she
> > will be able rename
>
> How could ordinary user access real /tmp if /home/user/tmp is mounted
> over the real /tmp and other entries of the /dev is also mounted over
> by dummy entries and the user is not allowed to create new device
> nodes?

We are not planning to change /dev and other things, although I don't think it 
makes much difference in this regard.  Without SE Linux the permission to 
mount file systems goes along with the permission to create device nodes, and 
with SE Linux the permission to umount file systems goes along with the 
permission to mount file systems.

As mentioned above users can access /tmp by possibly exploiting a bug in a 
login program (note that not all security bugs grant ultimate access, 
sometimes a series of bugs providing excessive privs may be used by an 
attacker), by being granted non-PI access to /tmp by the sys-admin (either 
mistakenly or intentionally), be keeping a login session open since before 
the sys-admin enabled the use of namespaces, and probably other ways that I 
didn't think of.

Also note that renaming the /tmp/.inst directory requires dac_override 
capability (root) as well as suitable SE Linux privs (which won't be granted 
to user processes or daemons).  It has two layers of defense, just the way we 
want it.

-- 
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: pam_namespace

[Russell Coker]

On Sunday 07 May 2006 19:28, Russell Coker <russell@coker.com.au> wrote:
> Of course there's nothing stopping us from modifying a program such as
> runuser or run_init to set up a namespace for a daemon.  In fact we should
> probably make the default behavior of run_init and runuser be the creation
> of a namespace.  It would be easy to create a config file for runuser that
> allows excluding daemons on the basis of executable name, UID, or other
> factors.

One problem we have with separate name spaces is that when the administrator 
mounts a file system the users won't see it.  When the mount point has 
the "user" option in /etc/fstab that won't be such a problem, but for the 
more common cases of autofs and the automatic mounting we have in Fedora 
that's not going to work.

As we want to provide as much protection as possible for as many users as 
possible it seems to me that for a typical targeted-policy system we would 
want to run daemons in their own name-space while leaving users in the system 
name-space.  It would not be difficult to modify runuser such that it could 
check for a domain_auto_trans() operation on launching a daemon (assuming 
that the runuser command in question runs the daemon directly instead of 
running a startup script) and then by default create a separate name space 
for every daemon that is confined in the targeted policy (which is probably a 
good list of daemons that may potentially become compromised and be used to 
attack users).

Having such separate name-spaces for daemons that run as non-root allows 
protecting users from attack while avoiding the usability issues of 
namespaces for each user.  This is a good match the design philosophy of the 
targeted policy.

For daemons such as xfs, we could have runuser set up a bind mount of the 
sub-directory of the /tmp directory that is used.  So /tmp/.font-unix could 
be bind mounted into the name-space of the xfs daemon.  Incidentally at the 
moment xfs is not started by runuser, so with my rough design outlined above 
it would not get a separate name-space.

-- 
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: pam_namespace

[Thomas Bleher]

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

[CC'ing Al Viro because he surely knows this...]

* Russell Coker <russell@coker.com.au> [2006-05-08 05:23]:
> On Sunday 07 May 2006 19:28, Russell Coker <russell@coker.com.au> wrote:
> > Of course there's nothing stopping us from modifying a program such as
> > runuser or run_init to set up a namespace for a daemon.  In fact we should
> > probably make the default behavior of run_init and runuser be the creation
> > of a namespace.  It would be easy to create a config file for runuser that
> > allows excluding daemons on the basis of executable name, UID, or other
> > factors.
> 
> One problem we have with separate name spaces is that when the administrator 
> mounts a file system the users won't see it.

I thought shared subtrees were invented to solve this problem?
I've read the documentation but never actually played with it, so I'd be
interested to hear if it doesn't work.

Thomas

> When the mount point has 
> the "user" option in /etc/fstab that won't be such a problem, but for the 
> more common cases of autofs and the automatic mounting we have in Fedora 
> that's not going to work.
> 
> As we want to provide as much protection as possible for as many users as 
> possible it seems to me that for a typical targeted-policy system we would 
> want to run daemons in their own name-space while leaving users in the system 
> name-space.  It would not be difficult to modify runuser such that it could 
> check for a domain_auto_trans() operation on launching a daemon (assuming 
> that the runuser command in question runs the daemon directly instead of 
> running a startup script) and then by default create a separate name space 
> for every daemon that is confined in the targeted policy (which is probably a 
> good list of daemons that may potentially become compromised and be used to 
> attack users).
> 
> Having such separate name-spaces for daemons that run as non-root allows 
> protecting users from attack while avoiding the usability issues of 
> namespaces for each user.  This is a good match the design philosophy of the 
> targeted policy.
> 
> For daemons such as xfs, we could have runuser set up a bind mount of the 
> sub-directory of the /tmp directory that is used.  So /tmp/.font-unix could 
> be bind mounted into the name-space of the xfs daemon.  Incidentally at the 
> moment xfs is not started by runuser, so with my rough design outlined above 
> it would not get a separate name-space.

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

Re: pam_namespace

[Stephen Smalley]

On Tue, 2006-05-09 at 00:39 +0200, Thomas Bleher wrote:
> [CC'ing Al Viro because he surely knows this...]
> 
> * Russell Coker <russell@coker.com.au> [2006-05-08 05:23]:
> > One problem we have with separate name spaces is that when the administrator 
> > mounts a file system the users won't see it.
> 
> I thought shared subtrees were invented to solve this problem?
> I've read the documentation but never actually played with it, so I'd be
> interested to hear if it doesn't work.

Yes, they should address that particular problem.  Patch for mount(8)
program to support setting up shared subtrees was just posted to
redhat-lspp list yesterday.

-- 
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: pam_namespace

[Janak Desai]

Thomas Bleher wrote:

>[CC'ing Al Viro because he surely knows this...]
>
>* Russell Coker <russell@coker.com.au> [2006-05-08 05:23]:
>  
>
>>On Sunday 07 May 2006 19:28, Russell Coker <russell@coker.com.au> wrote:
>>    
>>
>>>Of course there's nothing stopping us from modifying a program such as
>>>runuser or run_init to set up a namespace for a daemon.  In fact we should
>>>probably make the default behavior of run_init and runuser be the creation
>>>of a namespace.  It would be easy to create a config file for runuser that
>>>allows excluding daemons on the basis of executable name, UID, or other
>>>factors.
>>>      
>>>
>>One problem we have with separate name spaces is that when the administrator 
>>mounts a file system the users won't see it.
>>    
>>
>
>I thought shared subtrees were invented to solve this problem?
>I've read the documentation but never actually played with it, so I'd be
>interested to hear if it doesn't work.
>
>Thomas
>  
>
Yes, shared tree will solve this problem. Ram Pai has been trying to 
upstream the
user level support for this feature (kernel portion is already upstream 
since 2.6.15)
but the maintainer hasn't been very responsive. I forwarded his patch to 
redhat-lspp
on the suggestion of Steve Grubb. We are planning on including it in our 
lspp
builds so folks can play with it. In the meantime, we will continue to 
push the
upstream maintainer of util-linux for including this patch to the mount 
command.

-Janak

>  
>
>>When the mount point has 
>>the "user" option in /etc/fstab that won't be such a problem, but for the 
>>more common cases of autofs and the automatic mounting we have in Fedora 
>>that's not going to work.
>>
>>As we want to provide as much protection as possible for as many users as 
>>possible it seems to me that for a typical targeted-policy system we would 
>>want to run daemons in their own name-space while leaving users in the system 
>>name-space.  It would not be difficult to modify runuser such that it could 
>>check for a domain_auto_trans() operation on launching a daemon (assuming 
>>that the runuser command in question runs the daemon directly instead of 
>>running a startup script) and then by default create a separate name space 
>>for every daemon that is confined in the targeted policy (which is probably a 
>>good list of daemons that may potentially become compromised and be used to 
>>attack users).
>>
>>Having such separate name-spaces for daemons that run as non-root allows 
>>protecting users from attack while avoiding the usability issues of 
>>namespaces for each user.  This is a good match the design philosophy of the 
>>targeted policy.
>>
>>For daemons such as xfs, we could have runuser set up a bind mount of the 
>>sub-directory of the /tmp directory that is used.  So /tmp/.font-unix could 
>>be bind mounted into the name-space of the xfs daemon.  Incidentally at the 
>>moment xfs is not started by runuser, so with my rough design outlined above 
>>it would not get a separate name-space
>>
>.
>  
>


--
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: pam_namespace

[Rogelio Serrano]

separate namespaces is somewhat similar to selinux/dte and clashes
with it. i dont think we can mix selinux with separate namespaces as
it is right now.

On 5/5/06, Russell Coker <russell@coker.com.au> wrote:
> I was just playing with pam_namespace.  It seems to me that the current setup
> of having tmp/tmp.inst-$USER- does not provide adequate protection.  A
> process that is hostile to the user and which runs in the system name space
> (EG any cracked daemon) can access the user's instance of /tmp.
>
> If we had tmp/tmp.inst-$USER-/tmp (or something similar) and
> gave /tmp/tmp.inst-$USER- permission mode 000 (and something equivalent in
> terms of SE Linux access) then processes in the global name space would not
> be able to try anything.
>
>
> PS  I am posting here because I am no longer subscribed to the LSPP list.
>
> --
> 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.
>


-- 
www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers


--
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: pam_namespace

[Stephen Smalley]

On Thu, 2006-05-11 at 21:45 +0800, Rogelio Serrano wrote:
> separate namespaces is somewhat similar to selinux/dte and clashes
> with it. i dont think we can mix selinux with separate namespaces as
> it is right now.

I think there is a misunderstanding - Linux namespaces do not
clash/conflict with SELinux at all, and pam_namespace is a mechanism for
using Linux namespaces and bind mounts to provide similar functionality
to multi-level directories in SELinux.

-- 
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: pam_namespace

[Rogelio Serrano]

On 5/11/06, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2006-05-11 at 21:45 +0800, Rogelio Serrano wrote:
> > separate namespaces is somewhat similar to selinux/dte and clashes
> > with it. i dont think we can mix selinux with separate namespaces as
> > it is right now.
>
> I think there is a misunderstanding - Linux namespaces do not
> clash/conflict with SELinux at all, and pam_namespace is a mechanism for
> using Linux namespaces and bind mounts to provide similar functionality
> to multi-level directories in SELinux.
>

Well it would not unless you consider namespace as an analog of a
coarse grained "domain" in dte. In a namespace experiment a while ago
the users were isolated from each other using namespaces but they had
no way of "transitioning" to other namespaces.

> --
> Stephen Smalley
> National Security Agency
>
>


-- 
www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers


--
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: pam_namespace

[Russell Coker]

On Thursday 11 May 2006 23:45, "Rogelio Serrano" <rogelio.serrano@gmail.com> 
wrote:
> separate namespaces is somewhat similar to selinux/dte and clashes
> with it. i dont think we can mix selinux with separate namespaces as
> it is right now.

Separate namespaces have no similarity or overlap in functionality with SE 
Linux.

All that separate namespaces offer is a different set of mounted file systems.  
No protection against IPC based attacks, no control over what is actually 
done to files in the filesystems in questions, etc.

SE Linux does not support hiding of file names.  If the name of a file is 
considered to be secret data (IE the output of "ls" is considered to be 
secret) then copying that file to /tmp (which may be done without the 
knowledge of the user by an editor creating a temporary buffer file with a 
derived name) would break the confidentiality controls we want to have on the 
system.

To solve this we have separate namespaces for processes that need to have 
isolated copies of /tmp.  The idea is that if user A creates the 
file /tmp/X.txt where X is secret then user B will see a different version 
of /tmp where there is no X.txt file.

Another problem is the issue of DOS attacks.  If a program uses a fixed 
file/directory name then a hostile process that first creates an object with 
that name (either with restrictive permissions or creating a directory where 
a file is expected) can prevent the process from running.  SE Linux can 
prevent programs from following hostile sym-links, writing to files created 
by hostile users, and most race-condition attacks on non-administrative 
processes, but it can't prevent the same operations from becoming DOS 
attacks - in fact many attacks that would violate system integrity or data 
confidentiality on non-SE systems become DOS attacks on SE systems.

Fedora Rawhide has just got PAM version 0.99.4.0-1 in which namespace works 
(the previous version didn't).  Please try configuring a SE Linux system with 
pam_namespace, you'll find that it works and provides some benefits that SE 
Linux alone can not provide.

-- 
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: pam_namespace

[Rogelio Serrano]

On 5/12/06, Russell Coker <russell@coker.com.au> wrote:
> On Thursday 11 May 2006 23:45, "Rogelio Serrano" <rogelio.serrano@gmail.com>
> wrote:
> > separate namespaces is somewhat similar to selinux/dte and clashes
> > with it. i dont think we can mix selinux with separate namespaces as
> > it is right now.
>
> Separate namespaces have no similarity or overlap in functionality with SE
> Linux.
>
> All that separate namespaces offer is a different set of mounted file systems.
> No protection against IPC based attacks, no control over what is actually
> done to files in the filesystems in questions, etc.
>
> SE Linux does not support hiding of file names.  If the name of a file is
> considered to be secret data (IE the output of "ls" is considered to be
> secret) then copying that file to /tmp (which may be done without the
> knowledge of the user by an editor creating a temporary buffer file with a
> derived name) would break the confidentiality controls we want to have on the
> system.
>
> To solve this we have separate namespaces for processes that need to have
> isolated copies of /tmp.  The idea is that if user A creates the
> file /tmp/X.txt where X is secret then user B will see a different version
> of /tmp where there is no X.txt file.
>
> Another problem is the issue of DOS attacks.  If a program uses a fixed
> file/directory name then a hostile process that first creates an object with
> that name (either with restrictive permissions or creating a directory where
> a file is expected) can prevent the process from running.  SE Linux can
> prevent programs from following hostile sym-links, writing to files created
> by hostile users, and most race-condition attacks on non-administrative
> processes, but it can't prevent the same operations from becoming DOS
> attacks - in fact many attacks that would violate system integrity or data
> confidentiality on non-SE systems become DOS attacks on SE systems.
>
> Fedora Rawhide has just got PAM version 0.99.4.0-1 in which namespace works
> (the previous version didn't).  Please try configuring a SE Linux system with
> pam_namespace, you'll find that it works and provides some benefits that SE
> Linux alone can not provide.
>

Well i agree.

We can go beyond just customizing /tmp though. We can hide /sbin from
ordinary users and we can hide some of the files from /etc and we can
actually have each user have their own passwd file. we can hide almost
all files from /dev. We can actually hide any file or directory we
want. I played with a custom init a while ago that did all this. I did
not think linux people want to step outside unix though so i killed
the project.

-- 
www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers


--
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: pam_namespace

[Russell Coker]

On Friday 12 May 2006 14:00, "Rogelio Serrano" <rogelio.serrano@gmail.com> 
wrote:
> We can go beyond just customizing /tmp though. We can hide /sbin from
> ordinary users and we can hide some of the files from /etc and we can
> actually have each user have their own passwd file. we can hide almost
> all files from /dev. We can actually hide any file or directory we
> want. I played with a custom init a while ago that did all this. I did
> not think linux people want to step outside unix though so i killed
> the project.

The general design idea in SE Linux is that files in /sbin will come from 
packages that are part of the distribution, therefore hiding /sbin from users 
will not provide a benefit.  Denying execute access to sbin_t could be 
implemented, however in Linux things aren't organized well enough to allow 
such a restriction without significant obstruction to normal system 
operation.  Reorganizing the contents of /bin and /sbin is beyond the scope 
of the project.

Hiding the existence of files in /etc is of minimal benefit, the file names 
are usually predictable and every daemon that has complex configuration has a 
sub-directory of /etc to which regular users are not granted search access.

You are correct that Linux people don't want to go too far from the Unix 
traditions.  We have enough problems with unreasoned criticism of SE Linux 
already without adding to it.

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