selinux-policies auf den letzten funktionierenden Stand bringen

Posted on 10. Juli 2018 by marius

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.

DNF: gezielt downgraden

Posted on 18. Mai 2016 by marius

Neulich bei Wine : „Es geht mal wieder nicht, aber gestern gings noch.“

In einem anderen Beitrag habe schon einmal auf Downgrades hingewiesen. Wenn man mit DNF/YUM einen Downgrade eines Paketes durchführt, geht das erstmal sehr einfach:

dnf downgrade paketname

Aber leider kann es vorkommen, daß bis auf die Basisversion eines Pakets zurück gegraded wird. Wie kommt das, wo doch lediglich eine kleine Revisionsänderung durchgeführt wurde ?

Ganz einfach: Weil das alte Paket nicht mehr im Update-Repository ist und nur noch die uralte Basisversion im Fedorahauptrepository zu finden ist.

Umgehen kann man das so, aber ein bisschen Arbeit ist es schon:

Einen Webserver einrichten oder idealerweise einen bereits fertigen Webserver auf folgende URL konfigurieren :http://dnf.meinedomain.de/$basearch/$releasever/fedora-old/Was in dem Fall meint, daß das Docroot in dem Pfad rauskommt, wo die BASEARCH, also die Basisarchitektur liegt. siehe Punkt 3 als Beispiel.
folgende Datei anlegen : /etc/yum.repos.d/fedora-downgrade.repo und das reinschreiben:[fedora-old]
name=Fedora $releasever – $basearch – OLD
baseurl=http://dnf.meinedomain.de/$basearch/$releasever/fedora-old/
enabled=1
gpgcheck=0

jetzt von Koji ( koji.fedoraproject.org/koji/ ) das Paket heraussuchen und die nötigen Dateien der Versionen die man gern hätte, in das Verzeichnis seines Apaches kopieren, in dem das Repo erstellt wurde. Das könnte so aussehen : /home/meinusername/repository/x86_64/23/fedora-old/

drwxr-xr-x 3 root root     4096  6. Mär 16:09 .
drwxr-xr-x 4 root root     4096  6. Mär 16:00 ..
drwxr-xr-x 2 root root     4096  6. Mär 16:09 repodata
-rw-r--r-- 1 root root    54078  6. Mär 16:07 wine-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    54390  6. Mär 16:07 wine-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root   106054  6. Mär 16:07 wine-alsa-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root   108178  6. Mär 16:07 wine-alsa-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root   143442  6. Mär 16:07 wine-arial-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    59662  6. Mär 16:07 wine-capi-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    59874  6. Mär 16:07 wine-capi-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root    74474  6. Mär 16:07 wine-cms-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    75418  6. Mär 16:07 wine-cms-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root   108838  6. Mär 16:07 wine-common-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root 22652170  6. Mär 16:08 wine-core-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root 22292142  6. Mär 16:08 wine-core-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root   133074  6. Mär 16:08 wine-courier-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root 38597470  6. Mär 16:08 wine-debuginfo-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root   159390  6. Mär 16:08 wine-desktop-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    84534  6. Mär 16:08 wine-filesystem-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    66710  6. Mär 16:08 wine-fixedsys-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    53654  6. Mär 16:08 wine-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root   115838  6. Mär 16:08 wine-ldap-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root   117914  6. Mär 16:08 wine-ldap-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root    65850  6. Mär 16:08 wine-marlett-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root  1738630  6. Mär 16:09 wine-ms-sans-serif-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    66506  6. Mär 16:09 wine-openal-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    68030  6. Mär 16:09 wine-openal-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root    65110  6. Mär 16:09 wine-opencl-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    66114  6. Mär 16:09 wine-opencl-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root    96042  6. Mär 16:09 wine-pulseaudio-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    96866  6. Mär 16:09 wine-pulseaudio-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root    68910  6. Mär 16:09 wine-small-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    79874  6. Mär 16:09 wine-symbol-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    54238  6. Mär 16:09 wine-systemd-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    72858  6. Mär 16:09 wine-system-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root   160394  6. Mär 16:09 wine-tahoma-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    55270  6. Mär 16:09 wine-tahoma-fonts-system-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root   150314  6. Mär 16:09 wine-times-new-roman-fonts-1.9.3-1.fc23.noarch.rpm
-rw-r--r-- 1 root root    85858  6. Mär 16:09 wine-twain-1.9.3-1.fc23.i686.rpm
-rw-r--r-- 1 root root    87210  6. Mär 16:09 wine-twain-1.9.3-1.fc23.x86_64.rpm
-rw-r--r-- 1 root root    66466  6. Mär 16:09 wine-wingdings-fonts-1.9.3-1.fc23.noarch.rpm

Nun wechselt man in das Verzeichnis und führt den Befehl „createrepo .“ aus. Damit werden die repodata-Files erzeugt, die DNF und YUM brauchen.
Wenn alles geklappt hat, kann man das Repo jetzt mit DNF finden.

