Dotaz: Zamčení složek i pro rota

[Marko]

Dobrý den chtel jsem se zeptat, jestli jdou nejak zamknout slozky na serveru aby se na ne nedostal ani kdyz bude prihlaseny jako root, zni to mozna divne ale je to tak ;) Jde to prosim nejak? dik

Odpovědi

[petris]

Složky ne, ale adresáře jdou zamykat třeba pomocí LIDS

[tsLnox]

jakýže je rozdíl mezi složkou a adresářem?

[Filip Jirsák]

Složka je soubor nějakých prvků (třeba souborů), adresář je seznam adres. Pro "množiny" souborů je podle mne srozumitelnější používat termín složka, ale někteří "linuxáci" to nemají rádi, protože s tím asi přišel Microsoft v českých lokalizacích Windows.

[Michal Kubeček]

Pro "množiny" souborů je podle mne srozumitelnější používat termín složka, ale někteří "linuxáci" to nemají rádi, protože s tím asi přišel Microsoft v českých lokalizacích Windows.

O to ani tak nejde, podstatnější je, že termín složka vzbuzuje představu, že je soubor v nějaké složce uložen. Na unixových filesystémech je ale taková představa naprosto mylná a velmi matoucí: na nějaký soubor může být odkaz v deseti adresářích a nebo také v žádném.

[Filip Jirsák]

To ale neplatí jen pro unixové filesystémy, platí to i pro NTFS, pro síťové filesystémy (protože nikdy nevíte, jak je implementován ten skutečný filesystém, na kterém běží), a vzhledem k možnosti mountování různcýh (i síťových) filesystémů to platí prakticky pro cokoli – klidně můžete mít jeden soubor exportován jednou přímo z FAT a jednou z té samé FAT přes WabDAV a navrch ještě přes FTP – a hned máte jeden soubor ve třech umístěních.

Že to vzbuzuje nějakou představu, to by mi moc nevadilo, protože pokud už nad tím někdo přemýšlí, asi si dokáže najít, jak je to doopravdy. A běžného uživatele zmatete už tím, že má jednou svůj sdílený síťový disk dostupný jako R: (ve Windows), a podruhé to samé ještě jednou jako S:\user_name. A můžete tomu říkat složka nebo adresář, stejně to bude považovat za jeden z divů, co počítače umí.

Ostatně to samé se dá říci o adresáři – ten zase vzbuzuje představu, že jsou tam nějaké adresy. Což jednak nemusí být pravda, jednak adresy se vyskytují i na spoustě jiných míst, než jsou soubory. Zrovna na Linuxu, kde "všechno je soubor", je to přísné rozlišování na adresáře a složky takové všelijaké.

[Michal Kubeček]

Ostatně to samé se dá říci o adresáři – ten zase vzbuzuje představu, že jsou tam nějaké adresy.

V podstatě ano - číslo inodu je svým způsobem adresa.

[xkucf03]

No a? Uživatel pracuje s programy a s OS. Že tam jsou vespod nějaké inody pro něj není důležité, tomu se říká abstrakce. Názvosloví by mělo být srozumitelné koncovým uživatelům, aspoň pokud se spolu nebaví programátor jádra a autor souborového systému

[Michal Kubeček]

Ten rozdíl má důsledky, které jsou podstatné i pro uživatele. Projevuje se to např. na chování linků.

[petris]

Naopak je to pro něj velmi důležité. Když si na flashdisku udělá uživatel, který rozdíl složka/adresář ignoruje, složku locate:prace, potom přeformátuje disk a bude si chtít obnovit svojí "zálohu", tak bude koukat jako puk.

[Filip Jirsák]

To ale vůbec nepopisuje rozdíl mezi složkou a adresářem. Když si na tom flashdisku udělá jako zálohu symbolický link, dopadne úplně stejně. Když bude mít nějaký adresář namapován na dvou různých místech, dopadne taky stejně. A když bude mít odkaz na soubor, jehož obsah pak zkrátí na nulu, dopadne zase stejně.

