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

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

[pjmlp]

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.

[segmondy]

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.