Systemd/Hardening: Difference between revisions

(8 intermediate revisions by 5 users not shown)

Line 1:

Systemd's service options are quite lax by default, and so it is often desirable to look at ways to harden systemd services.

</translate>

A good way to get started on a given service is to look at the output of the command <code>systemd-analyze security myService</code>. From there, you can look at the documentation for the options you see in the output, often in <code>man systemd.exec</code> or <code>man systemd.resource-control</code>, and set the appropriate options for your service.

</translate>

== Accessing the network with a different RootDirectory ==

== Accessing the network with a different RootDirectory ==

</translate>

To be able to access the network while having a RootDirectory specified, you need to give access to <code>/etc/ssl</code>, <code>/etc/static/ssl</code> and <code>/etc/resolv.conf</code>. The simplest way of doing this is by simply putting <code>/etc</code> in the <code>BindReadOnlyPaths</code> option.

</translate>

A more granular way, would be to put these 3 paths into <code>BindReadOnlyPaths</code>, and wait for the creation of <code>/etc/resolv.conf</code> through a <code>systemd.path</code> unit.

</translate>

== Dropping a shell inside a systemd service ==

== Dropping a shell inside a systemd service ==

While hardening a service, it often happens that you want a shell inside a hardened systemd unit, for ~~exemple~~ to check access to files, or check the network connectivity. One way to do this is to use tmux to create a session inside the service, and attaching to it outside of the service.

</translate>

While hardening a service, it often happens that you want a shell inside a hardened systemd unit, for example to check access to files, or check the network connectivity. One way to do this is to use tmux to create a session inside the service, and attaching to it outside of the service.

</translate>

Simple example:

</translate>

Line 30:

Line 46:

}

</syntaxhighlight>

Example with a <code>RootDirectory</code> specified:

</translate>

{ pkgs }:

Line 42:

Line 61:

Type = "forking";

# Used as root directory

# Used as root directory

RuntimeDirectory = "myService";

RootDirectory = "/run/myService";

BindReadOnlyPaths = [

BindReadOnlyPaths = [

"/nix/store"

# So tmux uses /bin/sh as shell

# So tmux uses /bin/sh as shell

"/bin"

];

# This sets up a private /dev/tty

# This sets up a private /dev/tty

# The tmux server would crash without this

# since there would be nothing in /dev

Line 61:

Line 84:

}

</syntaxhighlight>

</translate>

To attach to the shell, simply execute <code>tmux -S /path/to/tmux.socket attach</code>.

</translate>

== Hardening examples ==

== Hardening examples ==

</translate>

This list contains proposed hardening options that are not yet upstreamed. Please use with caution, and please notify the author of the change if something breaks:

</translate>

* Chrony: https://github.com/NixOS/nixpkgs/pull/104944/files

* Galène: https://github.com/NixOS/nixpkgs/pull/156163/files

* Isso: https://github.com/NixOS/nixpkgs/pull/140840/files

* Libreddit: https://github.com/NixOS/nixpkgs/pull/133771/files

* Mautrix-based bridge: https://github.com/mautrix/docs/pull/18/files

* Postfix: https://github.com/NixOS/nixpkgs/pull/93305/files

* TheLounge: https://github.com/thelounge/thelounge-deb/pull/78

</translate>

== Related links ==

</translate>

* SHH, systemd hardening helper: [https://www.synacktiv.com/en/publications/systemd-hardening-made-easy-with-shh systemd hardening made easy with SHH]

</translate>

[[Category:NixOS]]

[[Category:Cookbook]]

[[Category:Security]]

[[Category:systemd]]

@@ Line 1: / Line 1: @@
+{{Systemd/breadcrumb}}
+<translate>
+<!--T:1-->
 Systemd's service options are quite lax by default, and so it is often desirable to look at ways to harden systemd services.
+</translate>
+<translate>
+<!--T:2-->
 A good way to get started on a given service is to look at the output of the command <code>systemd-analyze security myService</code>. From there, you can look at the documentation for the options you see in the output, often in <code>man systemd.exec</code> or <code>man systemd.resource-control</code>, and set the appropriate options for your service.
+</translate>
-== Accessing the network with a different RootDirectory ==
+<translate>
+== Accessing the network with a different RootDirectory == <!--T:3-->
+</translate>
+<translate>
+<!--T:4-->
 To be able to access the network while having a RootDirectory specified, you need to give access to <code>/etc/ssl</code>, <code>/etc/static/ssl</code> and <code>/etc/resolv.conf</code>. The simplest way of doing this is by simply putting <code>/etc</code> in the <code>BindReadOnlyPaths</code> option.
+</translate>
+<translate>
+<!--T:5-->
 A more granular way, would be to put these 3 paths into <code>BindReadOnlyPaths</code>, and wait for the creation of <code>/etc/resolv.conf</code> through a <code>systemd.path</code> unit.
+</translate>
-== Dropping a shell inside a systemd service ==
+<translate>
+== Dropping a shell inside a systemd service == <!--T:6-->
-While hardening a service, it often happens that you want a shell inside a hardened systemd unit, for exemple to check access to files, or check the network connectivity. One way to do this is to use tmux to create a session inside the service, and attaching to it outside of the service.
+</translate>
+<translate>
+<!--T:7-->
+While hardening a service, it often happens that you want a shell inside a hardened systemd unit, for example to check access to files, or check the network connectivity. One way to do this is to use tmux to create a session inside the service, and attaching to it outside of the service.
+</translate>
+<translate>
+<!--T:8-->
 Simple example:
+</translate>
 <syntaxhighlight lang="nix">
@@ Line 30: / Line 46: @@
 }
 </syntaxhighlight>
+<translate>
+<!--T:9-->
 Example with a <code>RootDirectory</code> specified:
+</translate>
+<translate>
+<!--T:10-->
 <syntaxhighlight lang="nix">
 { pkgs }:
@@ Line 42: / Line 61: @@
        Type = "forking";
-       # Used as root directory
+       <!--T:11-->
+# Used as root directory
        RuntimeDirectory = "myService";
        RootDirectory = "/run/myService";
-       BindReadOnlyPaths = [
+       <!--T:12-->
+BindReadOnlyPaths = [
          "/nix/store"
-         # So tmux uses /bin/sh as shell
+         <!--T:13-->
+# So tmux uses /bin/sh as shell
          "/bin"
        ];
-       # This sets up a private /dev/tty
+       <!--T:14-->
+# This sets up a private /dev/tty
        # The tmux server would crash without this
        # since there would be nothing in /dev
@@ Line 61: / Line 84: @@
 }
 </syntaxhighlight>
+</translate>
+<translate>
+<!--T:15-->
 To attach to the shell, simply execute <code>tmux -S /path/to/tmux.socket attach</code>.
+</translate>
-== Hardening examples ==
+<translate>
+== Hardening examples == <!--T:16-->
+</translate>
+<translate>
+<!--T:17-->
 This list contains proposed hardening options that are not yet upstreamed. Please use with caution, and please notify the author of the change if something breaks:
+</translate>
+<translate>
+<!--T:18-->
 * Chrony: https://github.com/NixOS/nixpkgs/pull/104944/files
-* Galène: https://github.com/NixOS/nixpkgs/pull/156163/files
 * Isso: https://github.com/NixOS/nixpkgs/pull/140840/files
-* Libreddit: https://github.com/NixOS/nixpkgs/pull/133771/files
 * Mautrix-based bridge: https://github.com/mautrix/docs/pull/18/files
 * Postfix: https://github.com/NixOS/nixpkgs/pull/93305/files
+* TheLounge: https://github.com/thelounge/thelounge-deb/pull/78
+</translate>
+<translate>
+== Related links == <!--T:19-->
+</translate>
+<translate>
+<!--T:20-->
+* SHH, systemd hardening helper:  [https://www.synacktiv.com/en/publications/systemd-hardening-made-easy-with-shh systemd hardening made easy with SHH]
+</translate>
 [[Category:NixOS]]
 [[Category:Cookbook]]
 [[Category:Security]]
+[[Category:systemd]]