SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

New directives NoExecPaths= ExecPaths=

Browse Source 
Implement directives `NoExecPaths=` and `ExecPaths=` to control `MS_NOEXEC`
mount flag for the file system tree. This can be used to implement file system
W^X policies, and for example with allow-listing mode (NoExecPaths=/) a
compromised service would not be able to execute a shell, if that was not
explicitly allowed.

Example:
[Service]
NoExecPaths=/
ExecPaths=/usr/bin/daemon /usr/lib64 /usr/lib

Closes: #17942.
This commit is contained in:
Topi Miettinen
2021-01-29 12:40:52 +00:00
committed by Topi Miettinen
parent 78dff3f3d7
commit ddc155b2fd
15 changed files with 240 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/shared/mount-util.c
+8 -7
View File
@@ -210,13 +210,14 @@ int bind_remount_recursive_with_mountinfo(
assert(prefix);
assert(proc_self_mountinfo);
/* Recursively remount a directory (and all its submounts) read-only or read-write. If the directory is already
* mounted, we reuse the mount and simply mark it MS_BIND|MS_RDONLY (or remove the MS_RDONLY for read-write
* operation). If it isn't we first make it one. Afterwards we apply MS_BIND|MS_RDONLY (or remove MS_RDONLY) to
* all submounts we can access, too. When mounts are stacked on the same mount point we only care for each
* individual "top-level" mount on each point, as we cannot influence/access the underlying mounts anyway. We
* do not have any effect on future submounts that might get propagated, they might be writable. This includes
* future submounts that have been triggered via autofs.
/* Recursively remount a directory (and all its submounts) with desired flags (MS_READONLY,
* MS_NOSUID, MS_NOEXEC). If the directory is already mounted, we reuse the mount and simply mark it
* MS_BIND|MS_RDONLY (or remove the MS_RDONLY for read-write operation), ditto for other flags. If it
* isn't we first make it one. Afterwards we apply (or remove) the flags to all submounts we can
* access, too. When mounts are stacked on the same mount point we only care for each individual
* "top-level" mount on each point, as we cannot influence/access the underlying mounts anyway. We do
* not have any effect on future submounts that might get propagated, they might be writable
* etc. This includes future submounts that have been triggered via autofs.
*
* If the "deny_list" parameter is specified it may contain a list of subtrees to exclude from the
* remount operation. Note that we'll ignore the deny list for the top-level path. */