[Megoldva!] SELinux + root password visszaállítása

Linux-kezdő

Sziasztok!

Én Az egyik ismerősőm :) egy desktop gépen, amin van egy root user, és egy regular user véletlen egy rosszul kiadott usermod paranccsal kivette magát a wheel groupból. Ez egy Fedora 40 egyébként, és a root bejelentkezés pedig le van tiltva. Tehát sikeresen kitiltotta magát, mint adminisztrátor, ezt ugye jól gondolom?

Már túl vagyok a dolgokon, de három lehetőséget találtam, itt van leírva kettő:

https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/

A harmadik, hogy felmountolom a home-ot, gyorsan csinálok még egy mentést, és 15-30 perc alatt újrahúzom a rendszert (ami kb meg is lehet az összes beállítással).

Az első két megoldással elszórakoztam kb 2 órát,

1. Rescue módban ha megváltoztatom a jelszót, hiába hozok létre egy /.autorelabel fájlt, utána nem lehet belépni egy jelszóval sem.

Kicsit kutakodva, korábban a /etc/init.d/fuctions fájlban volt egy ilyen:
https://github.com/aababilov/systemd/blob/master/fedora-autorelabel
Most ez sehol nincs (vagyis én nem találtam), és a .autorelabel is ott marad a root könyvtárban reboot után, tehát nem is futott ilyesmi.
Ha kézzel akarom futtatni az itt leírt parancsokat, persze az nem működik, nem írtam fel a hibaüzeneteket, de selinux-os problémákra hivatkozott. (szerinten nem megfelelő context volt beállítva, vagy hasonló).

2. Live CD:

Miután felmountoltam mindent, és chroot-al root könyvtárat váltottam, kiadnám a passwd-t, de a következő hibát adja:

authentication token manipulation error

Tehát a Fedora-s leírások (2022-ben update-elték utoljára) igazából Fedora 40-el nem működnek/én a selinux-hoz se értek, meg kellene tanulni..

3. Újra telepítés: Ez itthon megtehető (máshol már nem), ez persze működik, gyorsan meg is van, csak nem ez lenne a módja.

Az is simán lehetséges, hogy valami pofon egyszerű egyéb módszerrel meg lehet ezt oldani, és feleslegesen bonyolítottam.

Most már nem kisérletezek vele, minden működik, de foglalkoztat, hogy mi a rendes megoldás, esetleg valaki járt már így?
Best practice, hasonló esetek kivédésére: Van a gépeden plusz user, vagy engeded a root-nak a belépést?

Megoldás:

Lásd: https://hup.hu/comment/3055661#comment-3055661

( dlaszlo | 2024. 05. 04., szo – 18:00 )

Szerkesztve: 2024. 05. 04., szo – 18:01

Egyébként egy elmélet: a 2. módszer (live cd) azért nem működhetett (és kaptam a "authentication token manipulation error" hibaüzenetet), mert már elrontottam a selinux jogosultságokat az 1. módszerrel (rescue mód).

Ez a

touch /.autorelabel

és reboot módszer meg nem működik valamiért már Fedora 40-en, csak esetleg nincs update-elve a doksi.

( zrubi v | 2024. 05. 05., v – 11:36 )

és a root bejelentkezés pedig le van tiltva

Ez alatt pontosan mit értesz?

 

Mert 'normál esetben', su-val (ismert és létező root jelszó esetén) tudnál váltani root-ra.

Ha ez sem megy, akkor 'rescue mód'-ban pedig simán vissza kellene tudnod rakni magad a megfelelő csoportba... szerintem.

(és/vagy manuálisan 0-ra állítod a létező user uid-ját)

ha rebootolni tudsz, akkor a selinuxot is tudod hatástalanítani a megfelelő kernel paraméterekkel (akár csak ideiglenesen)

 

összegezve:

ha reboot-olni tudsz, és kernel paramétereket is modosíthatsz = god mode.

innen már csak a szakértelem (hiánya) korlátozhat téged ;)

zrubi.hu

Mert 'normál esetben', su-val (ismert és létező root jelszó esetén) tudnál váltani root-ra.

Szerintem csak akkor tudsz, ha adtál a rootnak jelszót. Alapból Fedora alatt valahogy le van tiltva / nincs jelszava, nem tudtam rá átváltani.

Ha ez sem megy, akkor 'rescue mód'-ban pedig simán vissza kellene tudnod rakni magad a megfelelő csoportba... szerintem.

(és/vagy manuálisan 0-ra állítod a létező user uid-ját)

Na igen, ezt elcsesztem, mert kapásból azon voltam, hogy a rootnak adjak jelszót, de lehet, hogy elég lett volna a usert visszatenni a group-ba. A selinux-os kérdés lehet, hogy így is előjött volna.

ha rebootolni tudsz, akkor a selinuxot is tudod hatástalanítani a megfelelő kernel paraméterekkel (akár csak ideiglenesen)

Na hát ezt nem sikerült. :) pedig nagyon rajta voltam. Végül ráhagytam, de ez megoldás lehetett volna. A fájlokon kellett volna valami jogosultságot visszaállítani,
ami gondolom nem véletlen reboot-oláskor fut (az eredeti megoldás szerint amit linkeltem), tehát olyankor van beállítva, létrehozva valami selinux context, ami rescue módban nem ment.
De itt bőven van mit tanulnom, bocs ha hülyeséget beszélet.

innen már csak a szakértelem (hiánya) korlátozhat téged ;)

de sajnos a könnyebb utat választottam most (rövidebbet), el lehetett volna tenni a problémát reggelig, és akkor tanultam volna belőle. :) Egy VM-ben még lehet, hogy kipróbálom, ha lesz rá idő.

Köszi szépen!

'selinux=0'  és 'init=/bin/bash' kernel paraméterrel  bootolva, 'hatástalanítod' az egész selinux részt a kernelben, olyan, mintha nem is létezne.

a 'rescue mód' meg root jogokkal ad egy shell-t -> így korlátozás nélkül tudod a filerendszeredet módosítani = bármit csinálhatsz ilyenkor gyakorlatilag.

 

reference:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…

zrubi.hu

Igen, de Fedora alatt ahogy nézem Rescue módban a SELinux eleve disabled-ben van. A getenforce parancs outputja legalábbis az, hogy "Disabled".

Így ha jól értem, módosítottam fájlokon, amit így utána a selinux nem fogad el. Ahhoz hogy visszaállítsam a jogosultságokat ezeken a fájlokon be kellett volna tudnom lépni (de ki voltam zárva), hogy aktív legyen a selinux.

Vagy rescue módban kellett volna valami script-et heggeszteni, ami bootoláskor fut, amikor már aktív a selinux (ami elvileg volt korábban mint hivatalos megoldás, de most nem működik, vagy már máshogy működik).

( locsemege v | 2024. 05. 05., v – 12:13 )

Most nincs kedvem játszani vele, de ehhez szerintem se rescue, se live - ami ugyanaz - nem kell. A grub menüjében azt hiszem, 'e'-t nyomva tudod editálni a kernel paramétereket, ott egy jól irányzott selinux=0 kikapcsolja erre az egy boot-ra a selinuxot. Utána boot-olsz, ha nem megy a su - parancs, akkor vélhetően mennie kell a sudo -i parancsnak. Valahogyan kell root jog. Onnan már visszateszed magad a wheel-be, illetve csinálhatod azt, hogy a /etc/passwd file-ban a

root:x:0:0:root:/root:/bin/bash

sorból törlöd az x-et, tehát

root::0:0:root:/root:/bin/bash

lesz belőle. Ekkor üres lesz a root jelszó, pontosabban talán egyáltalán nem kér majd jelszót. De gondolom, kapásból is megy a passwd parancs. Aztán természetesen

: >/.autorelabel

Újraindítod, megcsinálja a relabelinget, ő is újraindítja magát, aztán szerintem készen vagy.

Ha meg egyáltalán nem sikerül root-nak lenned, akkor rescue - ami live - pendrive-ról boot-olva megcsinálod a passwd file-t. Szerintem kár volt újratelepíteni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( NevemTeve | 2024. 05. 05., v – 13:55 )

Első lépésként tiltani kellene a selinuxot, második lépésként megmenteni a rendszert, harmadik lépésben nem visszakapcsolni a selinuxot.

Harmadik lépésben boot során kényszeríteni a relabel-t, mert a kikapcsolt selinux-szal módosított /etc/{passwd|shadow|group} cimkéi mennek a kukába, amit helyre kell állítani. A "nem visszakapcsolni a selinuxot" az marhaság - meg kell tanulni, hogy micsoda, hogyan működik, mit csinál, és ennyi.

Sziasztok!

Igen, pontosan én is ezt találtam, hogy így kellene működnie. De Fedora 40 alatt hiába teszem oda a .autorelabel fájlt, nem triggereli a relabelt, ahogy kellene. Vagy valamit nagyon benézek, benne van a pakliban.

Rescue módban ki van kapcsolva alapból a SELinux.

Viszont a link mögött, amit @Zruby bemásolt, van egy autorelabel indítási paraméter is, lehet hogy az működik.

Most már indítok egy VM-et és kipróbálom. :)

Köszi szépen.

Ugye az a file /.autorelabel

Nem ./autorelabel, nem /autorelabel meg egyebek.

https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/ -- nagyon meg lennék lepve, ha nem menne, ugyanakkor számtalanszor elböktem már, hogy rossz helyre és/vagy névvel hoztam létre.

 

Aha, látom hogy közben megoldódott.

Alapvetően igazad van, de én megvédeném azért a kollégákat. Ez így agyrém, amit a Fedora csinál. Nem az, hogy van SELinux, az okés, ők abban hisznek, hogy valami is jobb lesz attól, de hogy emellé bekényszerítik, hogy nincs root, az már agyfarokság, a dolgok végletes tetézése (helyesebben van tovább, secure boot erőltetése, meg a többi). Tudom, biztonságoschhh, de olyannyira, hogy a user a saját rendszeréből ki lesz zárva.

Én ezek miatt nem használnék Fedorát. A nagy Red Hat corporate elmék eldöntenének mindent helyettem, fél évente disztrófőverziót kéne léptetnem, el lenne döntve, hogy nekem kell a Secure Boot, SELinux, rootnélküliség, OOMkiller, Windows jellegű, boot során frissítés, Btrfs, Grub, meg egy csomó extra szutyok, X letiltva, tárolókból kivéve, FFmpeg-ből a hardveres kódolás-dekódolás jogi okból kivéve, mert ők ezt jobban tudják, mint én. Holott a Linuxnak a szabadság lenne a lényege, hogy a te rendszered fölött a te kezedben legyen a teljes kontroll, csak az legyen fent, az fusson, amit te akarsz, akkor frissüljenek dolgok, amikor te akarod. Ez az értelme a sok haladó meg netinstallos disztrónak, hogy a te kezedbe teszik le a döntéseket, legalábbis javarészt. A legszabadabb a Gentoo, ott semmi nincs eldöntve helyetted. Az Arch már 1-2 dologban kötött, pl. ott eldöntötték helyetted, hogy glibc, systemd (Artix-on ez nincs, ott az van eldöntve, hogy ott meg nem lehet systemd-d), initramfs az lesz, de a többi rajtad áll. Void-on már azt is eldöntik, hogy neked Grub-od lesz, de még az se olyan vészes.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Fedora 40 van az összes gépemen, mindegyiken van root, egyiken sem vagyok a wheel csoportban. Amúgy ez a gyökértelen sudo-zás Ubuntu találmány tudtommal. Fedorára opcionálisan gyűrűzött át, nem pedig kötelezően. SELinux nem gátja a mindennapoknak, de akinek nem tetszik, egyetlen paranccsal kikapcsolhatja, ha valaki nagyon agresszív, akár kernelparaméter által is véget vethet neki.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( dlaszlo | 2024. 05. 05., v – 16:07 )

Szerkesztve: 2024. 05. 05., v – 16:31

Közben elég furcsa dolgot tapasztalok, de ezek szerint én bénázok. :/

VM-ben kipróbálva működik a ./autorelabel file.....

https://imgur.com/a/rYeRHyU

Ilyet nem is láttam a gépemen, ami a screenshot-on van, a fájlt vagy 10-szer leellenőriztem, hogy oda tettem-e, jó néven-e, stb... biztos, hogy nem futott valamiért. (újraindítás után ott is maradt a fájl, VM-ben egyébként törlődött, szóval biztos hogy nem futott az autorelabel korábban)

Köszi szépen a segítséget!

10-szer leellenőriztem, hogy oda tettem-e, jó néven-e, stb...

Ahhoz képest most is elírtad:

./autorelabel

Ez az aktuális könyvtárban egy autorelabel nevű file, ami akkor sem jó, ha történetesen a $PWD a /, mert a file első karaktere pont lenne. Helyesen:

/.autorelabel

Pedig már írták...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( dlaszlo | 2024. 05. 05., v – 16:52 )

Szerkesztve: 2024. 05. 05., v – 16:58

Még sincs megoldva!! Kipróbáltam a saját gépemen, nem fut az autorelabel, ahogy VM-ben, most éppen ki vagyok zárva. :) Rá sem bajszint a /.autorelabel fájlra. A jog rajta: 666, itt van a /-ben, és újraindítás után is itt marad. Jól adtam meg a fájlnevet.

( dlaszlo | 2024. 05. 05., v – 16:57 )

Szerkesztve: 2024. 05. 05., v – 17:05

Update: Ha indítási paraméternek adom meg az autorelabel=1-et, akkor viszont működik az autorelabel a gépemen is. (A fájlos módszer csak a VM-ben megy, a gépemen valamiért nem.)

(lásd doksi: https://hup.hu/comment/3055557#comment-3055557 amit @zruby belinkelt).

( joco01 v | 2024. 05. 05., v – 17:11 )

Másik rendszer alól editáld az /etc/group fájlt, tedd magad vissza a wheel csoportba.

Hát ez az, ez történik, és a hiba igazából már csak az, hogy valami furcsa együttállás miatt az igazi gépemen nem fut az autorelabel (ami a selinux-nak rendezi ezeket a fájlokat), ha a .autorelabel fájllal akarom triggerelni, de VM-ben pedig fut.

Ugyanúgy a root partícióba helyeztem el, ugyanolyan fájlrendszer van a gépemen és a VM-ben is. Mindegy.

Az autorelabel=1 kernel paraméter működik viszont.

Szerk1:

Itthagyok egy screenshot-ot a root könyvtárról, amiben ott van a .autorelabel, ez már bebootolva a fizikai gépen: https://imgur.com/a/KKAn6FS
Ezt le kellene törölnie, ha lefut, de ott maradt. Rákeresek, hol fut ez, és megnézem mit csinál.

Szerk2:

Itt van a forrása: /usr/libexec/selinux/selinux-autorelabel
Teleraktam echo-val, és bele sem futott.

Szerk3:

Journalctl-el lekérdeztem a boot-okat:

dlaszlo@desktop:~$ journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                  LAST ENTRY                  
...
 -1 05afd46e597c4056bff6abbc1e05a1a5 Sun 2024-05-05 19:29:35 CEST Sun 2024-05-05 19:46:36 CEST
  0 534c0685bc1847e38a0d2376ab18ca1e Sun 2024-05-05 19:46:54 CEST Sun 2024-05-05 20:10:54 CEST

Majd az utolsó boot logját, ami így kezdődik:

dlaszlo@desktop:~$ journalctl -b 534c0685bc1847e38a0d2376ab18ca1e | grep relabel
máj 05 19:47:10 desktop kernel: audit: type=1400 audit(1714931230.434:7): avc:  denied  { getattr } for  pid=1420 comm="selinux-autorel" path="/.autorelabel" dev="dm-0" ino=276358 scontext=system_u:system_r:selinux_autorelabel_generator_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
máj 05 19:47:11 desktop systemd[1]: selinux-autorelabel-mark.service - Mark the need to relabel after reboot was skipped because of an unmet condition check (ConditionPathExists=!/.autorelabel).

Tehát a 19:47:10-es sor nekem azt jelenti, hogy le akarta kérdezni a .autorelabel fájlt az autorelabeling folyamat (pid: 1420), de nem volt hozzá jogosultsága... Miért? A fájl továbbra is ott van rwrwrw jogosultsággal:

dlaszlo@desktop:~$ ls -la /
összesen 20
dr-xr-xr-x.   1 root root  182 máj    5 19.28 .
dr-xr-xr-x.   1 root root  182 máj    5 19.28 ..
dr-xr-xr-x.   1 root root    0 jan   24 01.00 afs
-rw-rw-rw-.   1 root root    0 máj    5 19.28 .autorelabel
lrwxrwxrwx.   1 root root    7 jan   24 01.00 bin -> usr/bin
...

De ez magyarázza, hogy miért nem futott le az autorelabel folyamat.

Szerk4:

Megoldva: Hozzáadtam az enforcing=0 kernel paramétert a következő bootoláskor (ez a permissive mód kell, úgy látszik, és valami doskiban is olvastam), és így lefutott az autorelabel! Szépen törölte is a /.autorelabel fájlt
Fogalmam sincs, hogy VM alatt miért működött default.

Csak egy utolsó megjegyzés: Ennek a logüzenetnek:

máj 05 19:47:10 desktop kernel: audit: type=1400 audit(1714931230.434:7): avc:  denied  { getattr } for  pid=1420 comm="selinux-autorel" ...

nem biztos, hogy köze van, hogy miért nem futott. Ez annál a bootolásnál is jött, amikor az enforcing=0 után rendben lefutott..

Lehet, de végül az enforcing=0 megoldotta.

Ezt a leírást végigcsinálva 666-al jön létre: https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/

Egyébként lehetne folytatni a keresgélést, vagy a doksi olvasást, hogy az enforcing=0 miért kell, és vm-ben miért nem kellett. Van egy akmods-al fordított nvidia driverem is, más különbséget tényleg nem tudnék mondani.

Köszi!

Pedig de...

scontext=system_u:system_r:selinux_autorelabel_generator_t:s0 tcontext=system_u:object_r:unlabeled_t

Az scontext az az, amiben a processzke futott. A tcontext meg az, amiben a fájl van. Volt.

Namost... nekem gyanús, hogy a kettőnek egyeznie kéne, hogy a selinux ne fújjon rá. De nem egyezik. Szóval kb. lábon lövi magát.

Már ha mindent jól értek.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…

 

Jha, a kollégám állítja, hogy ma neki csak a rescue módban ment, gondolom abban gyárilag benne van az enforce=0, de már nyálon csúszok az álmosságtól. Holnap meg nem lesz kedvem megnézni, hogy akkor most mi van :)