Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On 21/10/14 20:25, Lennart Poettering wrote: Ah, well, at least they should make the lib64 thing arch dependent. Multiarch means that whichever architecture systemd happens to have been compiled for, /lib64 might exist. If it does, it's a system library directory. (Consider an i386 or armhf systemd on a mixed i386 + amd64 or armhf + arm64 system, for instance. On a developer's system, you might even have mixed i386 + amd64 + armhf + s390x or something.) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On Tue, 21.10.14 14:03, Christian Seiler (christ...@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
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On 21/10/14 13:03, Christian Seiler wrote: That is definitely a good point. Also note that /lib32 is not included in the patch... lib64 is part of the Linux/x86_64 platform ABI (the exact path /lib64/ld-linux-x86-64.so.2 is hard-coded into every Linux/x86_64 executable) so it cannot be considered legacy. Is there a Linux ABI where /lib32 has the same status? If not, then its priority is rather lower. Debian x86_64 (amd64) systems with bi-arch i386 binaries (ia32-libs) are the only instance of /lib32 that I can think of, and that setup is superseded by multiarch these days. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Am 21.10.2014 um 14:38 schrieb Simon McVittie: On 21/10/14 13:03, Christian Seiler wrote: That is definitely a good point. Also note that /lib32 is not included in the patch... lib64 is part of the Linux/x86_64 platform ABI (the exact path /lib64/ld-linux-x86-64.so.2 is hard-coded into every Linux/x86_64 executable) so it cannot be considered legacy. Is there a Linux ABI where /lib32 has the same status? If not, then its priority is rather lower it don't matter after UsrMove: lib64 - usr/lib64 so the protection of /usr works as expected if some disto invents other dirs - the same logic if some distro don't follow that structure - no protection they can do the following in their unit-files ProtectSystem is nothing more than a nice addition ReadOnlyDirectories works even on old systemd versions ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/lib64 ReadOnlyDirectories=/lib32 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Am 2014-10-21 14:28, schrieb Lennart Poettering: We explicitly make no assumptions on /opt because nobody knows right now what it is supposed to be... Sure, I wasn't disputing that point. 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. That's why I didn't suggest that you (as upstream) should be in that game, but that distributions and administrators should be able to do so themselves. Therefore, may I suggest to make this configurable in /etc/systemd/system.conf: [...] 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. Debian's systemd package currently includes a variant of Martin's patch that does include additional directories. So your point that ProtectSystem= does the same thing on every distro is already not true. Of course, if you make it configurable, people can shoot themselves in the foot. But you already have a ton of global options in system.conf that can break a lot of software if people do stupid stuff with it: - set a global CapabilityBoundingSet= that's very restrictive - either the system doesn't boot at all because some essential stuff is completely missing - or it boots but some services don't work because they rely on certain things - set SystemCallArchitectures=native when non-native software is installed - set DefaultEnvironment=LD_TRACE_LOADED_OBJECTS=1 or the such - set DefaultTimeoutStartSec=1 to break any unit that takes longer than 1 second to start but doesn't set an own timeout because it assumes the default timeout is sane - DefaultLimitCPU=1 - ... Also, to go to your apache example: it's not clear that ProtectSystem= just making /usr readonly doesn't break things: I have seen DocumentRoots beneath /usr in the wild (/usr/local/www or the such), with people running dynamic webapps that had to write into that tree. If you then upgrade from a package version that did not include ProtectSystem= (perhaps because it only included a SysV init script) to a package version that does include ProtectSystem=, things will break. I actually agree with your sentiment of having an agreement between upstream developers and the core OS - I just think I would like to interpret the matter a little differently: To me, ProtectSystem= is supposed to be a protection of all the files a) installed on a system (not created by the user) and b) not subject to modification by typical services. (i.e. not a cache / status file / ...) For distros with /usr-move, this falls back to /usr and /boot (and /etc if =full). For other distros, there may be a few additional directories. And on a custom installation, it may include additional directories, such as /opt. If I am an upstream developer and ship a unit file with ProtectSystem=full, my expectations are that normal operation on directories that are supposed to contain data that is not put there at installation (such as /var, /tmp, /home, /srv, /run, ...) remain accessible, but that systemd will provide an extra layer of security around the rest of the installed system. As an upstream developer, I don't know where the distro the user is using decided to install stuff, whether it's in /usr or directly in /bin or wherever. And I don't really care about that and I don't WANT to care about that. If I really only want /usr to be read-only, I could just add ReadOnlyDirectories=/usr to the unit file and be done with it. But I don't want to care about distro details as an upstream developer, I want the setting to just work[tm] and do the right thing[tm]. The fact that it is a generically named option makes me actually expect an abstraction of distro differences. On the other hand, if I put my administrator hat on, as I said in the last mail, I will know what directories may be present additionally that could also fall under that umbrella. And if something breaks because I put in a stupid setting, that's my bad. By all means, put a big fat warning in the docs that this setting is dangerous to fiddle around with. I do see a good bit of orthogonality here: - Upstream developers can clearly expect that /usr-_type_ (!) stuff is protected
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On Tue, 21.10.14 15:57, Christian Seiler (christ...@iwakd.de) wrote: Am 2014-10-21 14:28, schrieb Lennart Poettering: We explicitly make no assumptions on /opt because nobody knows right now what it is supposed to be... Sure, I wasn't disputing that point. 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. That's why I didn't suggest that you (as upstream) should be in that game, but that distributions and administrators should be able to do so themselves. Will distros always are in charge, as they can for example merge Martin's patch downstream. (Though I'd be careful.) Therefore, may I suggest to make this configurable in /etc/systemd/system.conf: [...] 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. Debian's systemd package currently includes a variant of Martin's patch that does include additional directories. So your point that ProtectSystem= does the same thing on every distro is already not true. Which ones precisely? Of course, if you make it configurable, people can shoot themselves in the foot. But you already have a ton of global options in system.conf that can break a lot of software if people do stupid stuff with it: - set a global CapabilityBoundingSet= that's very restrictive - either the system doesn't boot at all because some essential stuff is completely missing - or it boots but some services don't work because they rely on certain things Well, it's a different thing really, I think. Finding resources in the file system and access to certain anyway priviliged facilities are not the same thing. - set SystemCallArchitectures=native when non-native software is installed Same here. In this case the software will totally fail to run, the failure is early and immediate. - set DefaultEnvironment=LD_TRACE_LOADED_OBJECTS=1 or the such Well, environment variables is something completely out of our reach, we are not the ones defining them. - set DefaultTimeoutStartSec=1 to break any unit that takes longer than 1 second to start but doesn't set an own timeout because it assumes the default timeout is sane - DefaultLimitCPU=1 - ... Well, I am not against making certain parameters configurable. I am simply saying that I don't want to make configurable how the base OS is laid out. Also, to go to your apache example: it's not clear that ProtectSystem= just making /usr readonly doesn't break things: I have seen DocumentRoots beneath /usr in the wild (/usr/local/www or the such), with people running dynamic webapps that had to write into that tree. If you then upgrade from a package version that did not include ProtectSystem= (perhaps because it only included a SysV init script) to a package version that does include ProtectSystem=, things will break. Well, sure everything new we introduce can break things. No doubt. But that's really why I wrote sufficiently sure instead of absolutely in my earlier mail. I actually agree with your sentiment of having an agreement between upstream developers and the core OS - I just think I would like to interpret the matter a little differently: To me, ProtectSystem= is supposed to be a protection of all the files a) installed on a system (not created by the user) and b) not subject to modification by typical services. (i.e. not a cache / status file / ...) For distros with /usr-move, this falls back to /usr and /boot (and /etc if =full). For other distros, there may be a few additional directories. And on a custom installation, it may include additional directories, such as /opt. Again, I disagree with this definition. Consider looking at this from an upstream perspective: if you are writing a unit file and really want to lock things down, then you want to enable everything where you understand the effect and what it entails. You also want to arrange your package in a way that fits this nicely. We achieve that now with the option, because we can explain in one or two sentences what this is about and what upstream has to do to make this work nicely. But sticking one configuration layer on
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On Tue, 21.10.14 13:38, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 21/10/14 13:03, Christian Seiler wrote: That is definitely a good point. Also note that /lib32 is not included in the patch... lib64 is part of the Linux/x86_64 platform ABI (the exact path /lib64/ld-linux-x86-64.so.2 is hard-coded into every Linux/x86_64 executable) so it cannot be considered legacy. Is there a Linux ABI where /lib32 has the same status? If not, then its priority is rather lower. Debian x86_64 (amd64) systems with bi-arch i386 binaries (ia32-libs) are the only instance of /lib32 that I can think of, and that setup is superseded by multiarch these days. Well, on some distros lib64 is a symlink on others it isn't. Doesn't Debian have /lib/arch or so with /lib64 just a symlink to the right subdir? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On 21/10/14 19:18, Lennart Poettering wrote: Well, on some distros lib64 is a symlink on others it isn't. Doesn't Debian have /lib/arch or so with /lib64 just a symlink to the right subdir? My Debian laptop has /lib64 as a real directory, containing a ld-linux-x86-64.so.2 symlink into /lib/multiarch tuple. I suspect this might be partly because Debian packages containing other files or symlinks in /lib64 have existed in the past (e.g. to support biarch compilers), and if any of those packages have lingered, dpkg is not going to be happy to replace a non-empty directory with a symlink. Being able to mount something read-only over /lib64 and /lib also seems necessary from the ProtectSystem point of view, if you want ProtectSystem to be a security measure and not just a guard against accidents, since those two strings are part of the portable ABI for Linux binaries on various architectures[1]. If a service can overwrite one of those symlinks with an attacker-chosen value, then it's game over the next time a binary with the relevant PT_INTERP tag is executed. It looks as though I was wrong about lib32 not being necessary, it's in that list too (albeit only for mips and tilegx); so is /libx32. S [1] https://sourceware.org/glibc/wiki/ABIList ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On Tue, 21.10.14 21:22, Christian Seiler (christ...@iwakd.de) wrote: Am 21.10.2014 20:09, schrieb Lennart Poettering: Debian's systemd package currently includes a variant of Martin's patch that does include additional directories. So your point that ProtectSystem= does the same thing on every distro is already not true. Which ones precisely? Here: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Include-additional-directories-in-ProtectSystem.patch (included in debian/patches/series under the heading 'Debian-specific patches') Ah, well, at least they should make the lib64 thing arch dependent. Otherwise, since you are obviously dead-set against this, I'm not going to argue this further (I don't think I will be able convince you), even though I disagree with a lot of your points of view in your reply. Unless you'd be interested in my response regardless, then I'd be happy to actually write it up. Yeah, I think it will be hard to convince me otherwise. Sorry! THis is one thing to agree to disagree on I figure. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On Sun, 19.10.14 12:05, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, in Debian/Ubuntu we don't use the merged /usr tree for now. systemd generally supports that (HAVE_SPLIT_USR), but doesn't consider that for ProtectSystem=. Ansgar (CC'ed) wrote a Debian specific patch for that some months ago. I generalized it for upstream now. Thanks for considering, 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. 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). Also note that it hardcodes x86_64 peculiarities in an arch-independent way, which looks pretty wrong too. 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. Sorry if that's disappointing, but this patch is really something to carry downstream if at all. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Hello all,
in Debian/Ubuntu we don't use the merged /usr tree for now. systemd
generally supports that (HAVE_SPLIT_USR), but doesn't consider that
for ProtectSystem=.
Ansgar (CC'ed) wrote a Debian specific patch for that some months ago.
I generalized it for upstream now.
Thanks for considering,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 84133fed054b02702955d9371a553c213a45ee9e Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Sun, 19 Oct 2014 11:56:45 -0400
Subject: [PATCH] Apply ProtectSystem to non-merged /usr directories
For systems that don't use a merged /usr, also protect /bin, /sbin, /lib, and
/lib64.
Separately handle /etc (for ProtectSystem=full) to make the code a bit easier
to read.
Replace hard-coded length of systemd dirs list with strv_length() to avoid
pitfalls.
---
src/core/namespace.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/core/namespace.c b/src/core/namespace.c
index ab03aeb..ac48f4d 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -420,6 +420,12 @@ static int make_read_only(BindMount *m) {
return r;
}
+#ifdef HAVE_SPLIT_USR
+#define SYSTEM_DIRS STRV_MAKE(/usr, /bin, /sbin, /lib, -/lib64, -/boot)
+#else
+#define SYSTEM_DIRS STRV_MAKE(/usr, -/boot)
+#endif
+
int setup_namespace(
char** read_write_dirs,
char** read_only_dirs,
@@ -448,7 +454,7 @@ int setup_namespace(
strv_length(inaccessible_dirs) +
private_dev +
(protect_home != PROTECT_HOME_NO ? 3 : 0) +
-(protect_system != PROTECT_SYSTEM_NO ? 2 : 0) +
+(protect_system != PROTECT_SYSTEM_NO ? strv_length(SYSTEM_DIRS) : 0) +
(protect_system == PROTECT_SYSTEM_FULL ? 1 : 0);
if (n 0) {
@@ -496,9 +502,14 @@ int setup_namespace(
}
if (protect_system != PROTECT_SYSTEM_NO) {
-r = append_mounts(m, protect_system == PROTECT_SYSTEM_FULL ? STRV_MAKE(/usr, -/boot, /etc) : STRV_MAKE(/usr, -/boot), READONLY);
+r = append_mounts(m, SYSTEM_DIRS, READONLY);
if (r 0)
return r;
+if (protect_system == PROTECT_SYSTEM_FULL) {
+r = append_mounts(m, STRV_MAKE(/etc), READONLY);
+if (r 0)
+return r;
+}
}
assert(mounts + n == m);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
