selinux-policies auf den letzten funktionierenden Stand bringen

Wie Ihr ( und .tux. )  im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉

Fedora und die Repostrukturen

Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.

Immer wieder Koji

Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1076199

Dort holen wir uns die nötigen RPMs für die lokale Installation:

https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-targeted-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-devel-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-doc-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-3.13.1-283.34.fc27.noarch.rpm

Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.

Manuelles DNF Update

Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:

[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete

Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8 
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8 
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8 
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8

Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27

Fertig.

Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :

# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=selinux-pol*

Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.

Ob das so clever war, die automatischen Tests zu umgehen?

Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.

Wissen eigentlich alle was diese Policies so machen ?

mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:

„SELinux Base package for SELinux Reference Policy – modular.
Based off of reference policy: Checked out revision 2.20091117“

Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:

/usr/share/selinux/targeted/default/active/modules/100/gnome/cil

Wenn man sich das jetzt mit less ansieht, sieht man nichts, da es bzip2 komprimiert ist. Daher brauchen wir jetzt das hier:

bzless /usr/share/selinux/targeted/default/active/modules/100/gnome/cil

u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:

(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse)

(filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0))))
(filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0))))
(filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0))))
(filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0))))
(filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0))))
(filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0))))
(filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0))))
(filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0))))
(filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0))))
(filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))

und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.

Ich hab versucht da  durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.

Fedora – GDM stürzt wegen SELinux ab

Ein schlecht ausgerolltes Update der SELinux Policies unter Fedora 27 führt dazu, daß der Loginbildschirm, im Fachjargon „Greeter“ genannt, mit einer unschönen Meldung absemmelt.

Fehleranalyse

Betroffene Version:  sellinux-policy 3.13.1-283.35

Wenn Eurer GDM Greeter also mit dem „blah blah ‚Benutzer abmelden'“ Fehler stehen bleibt, dann prüft folgendes:

1. „STRG+F2“ damit Ihr eine Root Konsole bekommt

2. „grep gdm /var/log/messages oderjournalctl -xe | grep gdm

kommt dabei das hier raus:

Jul 8 01:40:51 eve systemd[1627]: selinux: avc: denied { status } for auid=n/a uid=42 gid=42 cmdline=“/usr/libexec/gdm-x-session gnome-session –autostart /usr/share/gdm/greeter/autostart“ scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0

dann hilft Euch das hier weiter, falls keine neuere Version im Repository verfügbar ist (also vorher mit dnf -y update checken) :

dnf -y downgrade selinux-policy*
systemctl restart gdm

und anschließend das erneute Update mit dem Eintrag „exclude=selinux-p*“ in die /etc/dnf/dnf.conf verhindern.

Fazit

So eine Scheiße will einem um 1.10 Uhr nachts wirklich nicht passieren!

Probleme mit SELinux reparieren

SELinux mal wieder mal um die Ohren geflogen? Vielleicht kann dieser Artikel helfen.

Es war einmal eine neue SSD …

Vor einigen Tagen habe ich meine Systemfestplatte durch eine SSD ersetzt. Da die ganze Platte verschlüsselt war, folgte ein ziemlich aufwändiger Prozess um die Inhalte zu kopieren. Dabei wurde SELinux allerdings vergessen, was dazu geführt hat, daß Linux danach nicht mehr ganz störungsfrei lief.

Alles in allem häuften sich Meldungen wie diese :

Mar 22 23:10:48 eve python: SELinux is preventing /usr/lib64/firefox/plugin-container from open access on the file .

Da stellt sich einem Admin erstmal die Frage, welches File er da nicht öffnen konnte und wieso nicht. Leider bleibt diese Frage unbeantwortet, da das Audit von SELinux dazu schweigt. Dummerweise weiss man nicht welche Datei gemeint ist und was falsch sein könnte. Solange mein Bugreport nicht zu einer Änderung führt, werden wir das auch nie erfahren, da nicht mal strace herausfindet, welche Datei gemeint ist.

Wie Anfangs schon erwäht, wurden Daten von einer Platte auf eine andere kopiert und letztlich war das das Problem.

Was macht SELinux ?

SELinux (ab jetzt nur SEL ) kennt für fast jede Datei einen Zugriffscontext, fcontext genannt. Mit einem ls sieht man diesen Context nicht gleich, dazu muß man die -Z Option benutzen :

# ls -lad /home/
drwxr-xr-x. 4 root root 4096 20. Mär 07:03 /home/

# ls -ladZ /home/
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /home/

Das Verzeichnis /home/ hat also als Defaultcontext „home_root_t“ ( die enden fast alle auf _t, nicht fragen ). Alle Dateien in /home/ bekommen auch erstmal diesen Context. Programm die in einem Context gestartet wurden, können erstmal nicht auf Dateien in einem anderen Context zugreifen. Das verhindert, daß man durch den Hack z.b. des Apache Webservers auf systemrelevante Dateien zugreifen kann, auch wenn man durch den Hack Rootuser geworden ist. An sich eine Supersache was Security angeht.

Damit das klappt gibt es unter „/etc/selinux/targeted/contexts/files“ eine Liste mit Contexten, die Dateien zugeordnet sind. Wenn man jetzt TAR benutzt um den Inhalt einer Platte von A-> B zu kopieren, geht der Context verloren, aber SELinux findet beim Start seine Configdateien und handelt danach.

Jetzt wurden aus Platzgründen auf der SSD diese Dateien beim Kopieren beschädigt, weswegen der Rechner überhaupt gebootet hat, weil damit der Regelsatz gelöscht war. Da aber andere Dateien mit Contexten versehen wurden, was automatisch beim Anlegen einer Datei passiert (z.b. mit cp a b/) , gab es einige Contexte und andere nicht. Besonders das Home-Verzeichnis strotzt nur so vor Contexten.

Jede Fehlermeldung von SELinux wird dem User präsentiert. Dazu poppt auf dem Desktop eine Warnung auf. In dieser Warnung steht auch, was man dem System zu sagen hat, damit es diesen Zugriff zuläßt. Diese Ausnahmen muß es geben, damit Programme über verschiedene Contexte hinweg Daten austauschen können, z.b. Dateien per SSH ins Webverzeichnis spielen, per Samba Dateien kopieren usw.

Heute morgen hat das Chaos dann komplett zugeschlagen. Systemd konnte nicht mehr booten, da erneut SEL-rechte geändert wurden. Das führte zum komischsten Bootbug bisher. „failure to access /dev/initctl“, wo Systemd auf den „initctl“ Socket nicht mehr zugreifen konnte, also auf den eigentlichen Initprozess.

Wie man es behebt

In meinem Fall habe ich von der „alten“ Platte gebootet und systemd neu installiert, damit waren die komischen Bootprobleme behoben, aber die Gnomeshell startete trotzdem nicht. Was im Einzelnen nicht lief, lies sich nicht feststellen, damit man nicht mal mehr im Debugmodus ins System kam.

Abhilfe schaffte das Abschalten von SEL in /etc/selinux/config :

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing – SELinux security policy is enforced.
#     permissive – SELinux prints warnings instead of enforcing.
#     disabled – No SELinux policy is loaded.
SELINUX=permissive
#SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Der Permissive Modus ist eine Art Debugmode, SEL meckert zwar über die Sicherheitsprobleme, verhindert Sie aber nicht. Damit kann das System wieder booten und man kann die SEL Einstellungen und Probleme reparieren.

Ursachenbeseitigung

Wie sich nach nun umfassender Analyse der SEL Konfigurationen gezeigt hat, war der Policyordner defekt. Dateien mit 0 Bytegröße waren die Regel ( weil die Platte zwischenzeitlich voll war ) .

Das Verzeichnis /etc/selinux/targeted stellt den Regelsatz dar, den SEL befolgen soll, so stehts in der config (siehe oben). Diesen Ordner löscht man und ersetzt ihn anschliessend mit einer alten Kopie. In meinem Fall, von der alten Festplatte. Die Verzeichnisstruktur hat sich nicht geändert, also paßt der Regelsatz, da er „Laufwerke“ nicht beachtet, sondern nur „Pfade“ enthält. Der Name des Bootdevices spielt also keine Rolle.

Nun gibt man noch ein :

# restorecond -R -v /*

