systemd Security Hardening

[Christian Garbs]

Mahlzeit!

systemd hat ja einen Haufen Optionen, um Dienst wegzusperren und
ungewünschten Zugriff auf das System zu erschweren. Das ganze ist
auch schön übersichtlich dargestellt und halbwegs einfach editierbar,
z.B. so:

# systemd-analyze security
# systemd-analyze security getty@
# systemctl edit getty@


Ich will mir das mal genauer angucken und die Dienste etwas zunageln
und habe dazu zwei Fragen:

1) Gibt es eine sinnvolle Möglichkeit, die Konfiguration über mehrere
Systeme synchron zu halten? Wenn ich dem getty@ auf System A das
Schreibrecht auf /proc entziehe, dann möchte ich das auf System B
genauso haben.
Geht das schöner, als $(find /etc/systemd/system/ -name override.conf)
durch die Gegen zu kopieren?


2) Ich bin doch bestimmt nicht der erste auf der Welt (oder konkreter:
unter Debian Buster), der sich für getty@.service, ntp.service oder
uptimed.service sinnvolle Beschränkungen ausdenkt.
Gibt es irgendwo schlaue Listen mit erprobten eingeschränkten
Konfigurationen?
Oder freuen sich die Debian-Maintainer auf viele Vorschläge von
Beschränkungen, um sie ins nächste Release zu packen?
Oder geht genau das nicht, weil immer irgendwer einen Grund hat,
warum nun genau die Einstellung XY auf genau seinem System aber
doch nicht gesetzt werden darf?


Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Q: Why don't jokes work in octal?
A: Because 7 10 11.

[Sven Hartge]

Christian Garbs <mi...@cgarbs.de> wrote:

> 1) Gibt es eine sinnvolle Möglichkeit, die Konfiguration über mehrere
> Systeme synchron zu halten? Wenn ich dem getty@ auf System A das
> Schreibrecht auf /proc entziehe, dann möchte ich das auf System B
> genauso haben.
> Geht das schöner, als $(find /etc/systemd/system/ -name override.conf)
> durch die Gegen zu kopieren?

Nicht wirklich. Die üblichen Verdächtigen aus der Gruppe von ansible,
chef, salt, puppet, etc. halt.

> 2) Ich bin doch bestimmt nicht der erste auf der Welt (oder konkreter:
> unter Debian Buster), der sich für getty@.service, ntp.service oder
> uptimed.service sinnvolle Beschränkungen ausdenkt.
> Gibt es irgendwo schlaue Listen mit erprobten eingeschränkten
> Konfigurationen?

Wenn du eine findest: Bitte teile diese Informationen mit der Welt.
Oftmals ist es nützlich sich die Einstellungen bei anderen
Distributionen anzusehen und zu überlegen, ob diese anwendbar sind.

Das ist ja einer der Vorteile von systemd, dass die Vergleichbarkeit
über die Grenzen von Distributionen besser ist wie vorher.

> Oder freuen sich die Debian-Maintainer auf viele Vorschläge von
> Beschränkungen, um sie ins nächste Release zu packen?

Das ist immer der Fall.

> Oder geht genau das nicht, weil immer irgendwer einen Grund hat,
> warum nun genau die Einstellung XY auf genau seinem System aber
> doch nicht gesetzt werden darf?

Das ist natürlich auch oft der Fall. Aber zumindest als Beispiel in
die Dokumentation kann so etwas immer einfließen.

S°

--
Sigmentation fault. Core dumped.

[Christian Garbs]

Mahlzeit!

Thomas Noll <-_tn...@web.de> wrote:

> Am Mon, 30 Aug 2021 20:59:31 -0000 (UTC) schrieb Christian Garbs:

>> 2) Ich bin doch bestimmt nicht der erste auf der Welt (oder konkreter:
>> unter Debian Buster), der sich für getty@.service, ntp.service oder
>> uptimed.service sinnvolle Beschränkungen ausdenkt.
>

> Es könnte aber sein, daß du der letzte bist ;)
> Ich würde in Buster diesbezüglich keine Arbeit mehr stecken,
> sondern erst auf Bullseye wechseln.

Fipptehler, ich meine natürlich Bullseye.
Du Eaglyeye :)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Matter cannot be created or destroyed,
nor can it be returned without a receipt.