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

[Christian Seiler]

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.

> 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?

> Also note that it hardcodes x86_64 peculiarities in an
> arch-independent way, which looks pretty wrong too.

That is definitely a good point. Also note that /lib32 is not included
in the patch...

> 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?



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.

However, as an administrator, if I know what software is installed
underneath /opt, and that there is no need for services to write to it,
I might actually want to include it. Of course, I could add drop-ins 
for
all services that use ProtectSystem to also have
ReadOnlyDirectories=/InaccessibleDirectories=, but that would mean as 
an
administrator I have to track these services - and if an update 
suddenly
changes service files to use ProtectSystem= for increased protection,
I'd likely miss that and not be able to add these directives.

Additionally, not all custom installations follow the FHS and put
everything in /opt. I've seen computing clusters where software was
installed centrally and mounted per NFS to some other top-level
directory that is not /opt and /usr.

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.

Christian