On Monday, July 22, 2013, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>
> 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
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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
