systemd.resource-control (original) (raw)

IPAccounting=¶

Takes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for packets sent or received by the unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of the unit are accounted for.

When this option is used in socket units, it applies to all IPv4 and IPv6 sockets associated with it (including both listening and connection sockets where this applies). Note that for socket-activated services, this configuration setting and the accounting data of the service unit and the socket unit are kept separate, and displayed separately. No propagation of the setting and the collected statistics is done, in either direction. Moreover, any traffic sent or received on any of the socket unit's sockets is accounted to the socket unit — and never to the service unit it might have activated, even if the socket is used by it.

The system default for this setting may be controlled with DefaultIPAccounting= insystemd-system.conf(5).

Note that this functionality is currently only available for system services, not for per-user services.

Added in version 235.

IPAddressAllow=_`ADDRESS[/PREFIXLENGTH]…`_, IPAddressDeny=_`ADDRESS[/PREFIXLENGTH]…`_¶

Turn on network traffic filtering for IP packets sent and received overAF_INET and AF_INET6 sockets. Both directives take a space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix length in bits after a "/" character. If the suffix is omitted, the address is considered a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for IPv6).

The access lists configured with this option are applied to all sockets created by processes of this unit (or in the case of socket units, associated with it). The lists are implicitly combined with any lists configured for any of the parent slice units this unit might be a member of. By default both access lists are empty. Both ingress and egress traffic is filtered by these settings. In case of ingress traffic the source IP address is checked against these access lists, in case of egress traffic the destination IP address is checked. The following rules are applied in turn:

• Access is granted when the checked IP address matches an entry in theIPAddressAllow= list.
• Otherwise, access is denied when the checked IP address matches an entry in theIPAddressDeny= list.
• Otherwise, access is granted.

In order to implement an allow-listing IP firewall, it is recommended to use aIPAddressDeny= any setting on an upper-level slice unit (such as the root slice -.slice or the slice containing all system servicessystem.slice – seesystemd.special(7) for details on these slice units), plus individual per-service IPAddressAllow= lines permitting network access to relevant services, and only them.

Note that for socket-activated services, the IP access list configured on the socket unit applies to all sockets associated with it directly, but not to any sockets created by the ultimately activated services for it. Conversely, the IP access list configured for the service is not applied to any sockets passed into the service via socket activation. Thus, it is usually a good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless, it may make sense to maintain one list more open and the other one more restricted, depending on the use case.

If these settings are used multiple times in the same unit the specified lists are combined. If an empty string is assigned to these settings the specific access list is reset and all previous settings undone.

In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic names may be used. The following names are defined:

Table 1. Special address/network names

Note that these settings might not be supported on some systems (for example if eBPF control group support is not enabled in the underlying kernel or container manager). These settings will have no effect in that case. If compatibility with such systems is desired it is hence recommended to not exclusively rely on them for IP security.

This option cannot be bypassed by prefixing "+" to the executable path in the service unit, as it applies to the whole control group.

Added in version 235.

SocketBindAllow=_`bind-rule`_, SocketBindDeny=_`bind-rule`_¶

Configures restrictions on the ability of unit processes to invoke bind(2) on a socket. Both allow and deny rules to be defined that restrict which addresses a socket may be bound to.

bind-rule describes socket properties such as address-family,transport-protocol and ip-ports.

bind-rule := { [address-family:][transport-protocol:][_ip-ports_] | any }

address-family := { ipv4 | ipv6 }

transport-protocol := { tcp | udp }

ip-ports := { ip-port | ip-port-range }

An optional address-family expects ipv4 or ipv6 values. If not specified, a rule will be matched for both IPv4 and IPv6 addresses and applied depending on other socket fields, e.g. transport-protocol,ip-port.

An optional transport-protocol expects tcp or udp transport protocol names. If not specified, a rule will be matched for any transport protocol.

An optional ip-port value must lie within 1…65535 interval inclusively, i.e. dynamic port 0 is not allowed. A range of sequential ports is described by_ip-port-range_ := ip-port-low- ip-port-high, where ip-port-low is smaller than or equal to ip-port-high and both are within 1…65535 inclusively.

A special value any can be used to apply a rule to any address family, transport protocol and any port with a positive value.

To allow multiple rules assign SocketBindAllow= or SocketBindDeny= multiple times. To clear the existing assignments pass an empty SocketBindAllow= or SocketBindDeny= assignment.

For each of SocketBindAllow= and SocketBindDeny=, maximum allowed number of assignments is128.

