What does SELinux do to contain the the bash exploit? | Hacker News Reader

What does SELinux do to contain the the bash exploit?

danwalsh.livejournal.com

39 pointsnsaje12 comments

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.

This is what sometimes gets missed in the UNIX vs other OSes security discussions.

If no MAC system is in place and a user facing process gets owned, it will get free pass to $HOME and lots of other user accessible areas, where lots of juicy information are already available.

Additionally, downloading and running additionally scripts via the exploit path is quite easy. Who needs root afterwards....

On the systems UNIX/Windows I use all of them have MAC enforced, even if it might be a pain to configure sometimes.

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

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.

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

Does it? It let's someone dump a script in /tmp that can then be executed to have a shell into your system. With a shell, they can find other vector of attack, and escalate the privilege to root. You have to understand that even tho bash is the cause, a lot of other apps are now "vulnerable" including root enabled apps.

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

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.

  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?

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

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

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

"SELinux does not block the exploit"

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

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

Reply on news.ycombinator.com