Das dauert eine Weile, weil alle Files auf der Platte auf den im Regelsatz enthaltenen Wert zurück gesetzt werden. Mit einer SSD ist man in Minuten durch, mit einer SATA dauert es eine halbe Ewigkeit. Vor den vielen Ausgaben nicht erschrecken, es werden fast alle Dateien auf der Platte gerichtet!

Nun stellt man noch SEL in der /etc/selinux/config auf enforcing um :

# SELINUX=permissive
SELINUX=enforcing

Nun kann man rebooten und der Rechner läuft wieder.

Kleiner Tip an die Gemeinde: Kauft gleich eine TB große SSD, wenn Ihr Videos auf der Platte habt. Spart euch das Linken auf die alte Platte, damit spart Ihr euch eine Menge zusätzlichen Ärgers. Das Musik-  und Videos-Verzeichnis hat genauso Contexte wie alles andere und die müssen passen.

So habe ich das gemacht :

# ls -ladZ /home/marius/Videos
lrwxrwxrwx. marius marius unconfined_u:object_r:user_home_t:s0 /home/marius/Videos -> /sata_home/marius/Videos

]$ ls -ladZ /sata_home /sata_home/marius/
drwxr-xr-x. root root system_u:object_r:user_home_dir_t:s0 /sata_home/
drwx——. marius marius unconfined_u:object_r:user_home_dir_t:s0 /sata_home/marius/

In der /etc/fstab dann noch :

/dev/mapper/luks-53246778-9093-123d-235b-4f35522234211 /sata_home ext4 defaults,x-systemd.device-timeout=0 1 2

Eingetragen um die alte Home Partition als /sata_home zu mounten. Da die Passwörter für die Platten gleich sind ( beim Einrichten & Partitionieren der neuen Platte einfach so eintippen ) , wird diese Lukspartition auch automatisch beim Booten entschlüsselt und kann dann gemountet werden.

 

 

Sambafreigaben unter Fedora 20 managen

Fedora kommt standardmäßig mit einem Medienfreigabecenter daher. Leider handelt es sich dabei nicht um Freigaben wie man Sie von Windows kennt, sondern um DLNA Zugänge für mobile und nicht ganz so mobile Endgeräte bereitzustellen. Es ist nicht leicht zu erkennen, was man da eigentlich freigibt und nutzen tut es oft auch nichts, wenn man mit Windowsrechnern Daten austauschen möchte.

Zum Glück gibt es eine einfach Lösung dafür : Samba.

Folgende Paket müssen dazu installiert sein:

samba-common-4.1.6-1.fc20.i686
samba-client-4.1.6-1.fc20.i686
samba-4.1.6-1.fc20.i686
samba-vfs-glusterfs-4.1.6-1.fc20.i686

und

system-config-samba-1.2.100-2.fc20.noarch

Letzteres Paket gibt uns den im Fedora 20 verloren gegangenen Sambakonfigurator für die Oberfläche zurück:

 

Samba-Config

Damit kann man wirklich problemlos alle Freigaben managen. Aktivieren wir zunächst Samba. Dazu als Root eingeben:

systemctl enable smb
systemctl start  smb

Hat man das gemacht, wird man leider feststellen, daß die Freigaben nicht funktionieren 🙁 Die Ursache ist SELINUX, daß den Zugriff von Samba auf die Verzeichnisse verhindert.

Der schnellste Weg: als Root „setenforce 0“ eingeben. Damit ist SELINUX erstmal im Überredungsmodus, d.h. es meckert zwar, aber es klappt. Die Freigabe kann man nun von außen aufrufen. Das muß man auch tun, damit nun die nötigen Meldungen im SELinux produziert werden. Danach muß nur noch den Fehlermeldungen vom SEL-Control folgen, und die nötigen Änderungen an der SEL-Configuration vornehmen.

setsebool -P samba_share_fusefs 1
setsebool -P samba_export_all_ro 1
setsebool -P samba_export_all_rw 1
grep smbd /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp

Jetzt wieder SEL aktivieren : „setenforce 1“ . Das wars. Samba kann jetzt die Freigaben benutzen und das einem regen Datenaustausch steht nichts mehr im Weg.

Kleiner Tip für Android: Mit dem ES Datei Explorer und MX-Player, kann man alle Videos von der heimischen Platte ohne Probleme auf dem Handy oder Tablet als Stream sehen, dank Samba.