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