some policy feedback

some policy feedback

[Tom]

I've just come back from a 3-day hacker convention where I brought an
SELinux play system with me, to let the likes of teso, THC, LSD, etc.
have a go at it.

There were a number of interesting points that I'd like to feed to the
list:

1) su problem
The default policy seems to have a hole that has potentially serious
consequences. Root can run su and change to any user account authorized
for root's current role. That way, root can set up traps for the sysadm
when he logs into his own account, e.g. by trojaning the .bashrc file
and having the sysadm execute a fake newrole (which calls the real one
in the background, possibly a wrapper), capturing his password.

Someone (whose name I unfortunately forgot to get) did exploit this
problem and modified my .bashrc in a non-malicious way. I discussed the
issue with him and we both felt that it would probably be possible to
exploit it.


2) various kernel-level issues
code from LSD has brought up several interesting points that I could
not really answer due to lack of in-depth knowledge, especially in the
kernel operations.

One question was the usual LKM issue. Would it be possible to overload
calls of the SELinux patch, in turn disabling it? Or does LSM and/or SE
have any kind of "self-preservation" behaviour?

Another issue was whether it would be possible to trojan a running
binary. Assuming that a daemon has an exploitable buffer overflow, it
seems to be possible to change the daemon itself, at runtime. No exec
would be made, and as I understand it, no system calls that could
trigger SE. The trojaned daemon would continue to run, with whatever
changes were made. (obviously, patching binary code while its running
isn't for the faint of heart, but I've seen several methods for doing
so in action, and it certainly is possible.)


that brings me to

3) user macros
I've been digging through the user macros, because I wanted to set up
an additional unpriviledge (guest) user. Is there any documentation on
why the macros were laid out the way they were?


Some more details when I've caught up on some sleep.

-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: some policy feedback

[Russell Coker]

On Mon, 2 Jun 2003 06:23, Tom wrote:
> I've just come back from a 3-day hacker convention where I brought an
> SELinux play system with me, to let the likes of teso, THC, LSD, etc.
> have a go at it.
>
> 1) su problem
> The default policy seems to have a hole that has potentially serious
> consequences. Root can run su and change to any user account authorized
> for root's current role. That way, root can set up traps for the sysadm
> when he logs into his own account, e.g. by trojaning the .bashrc file
> and having the sysadm execute a fake newrole (which calls the real one
> in the background, possibly a wrapper), capturing his password.

In /etc/pam.d/su:
# This allows root to su without passwords (normal operation)
#auth       sufficient pam_rootok.so

SE Linux does not aim to protect users against standard Unix issues.  The idea 
is that you either have standard Unix permissions set up for it or you have 
different roles.

If you setup a different role for the users with non-0 UIDs and label their 
home directories correctly then root can't do anything even if they su to the 
account.

> Someone (whose name I unfortunately forgot to get) did exploit this
> problem and modified my .bashrc in a non-malicious way. I discussed the
> issue with him and we both felt that it would probably be possible to
> exploit it.

Peter Palfreder has just demonstrated this on Method's SE-Gentoo system (see 
the IRC channel).

> One question was the usual LKM issue. Would it be possible to overload
> calls of the SELinux patch, in turn disabling it? Or does LSM and/or SE
> have any kind of "self-preservation" behaviour?

You could entirely prevent module loading and access to /dev/mem and 
/dev/kmem.  In a default configuration only X can access /dev/mem and only 
modutils can load modules into the kernel.  If you change it so that nothing 
can write to the modules files that get loaded or the modprobe/insmod/rmmod 
binaries and don't install the policy for the X server then it should be 
reasonably safe.

> 3) user macros
> I've been digging through the user macros, because I wanted to set up
> an additional unpriviledge (guest) user. Is there any documentation on
> why the macros were laid out the way they were?

They have just evolved like that.  They need to be sorted out more, 
documented, etc.

-- 
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: some policy feedback

[Stephen Smalley]

On Sun, 2003-06-01 at 16:23, Tom wrote:
> 1) su problem
> The default policy seems to have a hole that has potentially serious
> consequences. Root can run su and change to any user account authorized
> for root's current role. That way, root can set up traps for the sysadm
> when he logs into his own account, e.g. by trojaning the .bashrc file
> and having the sysadm execute a fake newrole (which calls the real one
> in the background, possibly a wrapper), capturing his password

Options:
1) Drop the rootok line from the PAM configuration, as suggested by
Russell.  This allows user_t to still use su, but always requires a
password even when run by root.
2) Move the su_domain line from user_macros.te to admin_macros.te, i.e.
only allow sysadm_t and other admin domains to run su.
3) Use different base roles and home directory types to strictly
partition these users, i.e. no shared use of user_t and user_home_*_t by
roles other than user_r or add a new staff_r/staff_t role/domain for the
initial login of admins.
4) Polyinstantiated home directories with transparent redirection (not
yet supported).

> 2) various kernel-level issues
> code from LSD has brought up several interesting points that I could
> not really answer due to lack of in-depth knowledge, especially in the
> kernel operations.
> 
> One question was the usual LKM issue. Would it be possible to overload
> calls of the SELinux patch, in turn disabling it? Or does LSM and/or SE
> have any kind of "self-preservation" behaviour?

