Am 22.07.2013 18:37, schrieb Miloslav Trmač: > On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