• Binding to a socket is allowed when a socket address matches an entry in theSocketBindAllow= list.
• Otherwise, binding is denied when the socket address matches an entry in theSocketBindDeny= list.
• Otherwise, binding is allowed.

The feature is implemented with cgroup/bind4 and cgroup/bind6 cgroup-bpf hooks.

Note that these settings apply to any bind(2) system call invocation by the unit processes, regardless in which network namespace they are placed. Or in other words: changing the network namespace is not a suitable mechanism for escaping these restrictions on bind().

Examples:

…

Allow binding IPv6 socket addresses with a port greater than or equal to 10000.

[Service] SocketBindAllow=ipv6:10000-65535 SocketBindDeny=any …

Allow binding IPv4 and IPv6 socket addresses with 1234 and 4321 ports.

[Service] SocketBindAllow=1234 SocketBindAllow=4321 SocketBindDeny=any …

Deny binding IPv6 socket addresses.

[Service] SocketBindDeny=ipv6 …

Deny binding IPv4 and IPv6 socket addresses.

[Service] SocketBindDeny=any …

Allow binding only over TCP

[Service] SocketBindAllow=tcp SocketBindDeny=any …

Allow binding only over IPv6/TCP

[Service] SocketBindAllow=ipv6:tcp SocketBindDeny=any …

Allow binding ports within 10000-65535 range over IPv4/UDP.

[Service] SocketBindAllow=ipv4:udp:10000-65535 SocketBindDeny=any …

This option cannot be bypassed by prefixing "+" to the executable path in the service unit, as it applies to the whole control group.

Added in version 249.

RestrictNetworkInterfaces=¶

Takes a list of space-separated network interface names. This option restricts the network interfaces that processes of this unit can use. By default processes can only use the network interfaces listed (allow-list). If the first character of the rule is "~", the effect is inverted: the processes can only use network interfaces not listed (deny-list).

This option can appear multiple times, in which case the network interface names are merged. If the empty string is assigned the set is reset, all prior assignments will have not effect.

If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take precedence and will dictate the default action (allow vs deny). Then the next occurrences of this option will add or delete the listed network interface names from the set, depending of its type and the default action.

The loopback interface ("lo") is not treated in any special way, you have to configure it explicitly in the unit file.

Example 1: allow-list

RestrictNetworkInterfaces=eth1 RestrictNetworkInterfaces=eth2

Programs in the unit will be only able to use the eth1 and eth2 network interfaces.

Example 2: deny-list

RestrictNetworkInterfaces=~eth1 eth2

Programs in the unit will be able to use any network interface but eth1 and eth2.

Example 3: mixed

RestrictNetworkInterfaces=eth1 eth2 RestrictNetworkInterfaces=~eth1

Programs in the unit will be only able to use the eth2 network interface.

This option cannot be bypassed by prefixing "+" to the executable path in the service unit, as it applies to the whole control group.

Added in version 250.

NFTSet= family:table:set¶

This setting provides a method for integrating dynamic cgroup, user and group IDs into firewall rules with NFT sets. The benefit of using this setting is to be able to use the IDs as selectors in firewall rules easily and this in turn allows more fine grained filtering. NFT rules for cgroup matching use numeric cgroup IDs, which change every time a service is restarted, making them hard to use in systemd environment otherwise. Dynamic and random IDs used by DynamicUser= can be also integrated with this setting.

This option expects a whitespace separated list of NFT set definitions. Each definition consists of a colon-separated tuple of source type (one of "cgroup", "user" or "group"), NFT address family (one of "arp", "bridge", "inet", "ip", "ip6", or "netdev"), table name and set name. The names of tables and sets must conform to lexical restrictions of NFT table names. The type of the element used in the NFT filter must match the type implied by the directive ("cgroup", "user" or "group") as shown in the table below. When a control group or a unit is realized, the corresponding ID will be appended to the NFT sets and it will be be removed when the control group or unit is removed. systemd only inserts elements to (or removes from) the sets, so the related NFT rules, tables and sets must be prepared elsewhere in advance. Failures to manage the sets will be ignored.

Table 2. Defined source type values

If the firewall rules are reinstalled so that the contents of NFT sets are destroyed, commandsystemctl daemon-reload can be used to refill the sets.

Example:

[Unit] NFTSet=cgroup:inet:filter:my_service user:inet:filter:serviceuser

Corresponding NFT rules:

table inet filter { set my_service { type cgroupsv2 } set serviceuser { typeof meta skuid } chain x { socket cgroupv2 level 2 @my_service accept drop } chain y { meta skuid @serviceuser accept drop } }

This option is only available for system services and is not supported for services running in per-user instances of the service manager.

Added in version 255.