Hi,
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
Would It be useful to take a pass at configuring this more sandboxy? in my opinion, security should be default.
It appears this is a lot simpler to contain the services than with functionality like apparmor or selinux, although those of course provide further protection.
Here's an example on smartd.service:
# systemd-analyze security smartd.service NAME DESCRIPTION EXPOSURE ✗ PrivateNetwork= Service has access to the host's network 0.5 ✗ User=/DynamicUser= Service runs as root user 0.4 ✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities 0.3 ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges 0.3 ✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities 0.3 ✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3 ✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces 0.3 ✗ RestrictAddressFamilies=~… Service may allocate exotic sockets 0.3 ✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unrestricted 0.2 ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks 0.2 ✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_RAWIO Service has raw I/O access 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_TIME Service processes may change the system clock 0.2 ✗ DeviceAllow= Service has no device ACL 0.2 ✗ IPAddressDeny= Service does not define an IP address allow list 0.2 ✓ KeyringMode= Service doesn't share key material with other services ✗ NoNewPrivileges= Service processes may acquire new privileges 0.2 ✓ NotifyAccess= Service child processes cannot alter service state ✗ PrivateDevices= Service potentially has access to hardware devices 0.2 ✗ PrivateMounts= Service may install system mounts 0.2 ✗ PrivateTmp= Service has access to other software's temporary files 0.2 ✗ PrivateUsers= Service has access to other users 0.2 ✗ ProtectClock= Service may write to the hardware clock or system clock 0.2 ✗ ProtectControlGroups= Service may modify the control group file system 0.2 ✗ ProtectHome= Service has full access to home directories 0.2 ✗ ProtectKernelLogs= Service may read from or write to the kernel log ring buffer 0.2 ✗ ProtectKernelModules= Service may load or read kernel modules 0.2 ✗ ProtectKernelTunables= Service may alter kernel tunables 0.2 ✗ ProtectSystem= Service has full access to the OS file hierarchy 0.2 ✗ RestrictAddressFamilies=~AF_PACKET Service may allocate packet sockets 0.2 ✗ RestrictSUIDSGID= Service may create SUID/SGID files 0.2 ✗ SystemCallArchitectures= Service may execute system calls with all ABIs 0.2 ✗ SystemCallFilter=~@clock Service does not filter system calls 0.2 ✗ SystemCallFilter=~@debug Service does not filter system calls 0.2 ✗ SystemCallFilter=~@module Service does not filter system calls 0.2 ✗ SystemCallFilter=~@mount Service does not filter system calls 0.2 ✗ SystemCallFilter=~@raw-io Service does not filter system calls 0.2 ✗ SystemCallFilter=~@reboot Service does not filter system calls 0.2 ✗ SystemCallFilter=~@swap Service does not filter system calls 0.2 ✗ SystemCallFilter=~@privileged Service does not filter system calls 0.2 ✗ SystemCallFilter=~@resources Service does not filter system calls 0.2 ✓ AmbientCapabilities= Service process does not receive ambient capabilities ✗ CapabilityBoundingSet=~CAP_AUDIT_* Service has audit subsystem access 0.1 ✗ CapabilityBoundingSet=~CAP_KILL Service may send UNIX signals to arbitrary processes 0.1 ✗ CapabilityBoundingSet=~CAP_MKNOD Service may create device nodes 0.1 ✗ CapabilityBoundingSet=~CAP_NET_(BIND_SERVICE|BROADCAST|RAW) Service has elevated networking privileges 0.1 ✗ CapabilityBoundingSet=~CAP_SYSLOG Service has access to kernel logging 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_(NICE|RESOURCE) Service has privileges to change resource use parameters 0.1 ✗ RestrictNamespaces=~CLONE_NEWCGROUP Service may create cgroup namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWIPC Service may create IPC namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWNET Service may create network namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWNS Service may create file system namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWPID Service may create process namespaces 0.1 ✗ RestrictRealtime= Service may acquire realtime scheduling 0.1 ✗ SystemCallFilter=~@cpu-emulation Service does not filter system calls 0.1 ✗ SystemCallFilter=~@obsolete Service does not filter system calls 0.1 ✗ RestrictAddressFamilies=~AF_NETLINK Service may allocate netlink sockets 0.1 ✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1 SupplementaryGroups= Service runs as root, option does not matter ✗ CapabilityBoundingSet=~CAP_MAC_* Service may adjust SMACK MAC 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_BOOT Service may issue reboot() 0.1 ✓ Delegate= Service does not maintain its own delegated control group subtree ✗ LockPersonality= Service may change ABI personality 0.1 ✗ MemoryDenyWriteExecute= Service may create writable executable memory mappings 0.1 RemoveIPC= Service runs as root, option does not apply ✗ RestrictNamespaces=~CLONE_NEWUTS Service may create hostname namespaces 0.1 ✗ UMask= Files created by service are world-readable by default 0.1 ✗ CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE Service may mark files immutable 0.1 ✗ CapabilityBoundingSet=~CAP_IPC_LOCK Service may lock memory into RAM 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_CHROOT Service may issue chroot() 0.1 ✗ ProtectHostname= Service may change system host/domainname 0.1 ✗ CapabilityBoundingSet=~CAP_BLOCK_SUSPEND Service may establish wake locks 0.1 ✗ CapabilityBoundingSet=~CAP_LEASE Service may create file leases 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_PACCT Service may use acct() 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() 0.1 ✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system 0.1 ✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
→ Overall exposure level for smartd.service: 9.6 UNSAFE
On 1/25/21 9:54 PM, Dirk Müller wrote:
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
Would It be useful to take a pass at configuring this more sandboxy? in my opinion, security should be default.
Full ack. openSUSE should use it!
Are you a maintainer of some packages? If yes, then start by adding those sandboxing options to systemd units of your packages.
I've started to do this in my ansible roles for Æ-DIR components (which cover various Linux distros). And I've started to do this for some openSUSE packages.
Be prepared to fiddle e.g. SystemCallFilter= for different OS / systemd versions if you're eager using that.
It appears this is a lot simpler to contain the services than with functionality like apparmor or selinux, although those of course provide further protection.
I do both: systemd sandboxing and AppArmor profiles. IMO AppArmor profiles should also be part of the packages.
Here's an example on smartd.service:
More examples:
https://build.opensuse.org/package/show/network:telephony/coturn
https://build.opensuse.org/package/show/network:telephony/galene
Ciao, Michael.
* Dirk Müller dirk@dmllr.de [01-25-21 16:00]:
Hi,
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
Would It be useful to take a pass at configuring this more sandboxy? in my opinion, security should be default.
It appears this is a lot simpler to contain the services than with functionality like apparmor or selinux, although those of course provide further protection.
Here's an example on smartd.service:
# systemd-analyze security smartd.service NAME DESCRIPTION EXPOSURE ✗ PrivateNetwork= Service has access to the host's network 0.5
[...]
→ Overall exposure level for smartd.service: 9.6 UNSAFE
you want to see an even worse report, try: systemd-analyze security
note: I have cc'd you as I am currently censored and sometimes posts are delayed for extended time periods. But it doesn't seem to bother those tasked with the duty.
On 25/01/2021 22.49, Patrick Shanahan wrote:
- Dirk Müller dirk@dmllr.de [01-25-21 16:00]:
Hi,
today I stumbled over "systemd-analyze security" which gives an
you want to see an even worse report, try: systemd-analyze security
did I miss something or did you recommend exactly what Dirk recommended?
Hi Dirk,
Is it possible to write rpmlint check for this? I suppose this would be the better way for spotting this kind of issues in all packages.
25.01.2021 23:54, Dirk Müller пишет:
Hi,
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
Would It be useful to take a pass at configuring this more sandboxy? in my opinion, security should be default.
It appears this is a lot simpler to contain the services than with functionality like apparmor or selinux, although those of course provide further protection.
Here's an example on smartd.service:
# systemd-analyze security smartd.service NAME DESCRIPTION EXPOSURE ✗ PrivateNetwork= Service has access to the host's network 0.5 ✗ User=/DynamicUser= Service runs as root user 0.4 ✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities 0.3 ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges 0.3 ✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities 0.3 ✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3 ✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces 0.3 ✗ RestrictAddressFamilies=~… Service may allocate exotic sockets 0.3 ✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unrestricted 0.2 ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks 0.2 ✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_RAWIO Service has raw I/O access 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_TIME Service processes may change the system clock 0.2 ✗ DeviceAllow= Service has no device ACL 0.2 ✗ IPAddressDeny= Service does not define an IP address allow list 0.2 ✓ KeyringMode= Service doesn't share key material with other services ✗ NoNewPrivileges= Service processes may acquire new privileges 0.2 ✓ NotifyAccess= Service child processes cannot alter service state ✗ PrivateDevices= Service potentially has access to hardware devices 0.2 ✗ PrivateMounts= Service may install system mounts 0.2 ✗ PrivateTmp= Service has access to other software's temporary files 0.2 ✗ PrivateUsers= Service has access to other users 0.2 ✗ ProtectClock= Service may write to the hardware clock or system clock 0.2 ✗ ProtectControlGroups= Service may modify the control group file system 0.2 ✗ ProtectHome= Service has full access to home directories 0.2 ✗ ProtectKernelLogs= Service may read from or write to the kernel log ring buffer 0.2 ✗ ProtectKernelModules= Service may load or read kernel modules 0.2 ✗ ProtectKernelTunables= Service may alter kernel tunables 0.2 ✗ ProtectSystem= Service has full access to the OS file hierarchy 0.2 ✗ RestrictAddressFamilies=~AF_PACKET Service may allocate packet sockets 0.2 ✗ RestrictSUIDSGID= Service may create SUID/SGID files 0.2 ✗ SystemCallArchitectures= Service may execute system calls with all ABIs 0.2 ✗ SystemCallFilter=~@clock Service does not filter system calls 0.2 ✗ SystemCallFilter=~@debug Service does not filter system calls 0.2 ✗ SystemCallFilter=~@module Service does not filter system calls 0.2 ✗ SystemCallFilter=~@mount Service does not filter system calls 0.2 ✗ SystemCallFilter=~@raw-io Service does not filter system calls 0.2 ✗ SystemCallFilter=~@reboot Service does not filter system calls 0.2 ✗ SystemCallFilter=~@swap Service does not filter system calls 0.2 ✗ SystemCallFilter=~@privileged Service does not filter system calls 0.2 ✗ SystemCallFilter=~@resources Service does not filter system calls 0.2 ✓ AmbientCapabilities= Service process does not receive ambient capabilities ✗ CapabilityBoundingSet=~CAP_AUDIT_* Service has audit subsystem access 0.1 ✗ CapabilityBoundingSet=~CAP_KILL Service may send UNIX signals to arbitrary processes 0.1 ✗ CapabilityBoundingSet=~CAP_MKNOD Service may create device nodes 0.1 ✗ CapabilityBoundingSet=~CAP_NET_(BIND_SERVICE|BROADCAST|RAW) Service has elevated networking privileges 0.1 ✗ CapabilityBoundingSet=~CAP_SYSLOG Service has access to kernel logging 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_(NICE|RESOURCE) Service has privileges to change resource use parameters 0.1 ✗ RestrictNamespaces=~CLONE_NEWCGROUP Service may create cgroup namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWIPC Service may create IPC namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWNET Service may create network namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWNS Service may create file system namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWPID Service may create process namespaces 0.1 ✗ RestrictRealtime= Service may acquire realtime scheduling 0.1 ✗ SystemCallFilter=~@cpu-emulation Service does not filter system calls 0.1 ✗ SystemCallFilter=~@obsolete Service does not filter system calls 0.1 ✗ RestrictAddressFamilies=~AF_NETLINK Service may allocate netlink sockets 0.1 ✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1 SupplementaryGroups= Service runs as root, option does not matter ✗ CapabilityBoundingSet=~CAP_MAC_* Service may adjust SMACK MAC 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_BOOT Service may issue reboot() 0.1 ✓ Delegate= Service does not maintain its own delegated control group subtree ✗ LockPersonality= Service may change ABI personality 0.1 ✗ MemoryDenyWriteExecute= Service may create writable executable memory mappings 0.1 RemoveIPC= Service runs as root, option does not apply ✗ RestrictNamespaces=~CLONE_NEWUTS Service may create hostname namespaces 0.1 ✗ UMask= Files created by service are world-readable by default 0.1 ✗ CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE Service may mark files immutable 0.1 ✗ CapabilityBoundingSet=~CAP_IPC_LOCK Service may lock memory into RAM 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_CHROOT Service may issue chroot() 0.1 ✗ ProtectHostname= Service may change system host/domainname 0.1 ✗ CapabilityBoundingSet=~CAP_BLOCK_SUSPEND Service may establish wake locks 0.1 ✗ CapabilityBoundingSet=~CAP_LEASE Service may create file leases 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_PACCT Service may use acct() 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() 0.1 ✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system 0.1 ✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
→ Overall exposure level for smartd.service: 9.6 UNSAFE
Hi,
On Tue, Jan 26, Matwey V. Kornilov wrote:
Hi Dirk,
Is it possible to write rpmlint check for this? I suppose this would be the better way for spotting this kind of issues in all packages.
This doesn't make sense as this are no generic issues. Every service has different requirements. You need to evaluate every single service to find out, which capabilities are required and which you can safely take away. E.g. wouldn't make much sense to forbid chrony to set the time or rebootmgr to run as root...
Thorsten
25.01.2021 23:54, Dirk Müller пишет:
Hi,
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
Would It be useful to take a pass at configuring this more sandboxy? in my opinion, security should be default.
It appears this is a lot simpler to contain the services than with functionality like apparmor or selinux, although those of course provide further protection.
Here's an example on smartd.service:
# systemd-analyze security smartd.service NAME DESCRIPTION EXPOSURE ✗ PrivateNetwork= Service has access to the host's network 0.5 ✗ User=/DynamicUser= Service runs as root user 0.4 ✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities 0.3 ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges 0.3 ✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities 0.3 ✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3 ✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces 0.3 ✗ RestrictAddressFamilies=~… Service may allocate exotic sockets 0.3 ✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unrestricted 0.2 ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks 0.2 ✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_RAWIO Service has raw I/O access 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_TIME Service processes may change the system clock 0.2 ✗ DeviceAllow= Service has no device ACL 0.2 ✗ IPAddressDeny= Service does not define an IP address allow list 0.2 ✓ KeyringMode= Service doesn't share key material with other services ✗ NoNewPrivileges= Service processes may acquire new privileges 0.2 ✓ NotifyAccess= Service child processes cannot alter service state ✗ PrivateDevices= Service potentially has access to hardware devices 0.2 ✗ PrivateMounts= Service may install system mounts 0.2 ✗ PrivateTmp= Service has access to other software's temporary files 0.2 ✗ PrivateUsers= Service has access to other users 0.2 ✗ ProtectClock= Service may write to the hardware clock or system clock 0.2 ✗ ProtectControlGroups= Service may modify the control group file system 0.2 ✗ ProtectHome= Service has full access to home directories 0.2 ✗ ProtectKernelLogs= Service may read from or write to the kernel log ring buffer 0.2 ✗ ProtectKernelModules= Service may load or read kernel modules 0.2 ✗ ProtectKernelTunables= Service may alter kernel tunables 0.2 ✗ ProtectSystem= Service has full access to the OS file hierarchy 0.2 ✗ RestrictAddressFamilies=~AF_PACKET Service may allocate packet sockets 0.2 ✗ RestrictSUIDSGID= Service may create SUID/SGID files 0.2 ✗ SystemCallArchitectures= Service may execute system calls with all ABIs 0.2 ✗ SystemCallFilter=~@clock Service does not filter system calls 0.2 ✗ SystemCallFilter=~@debug Service does not filter system calls 0.2 ✗ SystemCallFilter=~@module Service does not filter system calls 0.2 ✗ SystemCallFilter=~@mount Service does not filter system calls 0.2 ✗ SystemCallFilter=~@raw-io Service does not filter system calls 0.2 ✗ SystemCallFilter=~@reboot Service does not filter system calls 0.2 ✗ SystemCallFilter=~@swap Service does not filter system calls 0.2 ✗ SystemCallFilter=~@privileged Service does not filter system calls 0.2 ✗ SystemCallFilter=~@resources Service does not filter system calls 0.2 ✓ AmbientCapabilities= Service process does not receive ambient capabilities ✗ CapabilityBoundingSet=~CAP_AUDIT_* Service has audit subsystem access 0.1 ✗ CapabilityBoundingSet=~CAP_KILL Service may send UNIX signals to arbitrary processes 0.1 ✗ CapabilityBoundingSet=~CAP_MKNOD Service may create device nodes 0.1 ✗ CapabilityBoundingSet=~CAP_NET_(BIND_SERVICE|BROADCAST|RAW) Service has elevated networking privileges 0.1 ✗ CapabilityBoundingSet=~CAP_SYSLOG Service has access to kernel logging 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_(NICE|RESOURCE) Service has privileges to change resource use parameters 0.1 ✗ RestrictNamespaces=~CLONE_NEWCGROUP Service may create cgroup namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWIPC Service may create IPC namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWNET Service may create network namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWNS Service may create file system namespaces 0.1 ✗ RestrictNamespaces=~CLONE_NEWPID Service may create process namespaces 0.1 ✗ RestrictRealtime= Service may acquire realtime scheduling 0.1 ✗ SystemCallFilter=~@cpu-emulation Service does not filter system calls 0.1 ✗ SystemCallFilter=~@obsolete Service does not filter system calls 0.1 ✗ RestrictAddressFamilies=~AF_NETLINK Service may allocate netlink sockets 0.1 ✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1 SupplementaryGroups= Service runs as root, option does not matter ✗ CapabilityBoundingSet=~CAP_MAC_* Service may adjust SMACK MAC 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_BOOT Service may issue reboot() 0.1 ✓ Delegate= Service does not maintain its own delegated control group subtree ✗ LockPersonality= Service may change ABI personality 0.1 ✗ MemoryDenyWriteExecute= Service may create writable executable memory mappings 0.1 RemoveIPC= Service runs as root, option does not apply ✗ RestrictNamespaces=~CLONE_NEWUTS Service may create hostname namespaces 0.1 ✗ UMask= Files created by service are world-readable by default 0.1 ✗ CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE Service may mark files immutable 0.1 ✗ CapabilityBoundingSet=~CAP_IPC_LOCK Service may lock memory into RAM 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_CHROOT Service may issue chroot() 0.1 ✗ ProtectHostname= Service may change system host/domainname 0.1 ✗ CapabilityBoundingSet=~CAP_BLOCK_SUSPEND Service may establish wake locks 0.1 ✗ CapabilityBoundingSet=~CAP_LEASE Service may create file leases 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_PACCT Service may use acct() 0.1 ✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() 0.1 ✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system 0.1 ✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
→ Overall exposure level for smartd.service: 9.6 UNSAFE
Thorsten Kukuk wrote:
On Tue, Jan 26, Matwey V. Kornilov wrote:
Is it possible to write rpmlint check for this? I suppose this would be the better way for spotting this kind of issues in all packages.
This doesn't make sense as this are no generic issues. Every service has different requirements. You need to evaluate every single service to find out, which capabilities are required and which you can safely take away. E.g. wouldn't make much sense to forbid chrony to set the time or rebootmgr to run as root...
Chances are that one can at least apply some restrictions in every service. Total absence of any security related settings probably would be an indication that the service was not reviewed. In the case of the packages you mention those services probably do not need for example CAP_DAC_OVERRIDE or load kernel modules. Even a service running as root could be limited to eg CAP_SYS_TIME or CAP_SYS_BOOT. On that topic we may also want to change the default permissions of OS owned directories to root:root 555 instead of 755. That way a capability restricted process with uid 0 can't write everywhere anymore.
cu Ludwig
Am 2021-01-25 21:54, schrieb Dirk Müller:
Hi,
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
Would It be useful to take a pass at configuring this more sandboxy? in my opinion, security should be default.
It appears this is a lot simpler to contain the services than with functionality like apparmor or selinux, although those of course provide further protection.
Here's an example on smartd.service:
# systemd-analyze security smartd.service
Question1: Does parameter security only exists in tumbleweed?
Question2: What is with check systemd-analyze verify? There are errors in dracut* rc-local* and so on.
Hi Eric,
Question1: Does parameter security only exists in tumbleweed?
yes, it is missing in leap 15.2/sle15 sp2
Question2: What is with check systemd-analyze verify? There are errors in dracut* rc-local* and so on.
thats more a linting style check for syntax errors and so on. that could be a rpmlint check indeed.
Greetings, Dirk
Thanks for you explanations.
Regards Eric
Am 26. Januar 2021 14:02:50 MEZ schrieb "Dirk Müller" dirk@dmllr.de:
Hi Eric,
Question1: Does parameter security only exists in tumbleweed?
yes, it is missing in leap 15.2/sle15 sp2
Question2: What is with check systemd-analyze verify? There are errors in dracut* rc-local* and so on.
thats more a linting style check for syntax errors and so on. that could be a rpmlint check indeed.
Greetings, Dirk
On 25/01/2021 21.54, Dirk Müller wrote:
today I stumbled over "systemd-analyze security" which gives an overview of installed systemd services and their configured sandboxing capabilities. It appears that from the ones that I have installed, most of them have no sandboxing features enabled at all, so pretty much everything is at score 9.5 and above (10 seems to be the absolutely worst).
I started with two:
tor https://build.opensuse.org/request/show/867136 auditd https://github.com/linux-audit/audit-userspace/pull/151
other worthy+easy targets might be dbus display-manager dm-event haveged systemd-ask-password-console systemd-initctl systemd-rfkill wickedd*
I noticed that Leap 15.2 needed some more syscalls in the @resources and @privileged group than Tumbleweed, so if you create very restrictve profiles, be sure to test on 15.2 as well.
Hi Bernhard,
Am Fr., 29. Jan. 2021 um 10:20 Uhr schrieb Bernhard M. Wiedemann bernhardout@lsmod.de:
tor https://build.opensuse.org/request/show/867136 auditd https://github.com/linux-audit/audit-userspace/pull/151
Great, thanks a lot for doing this upstream - this will greatly help getting things sorted out properly and to the benefit of all linux distributions.
I'm curious to learn if others are working on this as well. I've also seen that the SUSE Security team filed https://bugzilla.suse.com/show_bug.cgi?id=1181400 for this. I think if we prioritize a few central services to be sandboxed first, that would benefit us most.
Greetings, Dirk
On 2/1/21 9:22 PM, Dirk Müller wrote:
I'm curious to learn if others are working on this as well. I've also seen that the SUSE Security team filed https://bugzilla.suse.com/show_bug.cgi?id=1181400 for this.
"You are not authorized to access bug #1181400."
Ciao, Michael.
Am Montag, 1. Februar 2021, 22:03:16 CET schrieb Michael Ströder:
On 2/1/21 9:22 PM, Dirk Müller wrote:
I'm curious to learn if others are working on this as well. I've also seen that the SUSE Security team filed https://bugzilla.suse.com/show_bug.cgi?id=1181400 for this.
"You are not authorized to access bug #1181400."
same issue for bugzilla.opensuse.org....
Am Mo., 1. Feb. 2021 um 22:14 Uhr schrieb Axel Braun axel.braun@gmx.de:
"You are not authorized to access bug #1181400."
same issue for bugzilla.opensuse.org...
I've asked whether the bug can be opened up. its just a tracker number for reference to systemd sandboxing improvements. nothing really interesting in there.
Greetings, Dirk
On Mon, Feb 01, 2021 at 10:19:18PM +0100, Dirk Müller wrote:
Am Mo., 1. Feb. 2021 um 22:14 Uhr schrieb Axel Braun axel.braun@gmx.de:
"You are not authorized to access bug #1181400."
same issue for bugzilla.opensuse.org...
I've asked whether the bug can be opened up. its just a tracker number for reference to systemd sandboxing improvements. nothing really interesting in there.
The bug is now open.
We opened it due to this discussion here.
Ciao, Marcus
On 1/29/21 10:19 AM, Bernhard M. Wiedemann wrote:
I started with two: [..] I noticed that Leap 15.2 needed some more syscalls in the @resources and @privileged group than Tumbleweed, so if you create very restrictve profiles, be sure to test on 15.2 as well.
I also have weird hacks for this distinction:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/vars/main.yml#...
Is it really necessary to support Leap 15.2? And how about the situation in 15.3?
Jinja2 templating for .service files would be nice.
Ciao, Michael.
On 01/02/2021 21.49, Michael Ströder wrote:
On 1/29/21 10:19 AM, Bernhard M. Wiedemann wrote:
I started with two: [..] I noticed that Leap 15.2 needed some more syscalls in the @resources and @privileged group than Tumbleweed, so if you create very restrictve profiles, be sure to test on 15.2 as well.
I also have weird hacks for this distinction:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/vars/main.yml#...
Is it really necessary to support Leap 15.2?
IMHO, you should not change 15.2. Implement changes on 15.3 instead.
And how about the situation in 15.3?
On 01/02/2021 21.49, Michael Ströder wrote:
Is it really necessary to support Leap 15.2?
Yes. We have devel projects that people use on older Leap versions and IMHO, it is OK to only apply 30 of 32 possible hardenings to not have to maintain extra cases. Otherwise the testing matrix grows too much.
In general, users don't like to be overly restricted by security either. Our homes don't have a secure 1000 kg steel door like banks do, because there is often this trade-off between usability and security.
Ciao Bernhard M.
On 2/3/21 12:14 PM, Bernhard M. Wiedemann wrote:
On 01/02/2021 21.49, Michael Ströder wrote:
Is it really necessary to support Leap 15.2?
Yes. We have devel projects that people use on older Leap versions and IMHO, it is OK to only apply 30 of 32 possible hardenings to not have to maintain extra cases. Otherwise the testing matrix grows too much.
It is much work going through all this so I'd recommend to do the work one time, but do it right.
Given the old systemd version in Leap 15.2 there are two issues:
1. Some config directives are not known to Leap's systemd. Log messages might confuse users. IMHO this would be acceptable.
2. Some syscall filter options will prevent the service to work properly.
In general, users don't like to be overly restricted by security either.
Users will *not* be overly restricted. If done right users will *not* notice any difference!
Our homes don't have a secure 1000 kg steel door like banks do, because there is often this trade-off between usability and security.
With this argument you could stop working on it.
Those security options are rarely needed. But in case of zero-day exploits everybody will appreciate having any line of defense which eventually gives more time to fix the underlying issue. That's the whole point of having these security options in place: They are there for *unknown* issues. So you cannot even argue now for having them.
Personally I'm implementing custom systemd units which work on Tumbleweed but likely not on Leap. I'm willing to contribute what I've learned so far. But if I still have to maintain my custom systemd units to reach the level of protection I'm aiming at this is way too much effort on my side.
Ciao, Michael.
Le mercredi 03 février 2021 à 14:05 +0100, Michael Ströder a écrit :
On 2/3/21 12:14 PM, Bernhard M. Wiedemann wrote:
On 01/02/2021 21.49, Michael Ströder wrote:
Is it really necessary to support Leap 15.2?
Yes. We have devel projects that people use on older Leap versions and IMHO, it is OK to only apply 30 of 32 possible hardenings to not have to maintain extra cases. Otherwise the testing matrix grows too much.
It is much work going through all this so I'd recommend to do the work one time, but do it right.
Given the old systemd version in Leap 15.2 there are two issues:
Please note Leap 15.3 will have a newer systemd (246), which would handle much more syscalls.
On 03.02.21 14:05, Michael Ströder wrote:
Users will *not* be overly restricted. If done right users will *not* notice any difference!
Is there a switch to globally disable all these filters? Because I have learned with Apparmor that "rcapparmor stop" (or "aa-teardown" nowadays) solves about 95% of my strange problems that I find on my openSUSE installation.
If you are lucky, a default installation is tested, but any custom config probably is not, and thus will fail in crazy ways with seemingly unrelated error messages.
Last example I remember offhand: ntpd trying to access ttyS0 (serial dcf77 clock) and being denied by apparmor.
On Wed, Feb 03, Stefan Seyfried wrote:
On 03.02.21 14:05, Michael Ströder wrote:
Users will *not* be overly restricted. If done right users will *not* notice any difference!
Is there a switch to globally disable all these filters? Because I have learned with Apparmor that "rcapparmor stop" (or "aa-teardown" nowadays) solves about 95% of my strange problems that I find on my openSUSE installation.
If you are lucky, a default installation is tested, but any custom config probably is not, and thus will fail in crazy ways with seemingly unrelated error messages.
From my experience, this is the biggest problem: people don't analyse the source code to find out what the application needs, but they are running it in their default configuration on their system, and if it works there, it's good enough and will be submitted. And the next one using a more advanced configuration runs into the errors.
Better invest the time in good SELinux and AppArmor policies. This helps much more, especially if you don't run the service via systemd but from the commandline. This systemd pseudo security feature will not give you any additional security.
Thorsten
On 2/3/21 3:14 PM, Thorsten Kukuk wrote:
Better invest the time in good SELinux and AppArmor policies. This helps much more, especially if you don't run the service via systemd but from the commandline.
I'd recommend to follow defense-in-depth principle and do both.
This systemd pseudo security feature will not give you any additional security.
AFAIK AppArmor does not implement something like SystemCallFilter=.
Ciao, Michael.
On 2/3/21 2:58 PM, Stefan Seyfried wrote:
On 03.02.21 14:05, Michael Ströder wrote:
Users will *not* be overly restricted. If done right users will *not* notice any difference!
Is there a switch to globally disable all these filters?
Not that I know of.
Because I have learned with Apparmor that "rcapparmor stop" (or "aa-teardown" nowadays) solves about 95% of my strange problems that I find on my openSUSE installation.
Hmm.
If you are lucky, a default installation is tested, but any custom config probably is not, and thus will fail in crazy ways with seemingly unrelated error messages.
I can somewhat understand your concerns.
I'd like compare it to current use of standard firewalling rules. There is a base configuration which works for most users but there might be special cases. And anyone seriously configuring custom network setup is up to implement custom firewall rules.
Last example I remember offhand: ntpd trying to access ttyS0 (serial dcf77 clock) and being denied by apparmor.
I'd not start with ntpd and chrony especially because they access hardware, muck with the system and hardware clocks and query the network. This has to be ironed out and this will be some work.
(Strictly speaking I'd argue that it's a design flaw of ntpd and chrony to access hardware devices, critical system clocks and network services within a single monolithic process.)
Ciao, Michael.
Citeren Michael Ströder michael@stroeder.com:
If you are lucky, a default installation is tested, but any custom config probably is not, and thus will fail in crazy ways with seemingly unrelated error messages.
I can somewhat understand your concerns.
I do too. The problem here is not the fact that something is being blocked, but that is very difficult to find out what the cause is. Usually, the application that attempts to use a feature will be blissfully unaware that systemd/apparmore/whatever is blocking access and invariably doesn't return a useful errormessage when some common feature is suddenly gone.
I found out two weeks ago that the fstrim service was no longer working because of systemd 'protecting' access to the filesystem after several systems with SSD root filesystems were slow as molasses on writes, occasionally blocking for minutes (boo#1181352).
I'd like compare it to current use of standard firewalling rules. There is a base configuration which works for most users but there might be special cases. And anyone seriously configuring custom network setup is up to implement custom firewall rules.
In that case, one can look at logs or hit counters for firewall rules to see what is going on. Is there something similar for systemd? I'd love to know.
Regards, Arjen
On 2/3/21 7:05 PM, Arjen de Korte wrote:
Citeren Michael Ströder michael@stroeder.com:
If you are lucky, a default installation is tested, but any custom config probably is not, and thus will fail in crazy ways with seemingly unrelated error messages.
I can somewhat understand your concerns.
I do too. The problem here is not the fact that something is being blocked, but that is very difficult to find out what the cause is. Usually, the application that attempts to use a feature will be blissfully unaware that systemd/apparmore/whatever is blocking access and invariably doesn't return a useful errormessage when some common feature is suddenly gone.
Yes, the famous "permissions denied" and file-system permissions "look ok-ish".
I found out two weeks ago that the fstrim service was no longer working because of systemd 'protecting' access to the filesystem after several systems with SSD root filesystems were slow as molasses on writes, occasionally blocking for minutes (boo#1181352).
Yes, it was wrong to use ProtectHome= and ProtectSystem= in this particular service unit.
I'd like compare it to current use of standard firewalling rules. There is a base configuration which works for most users but there might be special cases. And anyone seriously configuring custom network setup is up to implement custom firewall rules.
In that case, one can look at logs or hit counters for firewall rules to see what is going on. Is there something similar for systemd? I'd love to know.
Unfortunately there's no specific logging because things are e.g. blocked by read-only bind-mounts.
Even worse in case of over-blocking SystemCallFilter= the process just dies.
So, yes. It's much work to test all this in advance.
Ciao, Michael.
-
Arjen de Korte -
Axel Braun -
Bernhard M. Wiedemann -
Carlos E. R. -
Dirk Müller -
Eric Schirra -
Frederic Crozat -
Ludwig Nussel -
Marcus Meissner -
Matwey V. Kornilov -
Michael Ströder -
Patrick Shanahan -
Stefan Seyfried -
Thorsten Kukuk