Re: [PATCH] remove sys_security

Russell Coker
2002-10-18T10:09:07Z

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