[systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories

[Lennart Poettering]

On Tue, 21.10.14 14:03, Christian Seiler (christian at iwakd.de) wrote:

> Am 2014-10-20 17:05, schrieb Lennart Poettering:
> >I am sorry, but this is nothing we want to support. Monopolizing the
> >OS in /usr is what makes ProtectSystem= work. If you split things up
> >into many dirs then you will simply not get the same level of
> >protection. We will not try to list every possible dirs that the OS
> >might be split up to in systemd.
> 
> Why wouldn't you get the same level of protection, even if it is split
> up? I mean, we are talking about /bin, /sbin, /lib and possibly some
> pseudo-multiarch-variants for /lib - it's not like there are any other
> directories, the /usr-merge is about moving /bin, /sbin and /lib to
> /usr/$dir. I don't see that split-/usr with these additional directories
> protected would be inherently more insecure.

Well, for starters the bin/sbin merge is orthogonal to the /usr
merge. arch did both for example, fedora only one, debian none. gentoo
did a really weird usr merge where they didn't merge but just moved
all things breaking things all over the place. Suse also did a weird
usr merge. Moreover the lib dirs are different for all archs. 

I really don't want to be in the business of guessing and
distuingishing the many different ways how distros applied
that. Instead we do the minimally useful stuff that works in full on
the usr-merged distros, but only provides limited protection on the
ones which did not merge this. But that's OK, this is just an
additional line of protection. 

> >Note that your patch is likely to break systems that have the dirs you
> >list as symlinks (which all systems that have /usr merged have).
> 
> But on those systems, systemd is going to be compiled without
> HAVE_SPLIT_USR, right?

No, not necessarily. see above.

> >We are fine with supporting HAVE_SPLIT_USR work to the level where
> >things generally work, but given that ProtectSystem= is only an extra
> >layer of protection where nothing breaks if it doesn't fully protect
> >systems that haven't done the usr-merge I think applying this patch
> >is not useful.
> 
> But computer security often works as defence in depth. Of course
> ProtectSystem is an additional security measure, and protecting /usr
> alone is obviously still better than protecting nothing at all, but if
> it is not much work to provide a slightly higher level of protection -
> why not?

because we want to keep our code minimal, and nice, and simple, and
easily explainable. 

Mounting just /usr read-only is something that is minimal, nice,
simple and explainable. It is everywhere the same, and gets a good
message across regarding that upstream devs really should monopolize
their vendor code in /usr, and so on. 

> That all said, to add something constructive to this: If I put my
> administrator hat on, I think I can come up with something that might
> make all parties happy:
> 
> To start with, ProtectSystem does not include /opt. Now I don't suggest
> adding that to the list: distributions by default do not install
> anything there, therefore a vanilla installation of a reasonable
> distribution will not be affected by this. And there might be software
> which requires system services to be able to write to /opt (for example,
> think of some proprietary software that creates logfiles underneath /opt
> that you want to rotate, but want the logrotate-job to use
> ProtectSystem, since it's run as root), so it's probably a good default
> not to include it.

ProtectedSystem= is really supposed to be something that has very well
defined behaviour and only does something on the dirs we
*sufficiently* know that nothing breaks. We explicitly make no
assumptions on /opt because nobody knows right now what it is supposed
to be... Same for /usr, /bin, /sbin, and the other stuff Martin#s
patch added: we cannot make assumptions about it, it might be (and is
in real life) set up in different ways, and we don't want to be in
that game. However, what we do know is that /usr is something we can
mount read-only on all systems.

> Therefore, may I suggest to make this configurable in
> /etc/systemd/system.conf:
> 
>  - have an option such as ProtectSystemDirectories= that is a list
>    like the other *Directories= options for units
> 
>  - set the default to /usr, -/boot (like currently)
> 
>  - distributions can customize that to fit their needs (depending on
>    /lib{32,64}, split- or no-split-/usr, etc.)
> 
>  - administrators may themselves add /opt and other directories if
>    needed
> 
>  - still hard-code /etc for ProtectSystem=full
> 
> If you're willing to accept a patch for this, I'd provide one.

I really disagree that this would be a good idea. We should give clear
guidelines how things should be set up here to take full benefit of
the functionality. Because this is about an agreement between the OS
people and the upstream developers of packages to run on the OS. We
want to make sure they can make the assumptions everywhere, which are
not configurable and behave differently everywhere. For example, I
really want that let's say apache sets ProtectSystem= and can be sure
it will just not break things on our OSes. And because of that its
impact should be only on the safe subset, and it should be the same on
all installations, and not be subject to configuration.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat