Munin plugin hibat dob nem standard shebang line eseten - debian 11.1

Linux-kezdő

Üdv!

 

Van néhány munin pluginom, amik működtek egy korábbi, kb. 9-es debian rendszeren, de a mostani 11.1-es rendszeren ilyen hibát dobnak:

 

Can't exec "/etc/munin/plugins/test_plugin": Permission denied at /usr/share/perl5/Munin/Node/Service.pm line 274, <STDIN> line 24.

 

A plugin maga django-n keresztül adatbázisból szed adatokat, és a problémát úgy néz ki, hogy a shebang line okozza, ami:

 

#!/home/user/.virtualenvs/user/bin/python

 

. Ha ezt lecserélem /usr/bin/python-ra, akkor a plugin az adott hibán továbbjut, csak nekem szükségem van a virtualenves interpreterre.

 

A plugin kézzel indítvan természetesen lefut.

 

A debian egy viszonylag friss install, talán 3-4 hetes, ám egy script telepített egy alaprendszert, amiről nem sokat tudok.

 

Merre lenne érdemes elindulni?

 

Találtam ugyan egy /etc/selinux/semanage.conf nevű fájlt a rendszeren, de az összesen 2 nem kommentes sort tartalmaz:

 

module-store = direct

expand-check=0
 

 

  • 640 megtekintés

( okigye | 2022. 07. 29., p – 11:57 )

Hali!

Az a tippem, hogy, vagy az elérési útban van valahol jogosultság hiba, vagy a magának a futtatandó filenak a jogosultságaival van probléma.
Próbálj rá su-zni a munin futtató userére, és nézd meg, hogy eléri-e, és tudja-e futtatni a /home/user/.virtualenvs/user/bin/python filet.

OkiGyE

Az, hogy lecseréled a shebangot, azt jelenti, hogy egy másik útvonalon levő interpretert futtatsz. Maguk a program binárisok is egyszerű fájlok, és míg a /usr/bin mappánál az operációs rendszer garantálja, hogy minden felhasználó számára tallózható és a benne levő cuccok elérhetőek, a nem standard útvonalakra (és a /home/userem/.virtualenvs/ -en belüli könyvtárak ilyenek) nincs ilyen garancia. Tehát pont, hogy simán lehet elérési gond.

Úgy érdemes futtatni, hogy

sudo -Hu munin /etc/munin/plugins/enkicsipluginem

és így megnézni, hogy permdenied-et dob-e. Ha igen, akkor a következő lehetőség a 

sudo -Hu munin /home/user/.virtualenvs/bin/python

futtatása, hogy ez permdeniedet dob-e.

Szerk:

Lejjebb görgettem, és elolvastam a kommentedet, miszerint a /home/user/.virtualenvs/user/bin/python -t ha lemásolod, akkor működik, ha symlinkeled nem. Ez is a fenti gondolatmenetre vezet vissza. Megmutatom, hogy szerintem mi a gond.

Lássuk ezt az útvonalat: /home/user/.virtualenvs/user/bin/python

Ebben 5 darab mappa van, sorrendben

  • /home
  • /home/user
  • /home/user/.virtualenvs
  • /home/user/.virtualenvs/user
  • /home/user/.virtualenvs/user/bin

Ahhoz, hogy a "user" nevű felhasználón kívül bárki futtatni tudjon ezen mappákból valamit, az others jognak minimum x-nek kell lennie (oktálisan a harmadik számnak páratlannak kell lenni, az ls -l kimenetében pedig a harmadik szekcióban kell lennie egy x-nek legalább). Ha ez nincs így, akkor a futtató felhasználó nem tud bele cd-zni az adott mappába, és annak almappáiba se, így nem éri el a megfelelő binárist.

Nálam Arch Linux alatt pl így néz ki a home mappám:

drwxr-x--- 109 hron hron 4096 aug    1 23.19 /home/hron

Ebből azt láthatod, hogy azon felhasználóknak, akik nem én vagyok, és nincsenek benne a "hron" csoportban, nincs joguk belépni sem a mappámba. Következésképpen, ha én csinálnék hozzád hasonlóan egy munin plugint, én is permission deniedet kapnék, mert a munin nem tudna belelépni a /home/hron mappán belülre, és onnan már nem érné el a .virtualenvs mappámat sem. 

És a jogosultságok végignézése szimbolikus link esetén is ugyanígy működik, hiába symlinkelsz valamit ki, ha nincs jogod elérni azt a fájlt, akkor a symlinken keresztül sem lesz. Ez semmi egyéb védelem, mint a jó öreg Linuxos fájljogok.

A hiba felgöngyölítéséhez futtass "ls -ld" parancsot minden érintett mappára a virtualenves python útvonalában és nézd át a jogait. Ott lesz a gond, én érzem... a hasamban!

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Toma_ | 2022. 07. 29., p – 13:16 )

Csak találgatok, de nem lehet, hogy python verzióprobléma? A 9-ben a 2-es volt, azóta meg 3-as lett. Én futottam bele olyanba Debian 11-en, hogy az #!/usr/bin/python-t is át kellett írnom a ketteshez, pedig elvileg már a 11-hez készült a script.

( arpi_esp v | 2022. 07. 29., p – 13:25 )

Szerkesztve: 2022. 07. 29., p – 13:25

a munin by default munin userrel futtatja a scripteket, ami lehet hogy nem lat bele abba a home-ba. konfba allitsd at hogy ezt a plugint az adott user (vagy root) joggal inditsa.  munin-run pluginneve paranccsal lehet tesztelni

Az a gond, hogy ugye a fajl eleresekkel nem lehet gondja, hiszen ha a shebang-ot atirom, akkor fut, illetve ha munin userkent kozvetlenul futtatom, akkor is fut.

 

Egyebkent root-kent a /usr/sbin/munin-run test_plugin is ugyanazt a hibat dobja.

Örökölt gépen jártam pórul. Egy belső fejlesztésű egyszerű app futott egy Ubuntun. Belenézem az init szkriptjébe, az a /usr/bin alól indított valamit. Még morgolódtam is, hogy miért nem a local alá pakolt, minek szemetelte össze a /usr/bin-t. Később, amikor töröltem a régi admin userét, a következő reboot után már nem indult el az app. Kiderült, hogy az illető a homejában fordított és a /usr/bin-be tett rá egy symlinket.

Azért is érdemes a helyükre pakolni a dolgokat, hogy ne szívasd meg a szerencsétlen utódodat.

$ grep -c egy$ word.list
100

Csak tippelni tudok, de szerintem nálad nem aktív a selinux, és lehet, hogy apparmor sincs. Ne aggódj, nálam sincs. ;) 

Egyébként amit írtál lentebb, a /home/user/.virtualenvs/user/bin/python az egy link volt eredetileg a /usr/bin/python-ra? És mi az a pythonu?

 

Szerk.:

Ja, a csere elég, de updatelni kell így a grubot, hogy használja. Bár én a helyedben csak a bootkor írnám be, akkor csak arra az egy bootra vonatkozik, a grub.cfg marad eredeti.

A /home/user/.virtualenvs/user/bin/python az egy valós binary, ami mindig létrejön, ha létrehozol egy virtualenv-et, pl. egy python projecthez. Ha ezt a virtualenv-et aktíválod, akkor ezt a python executable-t fogja használni.

 

A pythonu pedig erre a python executable-re egy link, vagy egy cp. Nyilvánvalóan az egésznek azzal van gondja, hogy a shebang egy olyan helyre mutat, ami nem tetszik neki, és ezt egy linkkel sem engedi áthidalni.

 

Sajnos a Debian 9-es rendszerem nem elérhető, csak fájlszinten van meg a tartalma, de el sem tudom képzelni mi okozhatja ezt a nyilvánvalóan egyszerú problémát, ami most már 2 gépen is fennáll.

A SELinux nem olyan valami, hogy van a /etc-ben egy config és aszerint viselkedik, hanem a filerendszer tulajdonsága, és minden egyes file-hoz van SELinux label. Ha az nem olyan, ami neked jó, akkor nem fog menni. Márpedig a user_home_t és a bin_t más környezetet definiál. Az ls -Z paranccsal tudod megnézni.

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

Hát, ez azért eléggé leegyszerűsített lett, nyilván a címkézést azért nem a kernel találja ki, hanem van rá házirend. Pl. az említett /etc/selinux/semanage.conf a távoli házirend kiszolgáló konfigurálása való tudtommal. No meg ugye nem csak enforce módja van. Gyanítom, hogy az ő rendszerén nem is aktív a selinux. Legalábbis úgy tűnik az eddigiekből.

Hogy tudom kideríteni, hogy aktív-e?

 

locate selinux
/etc/selinux
/etc/selinux/semanage.conf
/usr/include/linux/selinux_netlink.h
/usr/lib/x86_64-linux-gnu/libselinux.so.1
/usr/lib/x86_64-linux-gnu/security/pam_selinux.so
/usr/share/doc/libselinux1
/usr/share/doc/libselinux1/changelog.Debian.gz
/usr/share/doc/libselinux1/copyright
/usr/share/man/man7/pam_selinux.7.gz
/var/lib/dpkg/info/libselinux1:amd64.list
/var/lib/dpkg/info/libselinux1:amd64.md5sums
/var/lib/dpkg/info/libselinux1:amd64.shlibs
/var/lib/dpkg/info/libselinux1:amd64.symbols
/var/lib/dpkg/info/libselinux1:amd64.triggers
 

ls -Z minden érintett fájlra csak egy ?-et ad vissza.

No. Amikor fentebb írtam, hogy a munin-run nem megy, az igaz is volt, meg nem is. Root-ként tényleg nem megy, munin userként viszont igen.

 

Ami fura, hogy most egy másik gépre felraktam egy munin-t (debian 11.4), és ott is ez a hiba van. Ez afféle digitalocean-os előtelepített debian.

 

Ami megy:

1) @munin                            /etc/munin/plugins/test_plugin

2) @munin                            /usr/sbin/munin-run test_plugin

Ami nem megy:

1) @root                               /usr/sbin/munin-run test_plugin
Can't exec "/etc/munin/plugins/test_plugin": Permission denied at /usr/share/perl5/Munin/Node/Service.pm line 268.
# FATAL: Failed to exec.
Warning: the execution of 'munin-run' via 'systemd-run' returned an error. This may either be caused by a problem with the plugin to be executed or a failure of the 'systemd-run' wrapper. Details of the latter can be found via 'journalctl'.

2) @munin                                 munin-cron

2022/07/29-18:15:34 CONNECT TCP Peer: "[::ffff:127.0.0.1]:41584" Local: "[::ffff:127.0.0.1]:4949"
2022/07/29-18:15:35 [4058739] Error output from test_plugin:
2022/07/29-18:15:35 [4058739]   Can't exec "/etc/munin/plugins/test_plugin": Permission denied at /usr/share/perl5/Munin/Node/Service.pm line 268, <STDIN> line 25.
2022/07/29-18:15:35 [4058739] Service 'test_plugin' exited with status 42/0.
2022/07/29-18:15:35 [4058739] Error output from test_plugin:
2022/07/29-18:15:35 [4058739]   Can't exec "/etc/munin/plugins/test_plugin": Permission denied at /usr/share/perl5/Munin/Node/Service.pm line 268, <STDIN> line 26.
2022/07/29-18:15:35 [4058739] Service 'test_plugin' exited with status 42/0.
 

Ah, bár természetesen megint nem a systemd a hülye, hanem aki használja, de hasznos straces commented segített így reggel felhívni a figyelmemet, hogy a munin-run bizonyára csak valami dispatcher (ami, nem ismervén a cuccot, meg este lévén tegnap nem esett le).

Feltettem egy konténerbe, természetesen a debianosok "baszarintották el", vagyis hogy megvédik a géped a potenciálisan fos pluginektől:

cat /lib/systemd/system/munin-node.service 
[Unit]
Description=Munin Node
Documentation=man:munin-node(1) http://guide.munin-monitoring.org/en/stable-2.0/reference/munin-node.html
After=network-online.target

[Service]
EnvironmentFile=-/etc/default/munin-node
Type=notify
Restart=always
ExecStartPre=install -o munin -g munin -d /run/munin
ExecStart=/usr/sbin/munin-node --foreground $DAEMON_ARGS
PIDFile=/run/munin/munin-node.pid
# Plugins like "smart_" require access to devices
PrivateDevices=false
PrivateTmp=true
ProtectHome=true
# "full" (instead of "strict") still allows write access to the state files
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Na, ebből a ProtectHome pont ezt csinálja.

Egyébként kb le is írták, benne van a doksiban:

cat /usr/share/doc/munin-node/README.Debian |grep -A 10 -i systemd
  Systemd, munin-node and plugins
  -------------------------------

    The systemd service specification for munin-node imposes a few
    restrictions on the context of plugin execution.
    This may cause confusion, as the plugins' behaviour will depend on
    whether they are executed manually in "munin-run" (for debugging) or
    indirectly via "munin-node" (when being queried by the munin master).
    For example plugins are not allowed to read /home (may be relevant for
    the "df*" plugins) and they use a private /tmp directory.
    See /lib/systemd/system/munin-node.service for the default settings of
    the munin-node service.  All settings can be overridden permanently
    via "systemctl edit munin-node".

Szóval, systemctl edit munin-node, és írd bele, hogy ProtectHome=read-only, utána egy systemctl daemon-reolad, és jó lesz. Vagy tedd máshova a virtualenvet.

 

ja, és tedd vissza az apparmort. :)

Nekem a strace nagyjából egy 4 megás fájlt outputolt rengeteg adattal, de hasznosat nem találtam benne.

 

Viszont, nagyon köszönöm, ha a /lib/systemd/system/munin-node.service fájlban megszerkesztem a ProtectHome-t, és néhányszor újraindítom a system.d-t, illetve a munin / munin-node-t, működik.

 

Fura, hogy más még nem futott bele ebbe a hibába, bár lehet kevesen használnak nem standard shebangot, de itt most az kell... .

 

Köszi.

Ne közvetlen szerkeszt, azért mondtam az editet, mert az csinál egy override filet, (egyebként a /etc/systemd/system/munin-node.service.d/override.conf, vagy ilyesmi, de így nem kell a pathot megjegyezni), és oda elég azt beírni, amit csinálsz.

 

Egyébként más is belefutott már, csak max nem shebanggal, mert nem az a gond, hogy shebang, hanem hogy a homeodeban van.

Szép, grat!

Én nézegettem a munin debjeit, de eszembe se jutott, hogy a /lib-be belenézzek. Mondjuk ha megtalálom, akkor sem gondoltam volna erre, pedig ugye állítólag a mondás szerint, "ha már végképp nem működik valami, akkor el kell olvasni a dokumentációt"! :) 

Na igen, nekem is még eltartott volna 4-5 hétig, esetleg évig, mire rájövök :- ). Dokumentáció meg eszembe sem jutott. Már lassan 10 éve nem admin vagyok, a systemd-s dolgokat is csak érintőlegesen olvasgattam, de a dokumentációt elolvasni eszembe sem jutott. Meg voltam róla győződve, hogy bár 3 gépen volt ugyanaz a hiba, de én csinálok valamit nagyon rosszul (kinek nem volt még ilyen? :- . ).

Passz. ;)

$ cat debian_version 
11.2
$ systemd
Trying to run as user instance, but the system has not been booted with systemd.
 

Mindenesetre kicsit kíváncsi lettem, hogy MX-en lenne-e hiba, én egy vmstat plugint átraktam a ~/Asztal-ra, és a munin-cron hiba nélkül vitte munin userrel.

De nyűgös lettél! :D

Amúgy szerintem a hiba az a nem várt működés. Hogy most az kinek a hibája, az meg egy másik dolog, én azt nem mondtam, hogy kié. Mondhatnám erre azt, hogy ha tényleg működik systemd nélkül, akkor a systemd-s hibaüzenet nem valami szuper, főleg annak tudatában, hogy akkor most kétféleképpen működik, környezettől függően, és hiba, hogy a home-ból mégis működik ha nincs systemd!!!! :D Nyilván nem köteles a fejlesztő tökéletes hibakezelésre, de azért ekkora korlát elég komoly. Nyilván benne van a dokumentációban, és hiba esetén illik elolvasni, de lehetne a home szigorításról esetleg a hibaüzenetben is utalni, gondolom, megoldható lenne.

Na de mindegy is, észrevetted a _hiba_ okát, megoldódott, én most ezt a témát lezártam. :D

nem lettem, csak kevésbé kedvelem az olyen megállapításokat, hogy mánmegintszarasystemd, mert aztán jön majd pl mispelled gandzsa barátunk, és felírja a listájára, hogy hát factually szar a systemd, hát bele van írva a Zinternetbe. Miközben meg nem, valaki tudatosan bekapcsolt egy featuret. Azért van az egész "tényleg működik systemd nélküli", cseszés, mert neki a dolga a futtató környezet. Ez a típusú "hiba" nem új, és nem is systemd specifikus, előtte a "miafaszért nem fut ez cronból, mikor elindítva igen" volt a sláger, csak unlike a cron, a systemd legalább ad eszközt, amivel tudod úgy tesztelni, mintha ő indítaná. A munin fejlesztők használják is, nem is trivi, hogy miért futott le munin-runból, a kódot olvasva nem kellett volna.

