[ryandotsmith]

Are there common patterns or examples of directives that operators should be aware of?

I know the post linked to systemd docs, but I’d enjoy seeing some snippets of directives people are using to achieve this kind of hardening.

[bhaney]

I have a dropin called security.conf that I link in to most of my services, and then create an unsecurity.conf to disable/revert any directives not compatible with the service.

  [Service]
  DynamicUser=yes
  PrivateTmp=true
  PrivateDevices=true
  PrivateNetwork=true
  PrivateUsers=true
  InaccessiblePaths=-/mnt/
  ProtectSystem=strict
  ProtectHome=true
  ProtectHostname=true
  ProtectKernelTunables=true
  ProtectKernelModules=true
  ProtectKernelLogs=true
  ProtectControlGroups=true
  ProtectClock=true
  ProtectProc=invisible
  ProcSubset=pid
  RestrictNamespaces=true
  RestrictRealtime=true
  RestrictSUIDSGID=true
  LockPersonality=true
  NoNewPrivileges=true
  RemoveIPC=true
  IPAddressDeny=any
  UMask=0077
  SystemCallArchitectures=native
  RestrictAddressFamilies=none
  MemoryDenyWriteExecute=true
  SystemCallFilter=~@cpu-emulation @debug @module @mount @obsolete @reboot @swap @raw-io @privileged @resources
  CapabilityBoundingSet=~CAP_SYS_PACCT CAP_KILL CAP_WAKE_ALARM CAP_LINUX_IMMUTABLE CAP_IPC_LOCK CAP_SYS_TTY_CONFIG CAP_SYS_BOOT CAP_SYS_CHROOT CAP_BLOCK_SUSPEND CAP_LEASE CAP_MKNOD CAP_CHOWN CAP_FSETID CAP_SETFCAP CAP_SETUID CAP_SETGID CAP_SETPCAP CAP_SYS_RAWIO CAP_SYS_PTRACE CAP_SYS_NICE CAP_SYS_RESOURCE CAP_NET_ADMIN CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_MAC_OVERRIDE CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_IPC_OWNER CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_AUDIT_WRITE CAP_BPF CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW

MemoryDenyWriteExecute gets set back to "no" quite a lot because interpreters like to use it for JITing, but it prevents a whole class of exploits on services where it can stay enabled.

I also like to socket-activate services as often as possible so they don't need access to network interfaces. Even if a service doesn't support socket-activation itself, it can usually be shimmed in with systemd-socket-proxyd, which also provides good functionality for stopping services when there are no connections to them (they get started again by the next connection).

[temp0826]

So this looks pretty nice but I have to say...

> then create an unsecurity.conf to disable/revert any directives not compatible with the service

I've been using linux for something like 25 years now, and this just sounds like a heck of a lot of grokking and work (and maybe even trial and error?) for the mortals, no? I would think distribution maintainers should be the ones flipping more of these switches, and if they aren't, might that point to them being overly aggressive?

[bhaney]

> this just sounds like a heck of a lot of grokking and work (and maybe even trial and error?) for the mortals, no?

Absolutely. For the record, when I say "my services" I mean services that I'm writing, not any service running on my system. I consider this hardening to be part of development, to be done by the developer responsible for it, whether that's the upstream dev or package maintainer. I would not consider it to be the responsibility of a random end-user and I wouldn't recommend most to try unless they're personally interested in it.

That being said, for developers, these switches make it crazy easy to sandbox your service compared to older solutions. So much so that I actually bother doing it now.