Paketbau/Sicherheitsrichtlinien

aus openSUSE, der freien Wissensdatenbank

Sicherheitsrichtlinien für openSUSE-Pakete

Um unangenehme Überraschungen zu vermeiden, müssen Pakete für openSUSE bestimmte Sicherheitsrichtlinien befolgen. Ausnahmen von den allgemeinen Sicherheitsrichtlinien müssen erst mit dem SUSE-Sicherheitsteam diskutiert und von diesem genehmigt werden.

Daemons

• Paketinstallationen müssen keinen Daemon aktivieren. Das heißt beispielsweise, dass init-Skripte in %post nicht insserv'ed (aktiviert) werden müssen, xinetd-Dateien müssen 'disable = yes' enthalten.
• Daemons sollten unter einer unprivilegierten Nutzer-ID laufen. Das heißt normalerweise, dass das Paket den Nutzer in seinem %pre-Abschnitt erstellen muss. Es sollte vermieden werden, Daemons als root auszuführen und sie müssen nicht den Nutzer 'nobody' verwenden. Trotzdem ist es gut, die Gruppe 'nogroup' zu nutzen.
• Daemons sollten nach der Aktualisierung des Pakets neu gestartet werden, damit Sicherheitsaktualisierungen sofort wirksam werden.
• Daemons, die tcp- oder upd-Ports öffnen oder anderweitig Eingaben aus potentiell vertrauensunwürdigen Netzwerken erhalten, sollten Tests des Sicherheitsteams durchlaufen, bevor sie in die Distribution aufgenommen werden.

Setuid-Binärdateien

Paketen ist es nicht erlaubt, setuid/setgid-Binärdateien zu enthalten, so lange das Sicherheitsteam nicht den Quellcode überprüft und eine ausdrückliche Genehmigung erteilt hat. Um einen Audit für eine setuid-Binärdatei zu veranlassen, sollte ein Fehlerbericht für das Sicherheitsteam geöffnet werden. Der Fehlerbericht sollte den exakten Speicherort des Quellcodes, die betroffenen Dateien und eine Erklärung enthalten, warum das setuid-bit benötigt wird. Wenn der Audit positiv verläuft, fügt das Sicherheitsteam die Zugriffseinstellungen für die neuen Dateien dem Paket 'permissions' hinzu. Das Bausystem wird Pakete mit setuid-Binärdateien ablehnen, die nicht im Paket permissions aufgeführt sind.

setuid-Binärdateien müssen besonders gepackt werden. Schauen Sie sich das Makro %verify_permissions für ein Beispiel an.

World-Writable-Verzeichnisse

Im Allgemeinen sollten von allen beschreibbare Verzeichnisse vermieden werden. Falls ein Paket unbedingt für alle beschreibbare Verzeichnisse benötigt, gelten die selben Regeln wie für setuid-Binärdateien.

Group-Writable-Verzeichnisse

Es gibt keine Bauprüfungen für Verzeichnisse, die von einer bestimmten Gruppe beschreibbar sind und es bedarf keiner Prüfung durch das Sicherheitsteam. Trotzdem sollten sich Paketbauer darüber im Klaren sein, dass sich Verzeichnisse unterhalb von durch Gruppen beschreibbaren Verzeichnissen nicht sicher packen lassen und es Gruppenmitgliedern erlauben könnten, ihre Rechte bis auf root-Rechte auszuweiten. In anderen Worten, packen Sie niemals Verzeichnisse innerhalb von durch Gruppen beschreibbaren Verzeichnissen.

Firewall-Einstellungen

Es ist keinem Paket erlaubt, die Konfigurationsdatei von SuSEfirewall zu verändern. Eine Ausnahme besteht für das Firewall-Modul von YaST2. Jede andere Anwendung muss die Schnittstelle nutzen, die vom YaST2-Modul Firewall zum Ändern der Firewall-Einstellungen angeboten wird. Das ändern der Firewall-Einstellungen muss immer die explizite Erlaubnis des Nutzers erhalten.

DBus-Dienste

Programme, die Dienste über den System-DBus anbieten, müssen ein Audit des Sicherheitsteams durchlaufen, bevor sie in die Distribution aufgenommen werden. Grundsätzlich gelten die gleichen Regeln wie für jeden anderen Daemon.

PolicyKit-Privilegien

Programme, die im Namen des Nutzers privilegierte Operationen durchführen (wie bspw. das Ändern der Uhrzeit), sollten ein PolicyKit-Privilegie definieren, die ein Nutzer besitzen muss, um eine bestimmte Aktion durchzuführen. Die Nutzung von PolicyKit-Privilegien muss die Prüfung des Sicherheitsteams durchlaufen, bevor sie in die Distribution aufgenommen werden kann.

Passwörter

Pakete sollten nicht mit festen Passwörtern, Zertifikaten usw. vorkonfiguriert werden. Statt dessen sollte der Nutzer vor der ersten Nutzung dazu angehalten werden, ein Passwort festzulegen.

Nutzung von Kryptographie

Grundsätzlich sollten Pakete nicht ihre eigene Kryptographie implementieren, sondern eine der folgenden Implementierungen nutzen:

• mozilla-nss (bevorzugt)
• openssl
• gcrypt
• gnutls
• kernel-crypto-Schnittstelle (nur Kernel-Module)

Die bevorzugten Verschlüsselungs- und Hash-Algorithmen sollten konfigurierbar sein und auf die aktuell als sicher geltenden Algorithmen gesetzt werden (bspw. aes, sha1). Die Nutzung von MD5 als kryptographische Signatur ist nicht mehr sicher.

Pakete sollten nicht ihren eigenen Satz vertrauenswürdiger x509-Zertifikate mitbringen. Statt dessen sollte /etc/ssl/certs als Rückfallsicherung genutzt werden.