Běžný uživatel nebude zkoumat, jak je která složka implementována, zda to zrovna je adresář nebo není adresář. A předpoklad, že soubor je obsahem složky, není špatný jen pro adresáře, ale i pro spoustu složek. Takže oblíbený argument, že složka je matoucí název, nemá žádnou oporu v praxi – pokud s nějaký uživatel myslí, že soubor je obsahem složky, tak si to myslí pro "objekt, v němž se mu soubory zobrazují v nějakém správci souborů". A je jedno, zda tomu objektu říká složka, adresář, directory nebo folder. Navíc se obávám, že byste marně hledali takového běžného uživatele, který bude mylně předpokládat, že soubor je obsahem složky, ale zároveň bude přísně rozlišovat mezi složkou a adresářem a bude chápat, co jsou to inody atd.

[petris]

Dobře, vyjádřím se přesněji. Jádro poskytuje procesům k práci soubory a adresáře jako určitý druh abstrakce nad daty. Protože LIDS pracuje na této vrstvě, upozornil jsem na to tazatele, protože se ptal na složky, takže LIDS by teoreticky nemusel být to, co hledá. Co jsem udělal špatně?

[Filip Jirsák]

Nevysvětlil jste, jaký je podle vás rozdíl mezi složkou a adresářem. Spousta lidí (a nejspíš i tazatel) to považuje za synonyma. A zrovna v tomhle případě nestačí říct, že jde o adresáře – jsou to adresáře souborového systému, jak je uložen na disku? Nebo jsou to adresáře přimountovaného souborového systému?

[Ash]

Já bych se to ani vysvětlovat nesnažil :D Budeme raději ti zlí RTFM linuxáci ;) Myslím, že to tazatel pochopí, až si bude chtít zabezpečit nějakou složku typu "Oblíbené", nebo třeba složku "Settings", "aby mu nikdo nehrabal do nastavení". Pak si třeba vzpomene na kolegu petrise, že říkal něco o tom, že LIDS zabezpečuje adresáře, ne složky :)

Taťka má třeba na Widlích v kořenové....... složce :D dvě různé složky, které se jmenují úplně stejně (Dokumenty). Ale jinak proti složkám nic nemám, aby někdo nemyslel.

[petris]

Nevysvětlil jste, jaký je podle vás rozdíl mezi složkou a adresářem.

Nikdo se na něj neptal, když se pak zeptal, tak jsem ho vysvětlil.

A zrovna v tomhle případě nestačí říct, že jde o adresáře – jsou to adresáře souborového systému, jak je uložen na disku? Nebo jsou to adresáře přimountovaného souborového systému?

Teď se budu opakovat, ale třeba Vám to předtím uniklo: adresář je prostředek operačního systému, kde ho jádro vyčaruje Vám může být jedno. Takže stačí říct, že jde o adresáře.

[Filip Jirsák]

Nikdo se na něj neptal, když se pak zeptal, tak jsem ho vysvětlil.

Pokud ten rozdíl považujete za zásadní, a tazatel mezi složkou a adresářem zjevně nerozlišuje, bylo by rozumné ten rozdíl vysvětlit rovnou. Zvlášť v situaci, kdy není neobvyklým jevem, kdy někdo bazíruje na tom používat v Linuxu název adresář v jakémkoli významu a složka je pro něj sprosté slovo.

Teď se budu opakovat, ale třeba Vám to předtím uniklo: adresář je prostředek operačního systému, kde ho jádro vyčaruje Vám může být jedno. Takže stačí říct, že jde o adresáře.

Pokud je adresář prostředek operačního systému, o kterém nemusím nic vědět, nemusím ani vědět, zda obsahuje soubory nebo jenom odkazy na ně. Nebo zda je to dokonce virtuální "filtr souborů". A pak je adresář plně ekvivalentní se složkou.

To ale rozhodně není tento případ, protože pro zabezpečení přístupu musím přesně vědět, čemu se přístupová práva nastavují. Je to adresář (prostředek operačního systému) v konkrétním souborovém systému na disku? Takže ať ten souborový systém připojím kamkoli, vždy se ta přístupová práva uplatní? Nebo je to adresář (prostředek operačního systému) určený umístěním v adresářové hierarchii počínající rootem? Takže když do /usr namountuji pokaždé jiný diskový oddíl, budou mít soubory se stejným názvem vždy stejná práva?

[xkucf03]

"locate:něco" je jen (pseudo)protokol v KDE, rozhodně bych těm výsledkům hledání neříkal složka ani adresář. Ani mi není moc jasné, jak by si mohl uživatel na flešce vytvořit "složku locate:prace" Jestli myslíš ten .desktop soubor, tak to je přece soubor a ne složka, něco jako .lnk ve Windows. Pokud už na toho zástupce klikne, tak se mu i změní url na locate:něco, takže bych si nědělal starosti, že by si to pletl se složkou/adresářem.

To je jako když ti Windowsí uživatel přinese něco na USB disku a pak ale zjistíš, že tam vytvořil jen zástupce, místo aby tam ty soubory nakopíroval. Z toho ale nelze vinit technologie nebo názvosloví, to je pohá demence uživatelů

[petris]

Složka je desktopový výraz a nemusí mít ekvivalent na disku. Například konqueror podporuje složku locate:vyraz, jejichž obsahem je to, co najde locate pro výraz vyraz. Případně když v mc otevřete rpm balíček, vidíte programy INSTALL a UNINSTALL(možná to není úplně přesně takto, s rpm jsem už dlouho nepřišel do styku), takže ten balíček se tváří je složka, ale není to adresář.

Myslím, že ten termín používal apple dřív než MS.

[Ash]

Také jsem pro to rozlišovat takto. Složka na desktop, adresář na disk. Když ls -ld zahlásí "d", tak to je directory, v opačném případě (ikona na desktopu s nejasnou vazbou na obsažená data) to může být folder. Navíc ls -f už má jiný význam :D

[outsider]

Nevim. nakolik je wikipedia duveryhodny zdroj, ale ...

"With the introduction of Windows 95, Microsoft started referring to directories as folders." (Murach's C# 2005, page 34)

[Ash]

To by ještě tak nevadilo, synonym si člověk může nadělat kolik chce, jenomže pak tu jsou ještě by "Speciální složky", což jsou z terminologického hlediska sice také složky, ale z faktického hlediska to nejsou adresáře.

Ten zmatek mi připomíná tohle: "staří dobří linuxáci" říkají kalhotám kalhoty, a košilím košile.

Okenáři přijdou s tím, že kalhotům se bude říkat nánožnice. Pak vymyslí něco, co se dá omotat kolem těla (hodně to připomíná sukni) a začnou tomu říkat taky nánožnice.

V tu chvíli vznikl problém, a myslím že nemůžeme nikoho prudit za to, když se v určitou chvíli důsledně vrátí ke starému dobrému "kalhoty" ve chvíli, když si třeba chce koupit kalhoty, a v obchodě mu nabízí něco, co ze všeho nejvíc připomíná sukni a říkají tomu speciální nánožnice.

[narg]

Tipoval bych že by to neměl být problém pomocí SELinuxu.

[atan]

a k cemu by to bylo?

[Josef Kufner]

Snažit se zabránit rootovi aby dělal cokoliv je poněkud pošetilé... jediné co je schopné tvá data uhlídat je šifrování.

[petris]

Nasměrujte svůj prohlížeč na www.lids.org, přečtěte si dokumentaci a potom své tvrzení přehodnoťte.

[Filip Jirsák]

Vzhledem k tomu, že je tam nějaký soubor patch a nějaké .tar.gz, tipoval bych si, že se jedná o software. A ten těžko může zabránit tomu, aby si root nainstaloval upravenou verzi téhož společně s keyloggerem, a až bude uživatel k daným datům přistupovat, prostě si heslo odchytí (nebo si ta data přečte rovnou z paměti). Před rootem, který má právo na vyměnit jádro, vás ochrání jedině (de)šifrování v externím zařízení, které root nemá pod kontrolou (tj. např. čipová karta, kam pošlete hash, zadáte přímo na ní pin a ona vrátí hash podepsaný či zašifrovaný). Vzhledem k tomu, že root může číst celou paměť, je i tohle použitelné jen pro jednorázová hesla nebo podpisy – jakmile takhle něco rozšifrujete, má root možnost si to přečíst (ale nezná heslo a nedostane se k ničemu, co jste zatím nerozšifroval). Pravda, ještě je jedna možnost – DRM. Tedy že hardware zabrání běhu neautoriovaného kódu, třeba nepodepsaného jádra.

[petris]

Zřejmě jste se o to moc nezajímal, proto než budete znovu reagovat, tak si alespoň přečtěte, co ten software dělá. Jádro samozřejmě jde modifikovat tak, aby některé akce nemohl provést ani root. Celý Váš příspěvek je nesmysl.

[Filip Jirsák]

To by mne zajímalo, jak takové modifikované jádro zabrání tomu, aby root vypnul jistič, vyměnil jádro za takové, které mu umožní některé akce provést, a nabootoval s tímhle novým jádrem.

[Michal Kubeček]

To je ovšem dost podstatný rozdíl, jestli se bavíme o "někom, kdo je přihlášený jako root" a "někom, kdo má fyzický přístup k počítači a šroubovák a rescue CD v kapse".

[Josef Kufner]

Roota obvykle mívá majitel serveru a ten mívá i fyzický přístup. Pokud je to někdo jiný a není důvěryhodný, nemá mít roota.

[dustin]

Jo, teorie a praxe :)

[Michal Kubeček]

1. Mám třeba roota (legálně) na jednom serveru, ke kterému je fyzický přístup dost problematický (je to 60 kilometrů daleko, dostat se tam dá jen ve všední den v pracovní době a ještě se musím předem domluvit. Majitel toho serveru tam nemá roota vůbec (stejně by nevěděl co s ním).

2. Nástroje, o kterých je tu řeč, jsou určeny právě pro případ, kdy přístup na úrovni roota (nebo kontrolu nad démonem, který pod rootem běží) získá někdo, kdo ho mít nemá. Samozřejmě by se to stávat nemělo, ale chyby se dějí a jedna pojistka navíc není k zahození.

[Dejv]

... a není důvěryhodný ...

Čtěte.

[Michal Kubeček]

Čtěte také. Toho se týká bod 2.

[Filip Jirsák]

Reset počítače vypnutím jsitiče jsem uvedl pro zjednodušení. Důležité je, zda má možnost změnit jádro. K tomu stačí mít možnost restartovat počítač a buď přepsat původní jádro, nebo změnit parametry zavaděče. Nedovedu si představit, že by root měl tak omezená práva, že nebude moci ani zavést jiné jádro. Pak by stejně musel existovat někdo jiný, kdo by tohle právo měl – tj. ekvivalent roota. Prostě kdo zavádí do počítače operační systém, ten má nad počítačem a vším, co se v něm děje, absolutní moc. Alespoň pokud se bavíme o dnešních běžných PCčkách.

[dustin]

Lids jsem moc neznal, ale stačí pár minut, aby člověk našel základní informace, jako např. http://www.roedie.nl/lids-faq/html-multiple/unusable-system.html

4.6. Help!!! My system is totally unusable! What do I do?

You can reboot into a non-LIDS enhanced kernel, or boot into your LIDS enhanced kernel with LIDS disabled to try and patch things up. To boot with LIDS disabled, specify lids=0 at the lilo prompt. For example, if your LIDS enhanced kernel is called lids-kernel you would enter the following at the lilo prompt:

lilo: lids-kernel lids=0

That's the easy part. The difficult part is getting your LIDS enabled system to shutdown. You may not be able to shutdown successfully depending on your LIDS configuration.

Pokud root nebude mít právo zápisu do konfigurace boot manageru, nemá šanci vzdáleně rebootnout do jiného kernelu.

[Filip Jirsák]

Pokud root nebude mít právo zápisu do konfigurace boot manageru, nemá šanci vzdáleně rebootnout do jiného kernelu.

Na to nepotřebuje právo zápisu, třeba s grubem tu konfiguraci může změnit během bootu (při troše dobré vůle ze strany toho, kdo grub konfiguroval, dokonce i po síti).

[Michal Kubeček]

I s tím GRUBem se to ale dá nastavit tak, že bez nabootování z vlastního média (tj. při rozumném BIOSu bez otevření počítače - bohužel je rozumných BIOSů čím dál méně) tu konfiguraci nezmění. U permanentně běžícího serveru bych takovou konfiguraci považoval za standardní volbu.

[dustin]

Samozřejmě jsem nepředpokládal, že útočník má přístup k bootovací konzoli grubu při restartu - to už může bootnout z CD nebo třeba vyměnit server :) Všechno je to o vzdáleném přístupu, jak již bylo výše uvedeno.

[Jiří J.]

Buď pro výměnu kernelu netřeba reboot nebo jsem nepochopil kexec

[Michal Kubeček]

Myslíte, že vám při nasazení zmíněných prostředků správce serveru nechá něco takového povoleného?

[Jiří J.]

Myslím, že není nepřehlédnutelný...

[Michal Kubeček]

Pokud se konfigurace bude vytvářet podle principu "a priori všechno zakážu a pak povolím, co bude potřeba", pak přehlédnutí typicky vedou spíš k nefunkčnosti než k bezpečnostní díře.

[petris]

Dobře, můžeme uzavřít sázku. Dám Vám root účet na stroji, kde bude Vaším úkolem přečíst soubor. Cena by mohla být například toto.

[Michal Kubeček]

Doufám, že mu dovolíte aspoň spustit příkaz id, aby si mohl aspoň ověřit, že ten uživatel root má opravdu UID nula. :-)

[Filip Jirsák]

Obávám se, že rozepře v diskuzi je příliš malá motivace na to, aby se někdo pokoušel dostat do byť jen minimálně zabezpečeného počítače. Předpokládám ale, že pokud někdo chce zabezpečit něco před rootem, důvodně očekává, že motivace protistrany bude mnohem vyšší – a bude tedy ochotna shánět kde se server fyzicky nachází, případně se k němu i fyzicky dostavit, bude ochotna zkoumat různé potenciální slabiny, věnovat se pokusům něco vymámit z uživatelů atd.

Uzavřel bych to tím, že systémy jako SElinux nebo LIDS zvyšují bezpečnost, ale nejsou absolutně bezpečné. A zrovna obrana proti administrátorovi serveru je v Linuxu záležitost značně obtížná, až nemožná. Pokud vím, SElinux nebo LIDS mají chránit systém před chybami v aplikacích, které běží pod právy roota. Což je trochu něco jiného (a jednoduššího), než chránit server před člověkem, který ma ten server na starosti.

[petris]

Dotaz zněl jak zamezit přístupu roota někam a ne jak zabezpečit počítač proti někomu, kdo se k němu vloupá a ukradne/rozebere ho. Když někdo chce zabezpečit něco před rootem, dělá to třeba proto, aby mu případný průnik způsobil co nejmenší škody, aby útočník třeba neukradl soubory s důležitými daty. Pokud Vám jde o malou motivaci, můžeme ji zvýšit - navrhněte jak.

Z Vašeho příspěvku mám pocit, že nejste schopen přiznat svůj omyl a snažíte se to hodit na to, že jste vlastně od začátku předpokládal, že na ten stroj někdo fyzicky zaútočí z bezprostřední blízkosti (což je úplně mimo původní dotaz).

[Filip Jirsák]

Nikoli, každý ten dotaz chápeme jinak. Vy ho chápete jako „já jsem root na serveru a chci ten server zabezpečit tak, aby i když někdo např. ovládne aplikaci, která běží pod rootovskými právy, a dokáže z ní spouštět svůj kód, mohl napáchat co nejméně škody“. V takové situaci jsou SElinux nebo LIDS ty správné nástroje, a hned první dva komentáře je zmiňují.

Já dotaz chápu jako „někdo mi nainstaloval počítač a administruje ho, já ale potřebuju něco schovat tak, aby to ani on nemohl najít“ nebo dokonce „jsem běžný uživatel na počítači a mám tady něco, co by root neměl vidět, potřebuji to před ním schovat“ (např. žák ve škole hry). Ve druhém případě je SElinux i LIDS úplně k ničemu, protože je jako běžný uživatel nemůžete použít, v prvním případě sice můžete rootovi říct, že má nainstalovat a nakonfigurovat SElinux, al ezase vám nezbývá, než mu věřit, že to udělal a že si tam nikde nenechal zadní vrátka.

Nebo se to dá říci i jinak. Všechny zmíněné nástroje brání roota před sebou samým, případně před útočníky, kteří získají práva roota (a tam pak opravdu „stačí“ zamezit fyzickému přístupu k počítači a ošetřit síťové vstupy – např. již zmíněnou konfiguraci grubu). Ale neexistuje nástroj, který by před rootem chránil běžného uživatele (protože v takovém případě nestačí bránit budoucím útokům, ale potřeboval byste mít i jistotu, co se dělo s počítačem dříve – zda už tam nejsou nějaká zadní vrátka).

Pokud byste chtěl vyvrátit to, o čem píšu já, musela by sázka znít jinak – já nainstaluju počítač, dám vám k němu přístup běžného uživatele a vy na tom počítači něco schovejte tak, abyste byl schopen to v budoucnosti jen s prostředky toho počítače zase využít, a abych se k tomu já jako root nedostal. Ale stejně z toho nic nebude, protože já se nesázím z principu

Asi nemá smysl se přít, co měl na mysli původní tazatel, to by nám mohl zodpovědět jedině on.

[0man]

Autor by mel opravdu presne specifikovat, o co mu jde.

Bud mu nekdo spravuje server a chce pred nim schovat data, pak je asi nejlepsi ty data sifrovat (gnupg, x509) na vlastni stanici a posilat na server zasifrovane.

Nebo se boji toho, ze mu muze server nekdo ukrast/zabavit a pak se dostat na data, pak by mu mohlo stacit pouzit transparentni sifrovani (truecrypt, cryptsetup-luks, encfs).

Nebo chce chranit server pred napadeni nejake sluzby, ktera bezi s pravy roota, pak by mel asi pouzit ty SElinuxy a LIDSy a podobny. (ale mam dojem, ze o tohle tady nejde.)

[Michal Kubeček]

Pak by stejně musel existovat někdo jiný, kdo by tohle právo měl – tj. ekvivalent roota.

On to právě není ekvivalent. Vzhledem k nešťastné historické koncepci oprávnění (root může všechno - a ledacos může jen root) je potřeba aby pod rootem běžela řada procesů z naprosto malicherných důvodů, třeba jen proto, že potřebují poslouchat na portu s číslem menším než 1024. Systémy jako SELinux, LIDS a svým způsobem i AppArmor existují právě pro případ, kdy nad takovou aplikací získá kontrolu někdo s nekalými úmysly.

[Filip Jirsák]

Ano, napsal jsem to nepřesně. Ten, kdo má právo vyměnit kernel, má nad počítačem absolutní moc. Před rootem tedy zabezpečit lze, před tím-kdo-může-vyměnit-kernel ne.

[xkucf03]

je potřeba aby pod rootem běžela řada procesů z naprosto malicherných důvodů, třeba jen proto, že potřebují poslouchat na portu s číslem menším než 1024.

Pokud je číslo portu jediným důvodem, tak přece můžeme použít přesměrování pomocí iptables. Služba běží na vyšším portu a z privilegovaného se na něj přesměrovává.

K té koncepci: vždycky musí existovat nějaký "vlastník" počítače, který si s ním může dělat úplně cokoli. Nepřál bych si mít stroj, který bych nemohl (v případě potřeby) plně ovládat. Co někdy asi trochu chcbí, je možnost, delegovat některá práva na jiné uživatele. To ale také není neřešitelné - viz třeba Solaris.

[Michal Kubeček]

K té koncepci: vždycky musí existovat nějaký "vlastník" počítače, který si s ním může dělat úplně cokoli.

Ve fyzickém smyslu ano. Ale není důvod, proč by to musel být jeden speciální uživatelský účet.

Lépe to samozřejmě vyřešit lze. Že to jde i v Linuxu, to ukazují právě zmíněné nástroje typu SELinux, LIDS, AppArmor apod. I když trochu překvapivě (aspoň pro mne) ale všechny jdou cestou omezení navíc, žádný nepočítá s tím, že by naopak povolil přidělování capabilities procesům s nenulovým EUID.

[Filip Jirsák]

I když trochu překvapivě (aspoň pro mne) ale všechny jdou cestou omezení navíc, žádný nepočítá s tím, že by naopak povolil přidělování capabilities procesům s nenulovým EUID.

Ono je to překvapivé z pohledu uživatele – ten by samozřejmě radši přidělil procesu jen právo naslouchat na portu 80. Ale z pohledu programátora chápu, proč je to zrovna takhle – je to stará dobrá zásada nesahat na něco, co funguje. A přístupová práva jsou na Linuxu (a unixech) léta ověřená a funkční, a přidělování capabilities nenulovým EUID by znamenalo dělat do tohohle systému díry. Což se samozřejmě nikomu nechce.

[Michal Kubeček]

Já bych spíš řekl, že se v praxi ukázalo, že přístup založený na kombinaci

• proces s EUID==0 smí provést jakoukoli privilegovanou operaci
• kteroukoli privilegovanou operaci smí provést pouze proces s EUID==0

je z bezpečnostního hlediska naprosto nevhodný. Odlišné bezpečnostní modely jdou cestou výjimek z prvního pravidla. Já se snažím naznačit, že i když to vypadá na první pohled nesmyslně, mohlo by bezpečnost zvýšit i zavedení výjimek z druhého pravidla (protože by pak nemuselo tolik procesů celkem zbytečně běžet pod rootem).

[xkucf03]

To by chtělo Role-based access control ze Solarisu.

[petris]

Tak pro ty procesy je možné napsat zavaděč, který se po startu vzdá všech nepotřebných oprávnění a pak execne vlastní proces. Případně webserver může zavolat socket, získat tak soket pro port 80, a pak si změnit uživatele.

[Josef Kufner]

Tím ale problém nevyřešíš, jen obejdeš (a běžně se tak obchází).

[stativ]

A zatím jediným řešením by bylo používání souborových kvalifikací (file posix capabilities). Akorát by se musely dostat do jádra a taky rozšířit. Přičemž hlavně to rozšíření je hodně velký problém. A další problém je, že podpora pro kvalifikace zatím není napsaná snad ani pro jeden FS.

[ivan]

Dalsi moznosti, ktera ale neni sama o sobe uplne samospasitelna je tzv. princip 4 oci. Takove vec se da nastavit treba na AIXu(ten nema pam moduly). Uzivatel root sam nema heslo a k prihlaseni na roota potrebujete hesla alespon dvou adminu.