For clarity, SELinux is always built-in, LSM isn't based on system call
interposition, and your LSM can mediate access to the kernel module
syscalls as well as to /dev memory nodes.  Naturally, if you can gain
access to a domain that can insert modules or you can trick such a
domain into inserting a trojaned module, then the module is free to do
what it likes; you can't protect against other code in the kernel.

> Another issue was whether it would be possible to trojan a running
> binary. Assuming that a daemon has an exploitable buffer overflow, it
> seems to be possible to change the daemon itself, at runtime. No exec
> would be made, and as I understand it, no system calls that could
> trigger SE. The trojaned daemon would continue to run, with whatever
> changes were made. (obviously, patching binary code while its running
> isn't for the faint of heart, but I've seen several methods for doing
> so in action, and it certainly is possible.)

Yes, it would continue to run, but would be limited to whatever
permissions are granted to its domain.  There are techniques other than
kernel MAC for helping to counter that issue, but that isn't the focus
of SELinux.  You are naturally free to combine SELinux with other
security techniques to provide further security.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: some policy feedback

[Tom]

On Mon, Jun 02, 2003 at 10:37:21AM +1000, Russell Coker wrote:
> In /etc/pam.d/su:
> # This allows root to su without passwords (normal operation)
> #auth       sufficient pam_rootok.so
> 
> SE Linux does not aim to protect users against standard Unix issues.  The idea 
> is that you either have standard Unix permissions set up for it or you have 
> different roles.

Roger that. I wrote a workaround at the con using SELinux by
essentially prohibiting access to su for user_r.



> > Someone (whose name I unfortunately forgot to get) did exploit this
> > problem and modified my .bashrc in a non-malicious way. I discussed the
> > issue with him and we both felt that it would probably be possible to
> > exploit it.
> 
> Peter Palfreder has just demonstrated this on Method's SE-Gentoo system (see 
> the IRC channel).

Sorry, I'm drowning in work today. Could someone please post a 2-line
summary (like "oops, this is evil" or "not really serious") ?


> > One question was the usual LKM issue. Would it be possible to overload
> > calls of the SELinux patch, in turn disabling it? Or does LSM and/or SE
> > have any kind of "self-preservation" behaviour?
> 
> You could entirely prevent module loading and access to /dev/mem and 
> /dev/kmem.  In a default configuration only X can access /dev/mem and only 
> modutils can load modules into the kernel.  If you change it so that nothing 
> can write to the modules files that get loaded or the modprobe/insmod/rmmod 
> binaries and don't install the policy for the X server then it should be 
> reasonably safe.

In other words: Whoever can insmod modules can take over the system. So
if you want seperated sysadm accounts, you need to keep that in mind.


> > 3) user macros
> > I've been digging through the user macros, because I wanted to set up
> > an additional unpriviledge (guest) user. Is there any documentation on
> > why the macros were laid out the way they were?
> 
> They have just evolved like that.  They need to be sorted out more, 
> documented, etc.

Is anyone working on that? I would like to give that a try because I
would like to have a better role structure for my own systems.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: some policy feedback

[Russell Coker]

On Tue, 3 Jun 2003 02:24, Tom wrote:
> > > Someone (whose name I unfortunately forgot to get) did exploit this
> > > problem and modified my .bashrc in a non-malicious way. I discussed the
> > > issue with him and we both felt that it would probably be possible to
> > > exploit it.
> >
> > Peter Palfreder has just demonstrated this on Method's SE-Gentoo system
> > (see the IRC channel).
>
> Sorry, I'm drowning in work today. Could someone please post a 2-line
> summary (like "oops, this is evil" or "not really serious") ?

If you grant root access to untrusted users then yes it is serious.  Also 
regarding our recent discussions of ssh, if someone cracks sshd then they can 
get access to an account with low SE privs and then change the .login file 
etc to subvert newrole (Peter wrote a newrole program in shell script which 
sent the password off-site).

Creating a new type for the .login files etc is easy enough, I'm playing with 
this on my play machine.

> > > 3) user macros
> > > I've been digging through the user macros, because I wanted to set up
> > > an additional unpriviledge (guest) user. Is there any documentation on
> > > why the macros were laid out the way they were?
> >
> > They have just evolved like that.  They need to be sorted out more,
> > documented, etc.
>
> Is anyone working on that? I would like to give that a try because I
> would like to have a better role structure for my own systems.

Nothing serious is being done at this time.  In the last two years it seems 
that I'm the only person to work in this area, and all I have wanted to do 
was get multiple user roles working properly (which is 99% done).

Go for 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: some policy feedback

[Tom]

On Tue, Jun 03, 2003 at 10:22:03AM +1000, Russell Coker wrote:
[user macros]
> Nothing serious is being done at this time.  In the last two years it seems 
> that I'm the only person to work in this area, and all I have wanted to do 
> was get multiple user roles working properly (which is 99% done).
> 
> Go for it!

Going. Any input appreciated, otherwise I'll just keep the list in
touch about my progress.

-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

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