openSUSE:Sicherheitsrichtlinien für Pakete

Paketbau

Paketbau Richtlinien - Richtlinien zur Bezeichnung von Paketen - Richtlinien für Spezifikationsdateien - Richtlinien für Patches - Sicherheitsrichtlinien - Richtlinien für Paketgruppen - Paketbau Prüfungen - Kategorien für Desktopmenüs - RPM Makros - Init-Skripte - kleine Skript-Schnipsel - Paketbau Perl - Paketbau-Richtlinie für mehrfach benutzte Bibliotheken - Paketabhängigkeiten - Paketbau von Python-Software - Paketbau Richtlinien für mehrere Versionen

Die Sicherheitsrichtlinien regulieren alle Details zum sicheren Packen der openSUSE Distribution. Um unangenehme Überraschungen zu vermeiden, müssen die Pakete sich an besondere Sicherheitsregeln halten. Ausnahmen von den allgemeinen Sicherheitsbestimmungen müssen mit dem Sicherheits-Team abgestimmt und von ihm genehmigt werden.

Daemons

• Die Installation eines Paketes darf keinen Daemon aktivieren. Das bedeutet zum Beispiel, Init-Skripte dürfen nicht in %post mit dem Shellbefehl insserv aktiviert werden. xinetd-Dateien müssen 'disable = yes' enthalten.
• Deamons sollten unter einer unprivilegierten Benutzer ID laufen. Das bedeutet gewöhnlich, dass das Paket den Benutzer in seinem %pre-Abschnitt erzeugen muss. Daemons sollten es vermeiden als Root zu laufen und dürfen nicht den Benutzer 'nobody' verwenden. Es ist in Ordnung, die Gruppe 'nogroup' zu verwenden.
• Daemons sollten neu gestartet werden, wenn das Paket verbessert wurde, so dass Sicherheitsaktualisierungen unverzüglich greifen.
• Daemons, die TCP- oder UDP-Ports öffnen oder auf andere Weise Eingaben von potentiell nicht vertrauenswürdigen Netzwerken bekommen, sollten ein Audit vom Sicherheitsteam vor der Aufnahme in die Distribution erhalten.

Setuid Binärprogramme

Pakete dürfen keine Setuid/Setgid Binärprogramme enthalten, außer wenn das Sicherheitsteam den Quellcode überprüft und eine ausdrückliche Erlaubnis gegeben hat. Um ein Audit für Setuid-Binärprogramme zu erbitten, sollte ein Bug-Report für das Sicherheitsteam eröffnet werden. Der Fehlerbericht sollte die genaue Position des Quellcodes enthalten, die beeinflussten Dateien und eine Erklärung, warum das Setuid-Bit benötigt wird. Wenn das Audit als positiv bewertet wird, bezieht das Sicherheitsteam die Erlaubniseinstellungen für die neuen Dateien im Paket 'Erlaubnisse' ein. Das Bausystem wird Pakete mit Setuid-Binärprogrammen zurückweisen, die nicht im Paket Erlaubnisse aufgelistet sind.

Grundsätzlich erfordert die Verwendung eines standardmäßigen Setuid-Bits einen guten Grund. Meistens ist es besser, das Paket ohne Setuid-Bits auszuliefern, aber mit Anweisungen, wie /etc/permissions.local zu modifizieren ist, wenn es benötigt wird.

Setuid-Binärprogramme müssen speziell gepackt werden. Siehe zum Beispiel Überprüfung von Erlaubnissen für Makros.

World Writable Directories

Grundsätzlich sollten Verzeichnisse vermieden werden, die allen Systembenutzern Schreibrechte einräumen (world writable directories). Wenn ein Paket unbedingt diese unbegrenzten Schreibrechte benötigt, gelten die selben Regeln wie für Setuid-Binärprogramme.

Verzeichnisse mit Schreibrechten für die Gruppe (Group Writable Directories)

Es gibt keine Prüfung beim Bau für Verzeichnisse, die für einige Gruppen Schreibrechte vergibt. Es wird keine Prüfung vom Sicherheitsteam benötigt. Dennoch sollten Paketbauer sich Paketbauer bewusst sein, dass Verzeichnisse innerhalb von Verzeichnissen mit Schreibrechten für Gruppen nicht sicher gepackt werden können und könnten den Mitgliedern der Gruppe erlauben, ihre Privilegien zu Root anheben könnten. Mit anderen Worten, packen Sie niemals Verzeichnisse im Inneren mit Gruppenschreibrechten für das Verzeichnis.

Einstellungen für die Firewall

Keinem Paket ist es erlaubt, die Konfigurationsdatei für die SUSE-Firewall zu modifizieren. Eine Ausnahme wird dem YaST2-Firewall-Modul gewährt. Jede andere Anwendung muss die Schnittstelle, die vom YaST2-Firwall-Modul angeboten wird verwenden, um die Firewalleinstellungen zu verändern. Die Änderung der Firewalleinstellungen müssen immer die ausdrückliche Bestätigung des Benutzers erfordern.

DBus Services

Programme, die Services über den System-DBUS anbieten, müssen ein Audit vom Sicherheitsteam erhalten vor der Einbindung in die Distribution. Grundsätzlich sind die gleichen Regeln anzuwenden wie für jeden anderen Daemon.

Vorrechte von PolicyKit

Programme, die bevorzugte Operationen im Auftrag des Benutzers (so zum Beispiel Wechsel der Uhr) ausführen, sollte ein PolicyKit-Vorrecht definieren, das ein Benutzer für eine spezielle Aktion besitzen muss, damit sie ausgeführt werden kann. Die Verwendung von PolicyKit-Vorrechten müssen vom Sicherheitsteam vor der Einbindung in die Distribution auditiert werden.

Passwörter

Pakete dürfen nicht mit festen Passwörtern, Zertifikaten usw. vorkonfiguriert werden. Stattdessen muss der Benutzer gezwungen werden, vor der ersten Anwendung ein Passwort einzurichten.

Verwendung von Kryptografie

Grundsätzlich dürfen Pakete keinen eigenen kryptografischen Algorithmus enthalten, sondern sollten einer folgenden Implementierungen verwenden:

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

Bevorzugt sollten Verschlüsselung und Hash-Algorithmen konfiguriert und auf gegenwärtig als sicher betrachtete Algorithmen wie z.B. AES, SHAl, eingerichtet werden. Die Verwendung von MD5 als kryptografische Signatur ist nicht mehr länger sicher.

Pakete sollten nicht ihren eigenen Satz von vertrauenswürdigen X.509 Zertifikaten ausliefern. Stattdessen sollte /etc/ssl/certs als Fallback verwendet werden.