Re: [PATCH] remove sys_security

[Russell Coker <russell@coker.com.au>]

On Fri, 18 Oct 2002 09:28, Alexander Viro wrote:
> As for "highly secure"...  Could we please
> see some proof?  Clearly stated properties with code audit to verify them
> would be nice.
>
> I'm yet to see a single shred of evidence that so-called security
> improvements actually do improve security (as opposed to feeling of
> security - quite a different animal).  And in this case burden of proof is
> clearly on your side.

Some people at IBM are working on analysis of SE Linux policy to prove that it 
does what it is supposed to do.  The benefits of MAC as a general concept are 
well documented.


For real-world examples of the benefits of SE Linux:

With the recent terrible PAM bug, in a default Debian setup you could login as 
"man" and then replace the man program (owned by user "man") with a trojan 
(and wait for root to read a man page).  With a default SE Linux setup the 
man binary is in bin_t and the default SE Linux role (which is applied to the 
"man" account) is not permitted to write to it.  Of course setting the file 
to be immutable or configuring the man-db package for the man program to not 
be SUID would get the same result, but that's not generally done.  Also it 
should be noted that there's an infinite number of potential attacks, 
removing access that's not needed is the best way to address them.

The recent Apache SSL exploit gave attackers the full access rights of the 
Apache process, and the recent scoreboard Apache bug allowed someone who can 
write to Apache data the ability to send a signal to any process.  Taking 
advantage of both bugs a remote attacker could send a signal to any process 
(including root).  With SE Linux Apache only gets control over it's own 
cgi-bin scripts and it's own processes.  It can kill itself and some of it's 
children, but that's all.  It can't interfere with other daemons or user 
processes.

After the recent ssh bug the default SE Linux policy was changed to not allow 
sshd_t to transition directly to priviledged domains.  So the next time sshd 
is broken the worst you can do with a default SE Linux machine is to login as 
user_r (which allows you to kill any user processes and write to any user 
files but not kill daemons, change system configuration, or read 
/etc/shadow).  You could configure a SE Linux system to have ssh log you in 
with a role that is only allowed to transition to the real role (which 
requires password authentication) not actually do anything useful.  So then 
if sshd is cracked the attacker can't directly do anything useful.  Of course 
this still wouldn't solve the problem of sshd being trojaned...

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