A jobb hibaüzenet valóban jogos igény, és ez a systemdnél valóban tud vackos lenni, de ebben az esetben -- is, ez máskor is jellemző mint -- az van, amennyire egy gyors kód olvasás , meg common sense alapján látom,  hogy egy rendszer featuret konfigurál, nevezetesen egyszerűen a megfelelő paraméterekkel mountolja be az adott könyvtárat az adott processnek. Ebből meg következik, hogy a systemd nem igazán tudja logolni. A rendszer meg alapvetően baszik az fs perm denyokat logolni, erről nem a systemd tehet. Persze cserébe, ha nem ezt csinálná, hanem emiatt keresztülvinné valami saját szolgáltatásán, akkor meg az lenne a baj, hogy miért csinálja ezt is.

És persze ilyenkor a standard eszközökkel lehetne is nyomozni, írtam is, hogy ott az audit alrendszer, azt meg lehetne kérni, hogy legyen kedves.

És az is igaz, hogy ilyesmit általában szebben lehet csinálni mondjuk selinux policyval, többekközött azért, mert jobban logol. Csakhát az egyrészt több munka, másrészt meg unlike systemd, az még nem defacto standard, mert a világ egy jó fele ugye apparmort használ, kétszer dolgozni meg nem szeret senki.

Szerintem én egy rossz szót sem mondtam a systemd-ről, már csak azért sem, mert jelen esetben a systemd-hez való munin service kavart be, ami meg nem a systemd hibája. Amúgy szerintem a systemd egy totálisan linuxfilozófia-ellenes, túlbonyolított, elkapkodott, kiforratlan és felesleges baromság, és semmivel nem lett használhatóbb tőle a linux, de nem is lesz! :D De mondjuk ez a véleményem abszolút lényegtelen, és nem fogom/szoktam csak azért is szidni, megoldom, megoldottam a gondom valahogy, ahogy más rendszereknél szoktam. ;) 

Ez egy kiváló példája, hogy mi a baja a mostani fejlesztőknek. Ez az ész nélkül beemelek mindenféle libet meg komplett framework-öket plugin-kazallal, minden legyen benne, mint a fradilevesben, csak épp nem értjük, hogy mit csinál, hogy működik a háttérben, aztán megy a csodálkozás, meg jönnek a rá épülő sérülékenységhegyek, plusz az egész bloatabb is lesz. Ezért jó sokszor a köztes függőségeket meg abszrakciós rétegeket kihagyni. Egyszerűsít, gyorsít, soványít a kódon, később a hibakeresés is könnyebb lesz. Nem véletlenül esküszik erre a suckless és az OpenBSD csapata is.

Nem csak a programkódnál, de ezt a LaTeX-en is megfigyeltem, ami egy nagy rakás makrógányolás a sima (plain, Knuth-féle) TeX felett, amit aztán ha állítani akar az ember, akkor egy kazal csomag kell, amiről persze nem értjük mit csinál, meg egyes csomagok összeakadnak, egymás beállításait felülbírálva, így az egészből lesz egy spagettikódos katyvasz. Közben meg ugyanaz alap TeX parancsokkal sokszor sokkal egyszerűbben megcsinálható, átláthatóbb, kisebb, könnyebben leforduló kódot eredményezve. Vagy pl. ugyanez a kódgenerátoros meg dinamikus webframeworköknél, amik egy csomó extra erőforrást felemésztenek, egy csomó biztonsági támadási felületet behoznak, közben meg sokszor elég lenne kézileg normálisan megírni az oldal kódját, gyorsabban is renderelődne le.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Azt ugyan nem tudom, hogy ezt most rám érted-e, vagy a debian fejlesztőkre, de ha rám, én nem vagyok fejlesztő. Csak van egy plugin, ami működött 6-7 éve, tulajdonképpen lényegi változtatás nélkül, és a friss debianon is szerettem volna működésre bírni anélkül, hogy a plugint átírom. Persze, már a legelején lehetett volna találni workaroundot rá, de itt most nem az volt a lényeg.

 

Az átlag userek nem szeretik, ha működik valami évekig, aztán egy újabb verziónál bumm, már nem megy. Ilyenkor jó megtudni, hogy miért nem... .

Bocsánat, félreértettem, a node-ból meg a shebangból következtetve azt hittem, hogy ez egy n+1. webes framework lesz valami fejlesztési feladathoz, közben meg utánanézve ez egy hálózati monitorozós cucc, bár ahhoz meg furcsállom, hogy shebangezni kelljen. Bár félig még mindig tartom, hogy enélkül is lehetne monitorozni. Persze megértem a frusztrációt, eddig ment, most meg nem működik. Mindegy, megoldás végül is meg van, csak egy gondolat volt.

De ha már itt vagyok, az érdeméhez is hozzászólok. Arch Wiki szerint ennek a Muninnak kell, hogy a munin nevű csoportban lévő munin nevű userrel fusson. Lehet ez okozza a jogosultságbeli hibát, és mint ilyen, nem Debian-specifikus probléma. Bár ki tudja, lehet nem ez okozza, hanem az selinux kavar be, ahhoz meg végképp passz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Szerintem maradjunk abban, hogy ez kiváló példája annak, mi a baja a mostani hupos hozzászólóknak. Elolvasás nélkül kommentelnek irreleváns marahságokat, és mondanak értékítéletet mások felett, aztán ha elolvassák, még akkor se értik, hogy mi ez, de azért félig meddig ragaszkodnak a (még mindig irreleváns) marhaságukhoz.

Bónuszként hozzák a saját becsípődésüket. Baszki, szerintem te egy kell-e kolbász a rakott krumpliba topikba is be tudnád írni, hogy a vanilla tex jobb, mint a latex.

Jó, igazad van, minimális információk mentén messzire elszaladtam. Védelmemre legyen mondva, hogy abba a topikba se lenne haszontalan infó, legalább az a kérdés meg lenne oldva,latex semmiképp nem kell a rakott krumpliba, keserű íze lenne neki. Kolbász az belevaló, csak nem szabad beletenni, mert elkárhozunk, desznyó, tisztátalan állat, nem zuhanyzik naponta. Itt mink a nyugaton (UK) nem eszünk holmi porkot, mindenki muszlim vagy együttérző polkorrekt, meg paleo-neo-vegabarom, csak cshik-ííín, meg peri-peri, meg "Halal food", főleg ramadánkor, ez nem úgy van, mint a pogány balkánon, hogy majszolunk, erkölcstelen élvezet, azzal bevárjuk a 72 szüzet. Tudom, pulyka, marha, vad, stb., de ki hallott már olyanról? Olyat csak a jeti eszik, de ő azokat teszi a rakottba, meg a paprikás krumpliba is... kóbász helyett természetesen.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Még csak ez sem feltétlen. Ez egy viszonylag sensible security measure default egy olyan rendszernél, amibe azért pasztálgatnak az emberek pluginokat a fasztudja honnan is. Le is volt írva ott, ahol a debian az ilyen specifikumokat le szokta írni.

És mégiscsak az van, hogy a kolléga egy alapvetően system servicehez való izékét helyezett el a homejában, aminek ott konvenció szerint nem sok keresnivalója van.

Persze lehetett volna ehelyett apparmor meg selinux policyket is írni, de az azért nagyobb munka.

De értsd már már meg, hogy semmi baja a pluginoknak. Egyszerűen a debian maintainerek úgy döntöttek, hogy alapból nem engedik meg a pluginoknak, hogy a homeba turkáljanak, te meg beletetted oda a futtató binárisukat. Ha eleve valami sensible helyre tetted volna a virtualenvet, mondjuk az /usr/local/ alatt, akkor nem is futottál volna rá erre.

Pedig ez csak ott van bármi hatással.

Azt meg értem, hogy szoktak ilyet, de rossz szokás. Illetve az, hogy a venv a user homjában van, az akár jó is lehet, csak egy service user homejának nincs dolga a /home alatt.

És ezekre érdemes figyelni, mert ami régen leginkább csak konvenció volt, az ma általában a fokozott biztonság alapja. apparmor, selinux is gyak ezekre alapozza a policyjait. Pl Ami a /var/www-ben van, az az indiánnak szól, a többitől meg hesspicsába.

viszont az a tények fényében furcsa, hogy mikor teszteltél, akkor ment munin-runon keresztül, mert a kódot olvasva a munin-run megküzd azért (bár kicsit hülyén), hogy systemd-runon keresztül úgyanúgy fusson, mint rendesen. Ráadásul mind a kód, mint a konrét help a ProtectedHome-mal példálózik.

   --ignore-systemd-properties
        Do not try to detect and enforce the locally configured hardening
        flags of the "munin-node" service unit. This detection is skipped,
        if systemd is not enabled. The hardening flags may cause subtile
        surprises. For example "ProtectHome=yes" prevents the "df" plugin
        from determining the state of the "home" partition. [disabled]

 

szóval nem világos, miért nem akadt el. 

auditd -f
Config file /etc/audit/auditd.conf opened for parsing
local_events_parser called with: yes
write_logs_parser called with: yes
log_file_parser called with: /var/log/audit/audit.log
log_group_parser called with: adm
log_format_parser called with: ENRICHED
flush_parser called with: INCREMENTAL_ASYNC
freq_parser called with: 50
max_log_size_parser called with: 8
num_logs_parser called with: 5
priority_boost_parser called with: 4
name_format_parser called with: NONE
max_log_size_action_parser called with: ROTATE
space_left_parser called with: 75
space_action_parser called with: SYSLOG
verify_email_parser called with: yes
action_mail_acct_parser called with: root
admin_space_left_parser called with: 50
admin_space_left_action_parser called with: SUSPEND
disk_full_action_parser called with: SUSPEND
disk_error_action_parser called with: SUSPEND
use_libwrap_parser called with: yes
tcp_listen_queue_parser called with: 5
tcp_max_per_addr_parser called with: 1
tcp_client_max_idle_parser called with: 0
transport_parser called with: TCP
krb5_principal_parser called with: auditd
distribute_network_parser called with: no
q_depth_parser called with: 400
overflow_action_parser called with: SYSLOG
max_restarts_parser called with: 10
plugin_dir_parser called with: /etc/audit/plugins.d
No plugins found, not dispatching events
type=DAEMON_START msg=audit(1659130508.051:8760): op=start ver=3.0 format=enriched kernel=5.10.0-16-amd64 auid=1000 pid=20451 uid=0 ses=128 subj=unconfined  res=successAUID="csaba198" UID="root"
config_manager init complete
Error setting audit daemon pid (File exists)
type=DAEMON_ABORT msg=audit(1659130508.052:8761): op=set-pid auid=1000 pid=20451 uid=0 ses=128 subj=unconfined  res=failedAUID="csaba198" UID="root"
Unable to set audit pid, exiting
The audit daemon is exiting.
Error setting audit daemon pid (Permission denied)

 

Nem tudom, hogy ez segít-e valamit.
 

( e704112 | 2022. 07. 29., p – 20:57 )

Ami még érdekes, hogy ha csinálok egy symlinket:

 

ln -s /home/user/.virtualenvs/user/bin/python /usr/bin/pythonu

 

és ezt próbálom meg használni, az szintén nem megy, ám ha lemásolom:

 

cp /home/user/.virtualenvs/user/bin/python /usr/bin/pythonu

 

és ezt a pythonu-t állítom be shebangnak, no úgy már működik.

 

Ezt mi korlátozhatja így?

( NevemTeve | 2022. 07. 31., v – 15:09 )

Ebből csak annyit értek, hogy az X program elindítja az Y programot, de az egyszerűség kedvéért nem az erre kitalált fork/exec/spawn/etc rendszerhívásokkal, hanem a systemd bevonásával teszi ezt. Mondjuk azt már rég megtanultam az iparban, hogy minél több ilyen közvetítő komponens van egy rendszerben, annál gyorsabb és stabilabb.

igen, ezért örvendetes, hogy a dolgok általában már nem tényleg szarok, simán csak béla nem hajlandó megtanulni, aztán szenved vele, vagy elfogyott a hely.

Itt is épületes volt, hogy a selinuxot hogyan kell kipacsolnira kernel paraméter jött lendületből, ahelyett, hogy "setenforce 0, és úgy próbáld ki". (azt már meg se merem említeni, hogy elég egyértelmű volt, hogy a debianban nincs selinux.)

Off: Rasperry-s Linuxon is lehet ilyen seLinux? Mert a prog.hu-n valakinek olyasmi problémája van, amit én vaktában találgatva szintén a 'selinux vagy systemd' kategóriába sorolnék: nem tud a programja UDP-n fogadni, kivéve, ha ugyanakkor ugyanazon a gépen fut a WireShark is.

Aha. Két kommentel előbb meg helyeseltél.

Szerintem tényleg katasztrófa lenne ha egy 5 perces teszt erejéig valaki kikapcsolja a be sem kapcsolt selinuxot - én azt javasoltam -, nyilván rommá törik a gépét, pláne, hogy be sem volt kapcsolva, amit mertem feltételezni még előtte. Egyébként itt voltál, és akkor valahogy nem jutott eszedbe a setenforce 0, mert nem mondtad. A debianban meg van selinux, csak nem aktív, de hadd ne mi találjuk már ki, hogy esetleg nem volt-e mégis aktív, ezért be is linkeltem a setupját.

Amúgy cirka 25 éve basztatok linuxot, és képzeld, se apparmor, se selinux, se systemd nem volt jó sokáig, és mégsem törtek rommá naponta sokezer gépet. Sőt én egyiket se használom most se, de de törd fel a gépem nyugodtan!

Tőlem eljátszhatod a nagymenőt, meg a hipervédelmi hőst, mint zeller - aki kurvára előrébbvitte a probléma megoldását, ahogy szokta -, de akkor alaposabb legyél az ilyen utólagosan infószerzett beszólásoknál, mert kezd ciki lenni! :D

Amúgy cirka 25 éve basztatok linuxot, és képzeld, se apparmor, se selinux, se systemd nem volt jó sokáig, és mégsem törtek rommá naponta sokezer gépet. 

25 évvel, sőt, 20 évvel ezelőtt is sokkal kevesebb pénz volt ebben, ezért nem érte meg ezzel foglalkozni. Most már sokkal többen foglalkoznak Linux szerverek elleni támadással. Emiatt sokkal több támadási típus és támadási felület kerül felderítésre. Akkor is megvoltak a problémák, csak nem tudtál róla, mert nem foglalkozott vele senki.

:D

Ezek 15-20 éves security technológiák, a systemd meg elvileg nem is az lenne, szóval baromira beváltak, ha egyre több a sebezhetőség! Nyilván a linux szerverek baszogatása miatt tették bele még az Android telefonokba is, és nagy-nagy sikerrel védi a dalvik vm-et is!!!

De annak örülök, hogy tudod, hogy én miről tudtam!

Aha. Két kommentel előbb meg helyeseltél.

Mire?

A többit meg félreérted. Nem hipervédelmi hőst játszok (bár képzeld, én is úgy cirka 25 éve használok linuxot, és ennek egy elég jelentős részében vagy konkrétan securityval, vagy security érzékeny dolgokkal foglalkoztam), semmi baj nincs azzal, hogy kikapcsoljuk egy teszt erejéig. Egyszerűen csak arra jó példa ez az egész, hogy annyira nincsenek ezek a technológiák, hogy még a kikapcsolásnál is már ott tartottatok, hogy grubba turkáltatok, holott az egész egy darab command, aztán már lehet is megint tesztelni. És nem azért nem mondtam, mert nem tudtam, hanem mire ideértem (főleg érdemben) már rég túl voltatok rajta. Nyugodtan guglizd meg, hogy van-e itt sok évvel ezelőttről ilyen beszélgetés :)

Próbáltam utalni rá, hogy figyelmesebben fogalmazz, értelmezz de kár volt.

Konkrétan ezt írtam:

"Bár én a helyedben csak a bootkor írnám be, akkor csak arra az egy bootra vonatkozik, a grub.cfg marad eredeti."

Szerintem kb. értem mit kavartok itt, de én ebből kiszállok, mert gáz az egész. :D

A "permissive" mód pont azt csinálja, hogy _megy_ a SELinux, _de_ azok, amik "enforced" módban nem mennek, azok naplózás _mellett_ működni fognak. Ha és amennyiben ismernéd a SELinux működését, akkor ezt _is_ tudnád. De nem, te nem használod - gondolom, a shadow password is ördögtől való nálad, mint anno egy HP-UX-on láttam saját szememmel, miközben üzletileg kritikus alkalmazást használtak rajta, és unix-os userrel tudtak belépni...

Azért az kurva nagy, hogy 5 napig tartott amíg rájöttél, hogy a _nem_ használt selinuxot nem beállítani kell, hanem permissive módba kell tenni! :DDD

De legalább a szokásos ostoba módon játszod el, hogy mekkora ász vagy, és találgatsz vakon!

Baszki, 10 éve szórakozok Android és linux alapú custom ROM-okkal, a hybris kernelben speciel le kellett tiltani a selinuxot, de egyébként is sok ROM-ot permissive módban adnak ki, vagy egy su nélküli ROM-ban elég nehéz lenne a su-val váltani permissive-re, szóval kibaszott vicces ahogy a saját világodban magas a kerítés. :D

Én komolyan örülök, hogy végül maradtál a HUP-on, ennyi faszságot kevés ember ír le itt! :D

( e704112 | 2022. 08. 03., sze – 17:08 )

Amikor úgy nagyjából a 45. kommentnél kroozo rávilágított a megoldásra, eszembe nem jutott, hogy immáron ez lesz valószínűleg a 101. komment.

 

Persze, örülök, hogy ilyen sikeres topicot sikerült nyitnom, de remélem 200 nem lesz :- ). Az érdemi rész remélhetőleg nem veszik el.