Am 22.07.2013 18:37, schrieb Miloslav Trmač:
On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berrange@redhat.com wrote:
On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote:
On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.reindl@thelounge.net wrote:
has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase!
ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr
I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools.
Namespaces really aren't duplicating SELinux policy, they are working in a complementary fashion. There is clear value in having multiple layers of security defence because things do fail for any number of reasons.
The returns to additional layers enforcing the same policy are rapidly diminishing, though. We already have DAC permissions, and MAC policy, and a third layer is being proposed. Why not have four or ten? We have to stop somewhere.
depends on the cost and impact
the cost for two lines in the systemd-unit is low there is no measurable performance impact there is no such impact as mount /usr read-only so cronjobs and whatever are working as before while network-service is more protected
it steps in where SElinux is disabled or in permissive mode
(The network services shouldn't be running as root in the first place.)
No argument there, but even if something is running as non-root there is the potential for privilege escalation through security flaws in some thing that they use. In such a scenario having a separate filesystem namespace which has made certain areas read-only may well stop the exploit.
If I am able to escalate to root privileges, I can just switch back to the system namespace using setns(2), so the protection doesn't actually exist.
in theory yes
practically a exploit is not that easy like fire a bundle of commands as root like a script
So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is)
a httpd running with SElinux disabled or in permissive mode with the 4 lines below even after escalate to root privileges will hardly have a chance to overwrite /usr/sbin/sshd as example
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID NoNewPrivileges=yes ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr