On Monday, July 22, 2013, Reindl Harald <h.rei...@thelounge.net> wrote: > > Am 22.07.2013 18:37, schrieb Miloslav Trmač: >> On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange <berra...@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.rei...@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
Here is your problem ... How about running it in enforcing mode? I mean you care ab out security and disable security features at the same time. If there are selinux bugs file and/or fix them.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
