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

Apply hardening measures in bitcoind systemd service file #12102

Merged
merged 1 commit into from Mar 14, 2018

Conversation

Flowdalic
Copy link
Contributor

Adds typical systemd hardening measurements for network services.

@TheBlueMatt
Copy link
Contributor

Concept ACK, seems reasonable.

@fanquake
Copy link
Member

Here's documentation for the 4 new options being added, taken from the freedesktop.org docs.

ProtectSystem

Takes a boolean argument or the special values "full" or "strict". If true, mounts the /usr and /boot directories read-only for processes invoked by this unit. If set to "full", the /etc directory is mounted read-only, too. If set to "strict" the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev, /proc and /sys (protect these directories using PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is recommended to enable this setting for all long-running services, unless they are involved with system updates or need to modify the operating system in other ways. If this option is used, ReadWritePaths= may be used to exclude specific directories from being made read-only. This setting is implied if DynamicUser= is set. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see below. Defaults to off.

NoNewPrivileges

Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again. Defaults to false, but certain settings override this and ignore the value of this setting. This is the case when SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, MemoryDenyWriteExecute=, RestrictRealtime=, or LockPersonality= are specified. Note that even if this setting is overridden by them, systemctl show shows the original value of this setting. Also see No New Privileges Flag.

PrivateDevices

Takes a boolean argument. If true, sets up a new /dev mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. This is useful to securely turn off physical device access by the executed process. Defaults to false. Enabling this option will install a system call filter to block low-level I/O system calls that are grouped in the @raw-io set, will also remove CAP_MKNOD and CAP_SYS_RAWIO from the capability bounding set for the unit (see above), and set DevicePolicy=closed (see systemd.resource-control(5) for details). Note that using this setting will disconnect propagation of mounts from the service to the host (propagation in the opposite direction continues to work). This means that this setting may not be used for services which shall be able to install mount points in the main mount namespace. The new /dev will be mounted read-only and 'noexec'. The latter may break old programs which try to set up executable memory by using mmap(2) of /dev/zero instead of using MAP_ANON. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. If turned on and if running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied.

Note that the implementation of this setting might be impossible (for example if mount namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security.

MemoryDenyWriteExecute

Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited. Specifically, a system call filter is added that rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of various C compilers. This option improves service security, as it makes harder for software exploits to change running code dynamically. Note that this feature is fully available on x86-64, and partially on x86. Specifically, the shmat() protection is not available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar. If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied.

@dongcarl
Copy link
Contributor

dongcarl commented Feb 5, 2018

Hi all, I'm working on #12255 which also changes the systemd service file and sets up the pidfile, datadir, and conffile with the right permissions and at the right places. @laanwj told me to coordinate my changes with people here. From what I see things should be compatible except I make the assumption that the service is running as bitcoin:bitcoin, which I think we should be according to init.md right?

@practicalswift
Copy link
Contributor

Concept ACK. Hardening is good!

@laanwj laanwj changed the title Apply hardening measurements in bitcoind systemd service file Apply hardening measures in bitcoind systemd service file Feb 8, 2018
@@ -19,7 +19,26 @@ User=bitcoin
Type=forking
PIDFile=/run/bitcoind/bitcoind.pid
Restart=on-failure

# Hardening measurements
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Hardening measures, not measurements :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this out. Fixed with 8748949.

@laanwj laanwj self-assigned this Feb 8, 2018
@laanwj
Copy link
Member

laanwj commented Mar 13, 2018

ACK after squash

@cdecker
Copy link
Contributor

cdecker commented Mar 13, 2018

ACK 👍

@Flowdalic
Copy link
Contributor Author

Rebased and squashed.

@fanquake
Copy link
Member

utACK 2e86249

# new privileges through execve()
NoNewPrivileges=true

# Use a new /dev namespace only populated with API pseudeo devices
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "pseudo" :-)

NoNewPrivileges=true

# Use a new /dev namespace only populated with API pseudeo devices
# such as /dev/null, /dev/zero or /dev/random
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: "or" should be "and"?

# such as /dev/null, /dev/zero or /dev/random
PrivateDevices=true

# Deny the creation of writeable and executably memory mappings
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "writable" and "executable" :-)

PrivateTmp=true

# Mount /usr, /boot/ and /etc read-only for the process.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Remove trailing "." to get consistency with the remaining comments.

@practicalswift
Copy link
Contributor

practicalswift commented Mar 14, 2018

utACK modulo fixed review feedback above

Adds typical systemd hardening measurements for network services.
@Flowdalic
Copy link
Contributor Author

Incorporated @practicalswift's feedback and squashed. Thanks for the feedback. :)

@fanquake
Copy link
Member

re-utACK 79ddfad

@laanwj laanwj merged commit 79ddfad into bitcoin:master Mar 14, 2018
laanwj added a commit that referenced this pull request Mar 14, 2018
79ddfad Apply hardening measurements in bitcoind systemd service file (Florian Schmaus)

Pull request description:

  Adds typical systemd hardening measurements for network services.

Tree-SHA512: 63e54d5a2e3e625c123c91e4392474226ec26c48709f2627f4d9d257a59f6960dd53ba4faa10cd355a89cad37fe351e2dbe8db79e681645b59081cf83e940438
@Flowdalic Flowdalic deleted the systemd-hardening branch October 4, 2018 07:24
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jun 10, 2020
…vice file

79ddfad Apply hardening measurements in bitcoind systemd service file (Florian Schmaus)

Pull request description:

  Adds typical systemd hardening measurements for network services.

Tree-SHA512: 63e54d5a2e3e625c123c91e4392474226ec26c48709f2627f4d9d257a59f6960dd53ba4faa10cd355a89cad37fe351e2dbe8db79e681645b59081cf83e940438
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jun 13, 2020
…vice file

79ddfad Apply hardening measurements in bitcoind systemd service file (Florian Schmaus)

Pull request description:

  Adds typical systemd hardening measurements for network services.

Tree-SHA512: 63e54d5a2e3e625c123c91e4392474226ec26c48709f2627f4d9d257a59f6960dd53ba4faa10cd355a89cad37fe351e2dbe8db79e681645b59081cf83e940438
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jun 13, 2020
…vice file

79ddfad Apply hardening measurements in bitcoind systemd service file (Florian Schmaus)

Pull request description:

  Adds typical systemd hardening measurements for network services.

Tree-SHA512: 63e54d5a2e3e625c123c91e4392474226ec26c48709f2627f4d9d257a59f6960dd53ba4faa10cd355a89cad37fe351e2dbe8db79e681645b59081cf83e940438
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jun 13, 2020
…vice file

79ddfad Apply hardening measurements in bitcoind systemd service file (Florian Schmaus)

Pull request description:

  Adds typical systemd hardening measurements for network services.

Tree-SHA512: 63e54d5a2e3e625c123c91e4392474226ec26c48709f2627f4d9d257a59f6960dd53ba4faa10cd355a89cad37fe351e2dbe8db79e681645b59081cf83e940438
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jun 17, 2020
…vice file

79ddfad Apply hardening measurements in bitcoind systemd service file (Florian Schmaus)

Pull request description:

  Adds typical systemd hardening measurements for network services.

Tree-SHA512: 63e54d5a2e3e625c123c91e4392474226ec26c48709f2627f4d9d257a59f6960dd53ba4faa10cd355a89cad37fe351e2dbe8db79e681645b59081cf83e940438
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants