Shared hosting providers stay in business with the principle that somehow they provide a relatively secure platform for their users, so a few of them do harden their systems enough to prevent most priv escalation. But one buffer overflow and a lack of mandatory access control later and you've got gold. Priv escalation exploits have been so common in Linux in the past decade that I would consider local access the same as root access [without MAC like grsec or selinux enabled].
Well apparmor is like the baby cousin to selinux, or the big brother to the traditional unix DAC. Selinux is more robust but also more complex. Grsec is an attempt at both a MAC and various exploit-prevention techniques. In that sense, grsec will be more effective at preventing "traditional" exploit techniques.
But modern software development is so bad, even after using high-level languages and abstractions, much of the webapp and backend development is rife with security holes. You don't need to use things like buffer overflows anymore to simply extract data or take over accounts. Servers are so easily accessible and botnets are so widespread that owning a server isn't really the point anymore; once you have all their data, who needs root?
You don't need to bother with old-school stuff like grsec, iptables, IDS, chrooted applications or any stack-protection technologies.
Get a WAF, audit your web-app source-code and use a pen-test tool regularly instead.
SQL-injections walk right in, through the front door. They stuff their pockets full of data and then leave the same way they came, unnoticed most of the time.
Ya, I guess I'm thinking of it more from a hosting/cloud perspective, in that even though one user/tenant's site has been hacked, it would be nice not to have to wipe the machine for all other users.
I am definitely going to reinvestigate putting every user's data in their own container. When I last looked the options were FreeBSD Jails (not appealing) or Solaris Zones (interesting but a whole new OS); now with LXC maybe that can assist? There must be a way to harden things further...
Docker is not designed to isolate the root user from the rest of your system, and containers/capabilities are not MAC-based security. Docker strips 16 capabilities when it runs a container, leaving 23 additional capabilities to be abused by root, and whatever other vulnerabilities are left that capabilities don't cover. To prevent this you need guest isolation via virtualization.
Comments
Shared hosting providers stay in business with the principle that somehow they provide a relatively secure platform for their users, so a few of them do harden their systems enough to prevent most priv escalation. But one buffer overflow and a lack of mandatory access control later and you've got gold. Priv escalation exploits have been so common in Linux in the past decade that I would consider local access the same as root access [without MAC like grsec or selinux enabled].
Out of interest, have you any opinion on selinux vs grsec vs apparmor, in terms of which is better in certain scenarios and/or overall?
Well apparmor is like the baby cousin to selinux, or the big brother to the traditional unix DAC. Selinux is more robust but also more complex. Grsec is an attempt at both a MAC and various exploit-prevention techniques. In that sense, grsec will be more effective at preventing "traditional" exploit techniques.
But modern software development is so bad, even after using high-level languages and abstractions, much of the webapp and backend development is rife with security holes. You don't need to use things like buffer overflows anymore to simply extract data or take over accounts. Servers are so easily accessible and botnets are so widespread that owning a server isn't really the point anymore; once you have all their data, who needs root?
Agree!
You don't need to bother with old-school stuff like grsec, iptables, IDS, chrooted applications or any stack-protection technologies.
Get a WAF, audit your web-app source-code and use a pen-test tool regularly instead.
SQL-injections walk right in, through the front door. They stuff their pockets full of data and then leave the same way they came, unnoticed most of the time.
Ya, I guess I'm thinking of it more from a hosting/cloud perspective, in that even though one user/tenant's site has been hacked, it would be nice not to have to wipe the machine for all other users.
I am definitely going to reinvestigate putting every user's data in their own container. When I last looked the options were FreeBSD Jails (not appealing) or Solaris Zones (interesting but a whole new OS); now with LXC maybe that can assist? There must be a way to harden things further...
FreeBSD's jails have had a lot of work done on them over the last couple of versions. Now that 10.0 is out, could be worth another look.
Why not Docker? (lxc)
Docker is not designed to isolate the root user from the rest of your system, and containers/capabilities are not MAC-based security. Docker strips 16 capabilities when it runs a container, leaving 23 additional capabilities to be abused by root, and whatever other vulnerabilities are left that capabilities don't cover. To prevent this you need guest isolation via virtualization.
https://wiki.ubuntu.com/LxcSecurity http://www.infoq.com/news/2013/09/docker-container-security http://s3hh.wordpress.com/2013/07/19/creating-and-using-cont...