Proposal: ReadOnlyDirectories /etc and /usr for network-services

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange <berrange at 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 at 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.

>> (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.  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).
    Mirek