top | item 44928571

(no title)

ryandotsmith | 6 months ago

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.

discuss

order

bhaney|6 months ago

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|6 months ago

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?