Ist das der Fall und man downgraded wine, ist das die nächst neueste Version zu der, die bereits installiert ist und damit downgraded dnf das erst mal im Beispiel auf 1.9.3, bevor es dann mit einem weiteren Downgrade auf die Basisversion 1.7.x geht. Wenn man jetzt mehr als eine Version von Wine in dem OLD Repo hat, kann man sich recht komfortabel von einer Version zur nächsten bewegen und muß nicht erst alles per dnf erase löschen und dann mit rpm -i *rpm die gewünschte Version installieren. Aber nicht vergessen das Paket in der /etc/dnf/dnf.conf zu deaktivieren, sonst kommt das Update abends gleich wieder drauf.

Natürlich kann man in so einem Repo auch eigene RPM’s speichern. So ein Repo ist auch ein prima Cache, wenn man viele, viele Server hat, die sich dann die neusten Versionen aus dem eigenen Cache ziehen, statt alle von Fedora. Der Traffic bliebe dann z.b. im LAN.

Mit Yum Paketupdates rückgängig machen

Posted on 29. Januar 2015 by marius

Ab und zu kann es vorkommen, daß neue Pakete von Treiber oder Programmen zu Fehlern führen. Jüngstes Beispiel ist der Nvidia Treiber für Fedora 20. Da die Auswirkungen erst nach dem Neustart des Computers wirksam werden, benötigt man zum Beheben des Problems Rootrechte.

Pakete identifizieren

Zunächst einmal muß man die Pakete finden, die aktualisiert wurden. Dazu schaut man sich die letzten Zeilen des Yum Logfiles an :

# tail /var/log/yum.log
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-3.17.8-200.fc20.x86_64-340.65-4.fc20.x86_64
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-340.65-4.fc20.x86_64
Jan 29 00:45:22 Installed: 1:kmod-nvidia-3.17.8-200.fc20.x86_64-331.113-1.fc20.1.x86_64

Pakete die mit der Sache nichts zu tun haben, könnten natürlich auch installiert worden sein, im obigen Beispiel ist das nicht der Fall.

Pakete downgraden

Die Pakete wieder los zu werden ist ganz einfach, wenn man den korrekten Namen ermittelt hat:

# yum downgrade kmod-nvidia-340xx-3.17.8-200.fc20.x86_64
# yum downgrade kmod-nvidia-340xx-340

Updates verhindern

Damit die Pakete beim nächsten Update nicht wieder mit eingespielt werden, trägt man diese in die Liste der ausgeklammerten Pakete in der YUM Konfiguration ein:

# vi /etc/yum.conf

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=kmod-nvidia-340xx*

Damit wäre man vorerst vor Updates sicher. Das nächste Kernelupdate kommt aber todsicher und dann braucht man die neue Version der Pakete für diesen neuen Kernel. Man muß sich also jetzt sofort darum kümmern, daß dieser Fehler bekannt und natürlich behoben wird.

Bugzilla

RPMFusion und Fedora haben jeweils eine eigen Fehlertrackersoftware namens Bugzilla im Einsatz. Da die Nvidiatreiber über RPMFusion bekommen sind, muß man das Paket dort als Fehlerhaft melden.

Details zur Anmeldung kann man auf rpmfusion.org finden.

Es geht aber auch direkter, was in diesem Fall wohl dringend nötig ist. Dazu lädt man sich die defekten RPMS aus dem Repository direkt auf die Platte. Wie das geht habe ich hier beschrieben: Aus Yum ableiten wo ein RPM findet

Dann schaut man sich die Infos zu diesem RPM an : less xorg-x11-drv-nvidia-340xx-*

Neben allerlei Informationen zu dem Paket selbst, kann man hier auch direkt das Changelog sehen:

* Di Jan 27 2015 Leigh Scott <leigh123linux@googlemail.com> – 1:340.65-5
– revert last commit

Nun können Sie das direkt an den Entwickler melden, der das „verbockt“ hat 🙂

wenn das Paket bereits installiert ist …

geht das Aufrufen des Changelogs wesentlich einfacher :

# rpm -q –changelog xorg-x11-drv-nvidia-340xx
* Do Jan 15 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-4
– Replace main nvidia driver in F20 with this legacy version

* So Jan 11 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-3
– Switch libnvidia-ml and nvidia-debugdump to the cuda subpackage again

… die Logs gehen bis zur ersten Release des Pakets zurück …

* So Jun 22 2003 Andreas Bierfert (awjb) <andreas.bierfert[at]awbsworld.de> – 0:1.0.4363-0.fdr.1
– Initial RPM release, still some ugly stuff in there but should work…

Kein Wunder, daß die Pakete immer länger brauchen bis sie geladen worden sind.

Marius Welt

Tag Archives: downgrade