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

[Reindl Harald]

Am 22.07.2013 18:37, schrieb 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130722/ed5371f2/attachment.sig>