

What does SELinux do to contain the the bash exploit? - nsaje
http://danwalsh.livejournal.com/71122.html

======
616c
I think a lot of people will disparage and mock Dan (FYI he is a core SELinux
developer for Fedora if you do not know), but I think he outlines that it does
prevent the medium risk stuff which I think no base Linux system (without MAC
systems (SELinux, RBAC, AppArmor,etc.), just DAC of Unix file permissions)
would let pass easily. All the logs, all the non-root data which hackers would
use to build up to move forward in their operation.

I guess CGI scripting is convenient and necessarry for most of us (just like
bash itself), and SELinux did not prevent Heartbleed either. But that does not
mean I will make coloring jokes about its inefficacy.

~~~
nailer
Personally it always felt off that the SELinux approach to something like,
say, binding to low ports, was to allow something to run as root to bind to
that low port, then control access to that role so it couldn't do other root
things. See
[http://wiki.gentoo.org/wiki/SELinux/Tutorials/Managing_netwo...](http://wiki.gentoo.org/wiki/SELinux/Tutorials/Managing_network_port_labels)

I'd rather a simpler, file and user based approach. I know that's not role
based, but since the `myapp` user matches 1:1 with the role of my app, it
seems reasonable:

    
    
        chown /proc/ports/tcp/80 myapp
    

Yes, that file doesn't exist yet, it's a proposal. Yes this breaks the `all-
or-nothing` approach to root special privileges. But `all-or-nothing` is
broken, and SELinux just seems to be working around it.

Off-topic: 'avc denied' is still one of the worst error messages in Unix.
Nobody cares/knows that the access vector cache is part of SELinux. Making it
'SELinux denies' would have made people a lot happier with the system and lost
Google a small amount of search engine revenue.

~~~
ptx
The FreeBSD MAC framework[0] allows you to do exactly this, and I agree that
it makes a lot more sense.

So to run a web server as the user myapp (with UID 1234 in this example), you
simply load the mac_portacl kernel module and then:

    
    
      sysctl security.mac.portacl.rules=uid:1234:tcp:80,uid:1234:tcp:443
    

In Linux it seems I can only assign the right to bind to _all_ privileged
ports (with cap_net_bind_service), but once every user has that right, that's
essentially the same thing as not having privileged ports at all, and we're
back to where we started. O_o

[0]
[http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ma...](http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html)

------
willvarfar
I'm a big fan of SELinux, and for many shellshock attacks it will limit
exposure, but Dan should know better than invite people to ask him how SELinux
helps mitigate a dchp shellshock attack...

------
mrmondo
Big fan of SELinux here - it's really saved my ass a few times and the best
thing about it is that these days it's so damn easy to configure that you're
mad not to use it.

------
devicenull

      Lets look at what it can read.
      ... It can read apache static content, like web page data.
      Well what can't it read?
      user_home_t - This is where I keep my credit card data
      *db_t - No database data.
    

So, it can't read database data directly, but presumably your website can
already connect to the database. Which means it can read out your database
credentials, and just connect to the database?

------
treed
There are lots of stories of SELinux saves out there now. This is one I saw
just recently:

[https://www.reddit.com/r/linux/comments/1xdokz/selinux_saved...](https://www.reddit.com/r/linux/comments/1xdokz/selinux_saved_our_asses_xpost_rselinux/)

I myself have had several SELinux saves. It's definitely proven itself
valuable as an additional security control.

------
qwerta
It is like asking if it would catch SQL injections. Just sanitize your inputs
!

------
yarrel
"SELinux does not block the exploit"

Of course not. The exploit doesn't come in coloring book form.

~~~
walterbell
> "SELinux does not block the exploit _but it would prevent escalation of
> confined domains._ "

Not as easy to color the unabbreviated quote, since understanding the omitted
text would require reading the article.

A production server would have strong confinement of domains, tailored to the
production workload.

