Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opendkim.service: harden systemd service #154

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

Tachi107
Copy link

The current opendkim.service file is not hardened, and systemd-analyze security opendkim.service reports an "UNSAFE" exposure level of 9.6.

With the help of that tool I've applied some more security hardenings to the unit file, and the exposure level dropped to an amazing 1.1!

Some of the most notable changes include:

  • Setting ProtectSystem= to strict, so that the entire file system is mounted read-only; users can allow-list writable paths by overriding the config with systemctl edit opendkim.service, but it shouldn't be needed. OpenDKIM doesn't modify files at all, and only creates a unix socket at startup, usually in /run/opendkim/opendkim.socket or /var/spool/postfix/opendkim/opendkim.socket. Both paths are allowed by default.

  • Denying execution of system binaries with NoExecPaths=/, and only allowing the opendkim binary itself with ExecPaths=/usr/sbin/opendkim, so that if an attacker is able to gain access to OpenDKIM they won't be able to do much, if anything, as spawing shells, listing files, etc won't be allowed, making RCE vulnerabilities much harder to exploit.

  • Making home directories inaccessible with ProtectHome=true

  • Hiding all the users of the system, with PrivateUsers=true

  • Restricting the kind of permitted system calls with SystemCallFilter=@system-service and SystemCallFilter=~ @privileged @resources

Ported from https://salsa.debian.org/debian/opendkim/-/merge_requests/3

Related to #146

The current opendkim.service file is not hardened, and
`systemd-analyze security opendkim.service` reports an
"UNSAFE" exposure level of 9.6.

With the help of that tool I've applied some more security hardenings
to the unit file, and the exposure level dropped to an amazing 1.1!

Some of the most notable changes include:

- Setting ProtectSystem= to strict, so that the entire file system is
  mounted read-only; users can allow-list writable paths by overriding
  the config with `systemctl edit opendkim.service`, but it shouldn't
  be needed. OpenDKIM doesn't modify files at all, and only creates a
  unix socket at startup, usually in /run/opendkim/opendkim.socket or
  /var/spool/postfix/opendkim/opendkim.socket. Both paths are allowed
  by default.

- Denying execution of system binaries with NoExecPaths=/, and only
  allowing the opendkim binary itself with
  ExecPaths=/usr/sbin/opendkim, so that if an attacker is able to gain
  access to OpenDKIM they won't be able to do much, if anything, as
  spawing shells, listing files, etc won't be allowed, making RCE
  vulnerabilities much harder to exploit.

- Making home directories inaccessible with ProtectHome=true

- Hiding all the users of the system, with PrivateUsers=true

- Restricting the kind of permitted system calls with
  SystemCallFilter=@System-service and
  SystemCallFilter=~ @PRIVILEGED @resources
@Tachi107
Copy link
Author

@mdomsch how does this look to you?

@mdomsch
Copy link

mdomsch commented Oct 19, 2022

I missed this while I was in process of moving this summer. The ExecPaths may need to also include /usr/sbin/sendmail and /bin/sh as OpenDKIM can popen() sendmail to send success/failure reports to the standardized reporting addresses. I've been working with the Fedora SELinux team to add a SELinux policy which allows opendkim to invoke sendmail. Any Systemd restrictive wrappers needs to allow this as well.

@mdomsch
Copy link

mdomsch commented Oct 19, 2022

I should note, which mail submission tool to use is configurable in opendkim.conf. By default it's sendmail. The SELinux policy will allow sendmail, exim, postfix, and courier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants