Jak jsem chtěl a nechtěl poznat nepřítele (diskuse)

[Grunt]

Co core dump? Zachoval se?

[trekker.dk]

Tak mi tak skončil systém v kernel panice...

V poslední době se mi děje totéž při uspávání. A samozřejmě jsem za poslední dobu měnil dost věcí (verzi jádra, používanou síťovou kartu, disky), abych nevěděl s jistotou, co za to může.

[Jan Drábek]

Pokud člověk potřebuje jen e-mail, webový prohlížeč a přehrávač mp3 je celkem jedno co má za systém. Mě ale chyběl koníček, šťourání se ve fungujících věcech, které by mohly být lepší. Chyběla mi ta pověstná kontrola, já jsem root a kdo je víc, takové to, co zase hrabe na disk? Který proces drží ten zatracený flashdisk? A ze všeho nejvíc mi chyběl pacman! Prostě ta nemohoucnost mě dožírala každý den, na druhou stranu ta lenost, proč to přeinstalovávat, když to vlastně funguje... To zas bude doba, než to všechno nastavím a tak...

Přesně má slova!!!

[otasomil]

1+ Nemam co bych dodal tez.

[Grunt]

Jde u Windowsů vůbec nějak zjistit, který program hrabe na disk? To by bylo víc než užitečné.

[Vantomas]

Od Vista je zde aplikace "sledovani prostredku", ktera umi ukazat vyuziti CPU, Disku, Site a RAM u kazdeho procesu zvlast.

[Grunt]

Jo, to že umí zobrazit i I/O přístupy už od XP, to vím, ale co se pamatuju, tak to nebylo nic moc a moc dobře podle toho nešlo vyšmelit kam to šahá a jak moc si toho bere jako třeba z iotopu.

[Grunt]

A pokud se ještě víc pamatuju, tak to zobrazovalo jen uživatelské procesy a ne služby a jiné důležité skryté součásti.

[Michal2]

Pamatujes si to blbe. Jsou tam vsechny procesy i system akorat u svchost musis podle PID pak patrat ktere sluzby pod danym procesem bezi coz ale neni problem), jsou tam i zapisy do systemovych oblasti souboroveho systemu (MFT, transakcni log, bitmapa volneho mista) a do pagefile. Sloupce tam jsou PID, cteni B/s, zapis B/s, IO priorita, latence posledniho cteni. Suma sumarum vice informaci nez ti da IOstat minimalne o tu latenci.

[Grunt]

Tak to musím restartovat a přesvědčit se na vlastní oči.

[Grunt]

Příloha:

• sledování_spolehlivosti_a_výkonu.png (0 bytů)

Fíha, no fakt že jo. Jinak se to jmenuje Sledování spolehlivosti a výkonu. Tak to bych nikdy neřekl.

[Jan Grmela]

Tak tohle vidím prve. Díky, hádám mi to sníží počet sprostých nadávek na počítače zákazníků

[pht]

Nechci bejt hnidopich, ani "anti-...", ale když už spravujete u zákazníků windows, tak co si o nich něco přečíst?

[Jan Grmela]

Možná to bude tím, že to není můj hlavní zdroj obživy (díky bohu). Přiznám se bez mučení -- lenost zvítězila.

[kotyz]

neco od byvalych sysinternals, diskmon se to myslim jmenovalo. taky maji spoustu dalsich vymakanejch utilit napr. autoruns nebo process explorer.

[rastos]

Process Monitor a Process Explorer - dva najužitočnejšie Windows-only nástroje.

[pht]

Chyběla mi ta pověstná kontrola, já jsem root a kdo je víc, takové to, co zase hrabe na disk?

Tohle je hovadina. V každém OS, včetně windows, je administrátor absolutním pánem. To, že standardní klikací rozhraní tento pocit nenavozuje, je jiná věc (ostatně KDE4 systemsettings ho taky nenavozují).

[frdrx]

U Windows nejsi absolutním pánem ty, ale Microsoft.

[pht]

jistě

[Aleš Kapica]

Přesně tak. Zrovna tuhle mě fuckovala jedna aplikace při pokusu o instalaci s tím, že na to abych mohl zapisovat do registrů musím být administrátor. A to jsem byl přihlášen jako administrátor!

[pht]

Nesprávné ošetřování chyb a lhaní uživateli nemá nic společného s OS, nýbrž s aplikacemi. Takové aplikace byly, jsou, a budou na všech OS.

[Fluttershy, yay!]

Jakoby OS nebyl aplikace.

[pht]

Uff. Tak znova. Lhaní uživateli má na svědomí ta aplikace, která tu hlášku vypsala. Nemá to nic společného se skutečnou příčinou chyby. To, že jako administrátor můžete docílit všeho, s tím také nemá nic společného.

[rastos]

Keď sa prihlásiš do Visty/Win7 ako Administrátor (alebo člen skupiny Administrátorov) tak procesy tebou spustené (za normálnych okolností) nemajú práva Administrátora. Hnus.

[pht]

Já bych to neviděl jako hnus, ale jako začátek něčeho čemu se normálně říká přístup založený na rolích (role based access). Když někdo spustí celou KDE session pod rootem, tak je to hnus taky, ne? Ale uživatel a sudo ala blbuntu už je pánovi po chuti? No vidíte, tak UAC ve win funguje podobně.

[rastos]

Já bych to neviděl jako hnus, ale jako začátek něčeho čemu se normálně říká přístup založený na rolích (role based access).

Role sú pre užívateľov. A skupiny. Root má byť root.

Ale uživatel a sudo ala blbuntu už je pánovi po chuti?

Neviem. Nikdy som to nebežal viac ako 5 minút vo virtualboxe? V Ubuntu, keď sa prihlásim ako root (euid==0) tak mi odmietne zmazať /etc/passwd z filesystému, ktorý nie je read-only? Ak áno, tak je to hnus aj tam.

[pht]

Role sú pre užívateľov. A skupiny. Root má byť root.

Ale kdeže. Role jsou tím zajímavější, čím více privilegií je ve hře.

Neviem

Tak jinak. Uživatel a su je po chuti? Nebo valíte celé grafické rozhraní přes roota? Znova: To hnus není? (přihlášení pod Adminem ve woknech je ekvivalent tomuto)

V Ubuntu, keď sa prihlásim ako root (euid==0) tak mi odmietne zmazať /etc/passwd z filesystému, ktorý nie je read-only?

Neodmítne. A jak to souvisí s tématem?

[rastos]

Tak ešte raz:

Bežať grafické prostredie ako root - to je bezpečnostné riziko, ktoré ako správca systému môžem a nemusím vyhodnotiť ako prijateľné a OS mi do toho nemá čo hovoriť. Ale o tom reč vôbec nie je.

Hovorím o prípade, kedy som zadal heslo pre správcu systému a dostal som k systému prístup. Či už som ho dostal na Linuxe cez gdm/kdm/su/ssh/telnet/getty/... to je fuk. Raz som sa autentifikoval ako root, tak som root a každý proces, ktorý spustím a ktorému explicitne tie práva nezhodím, beží ako root a má práva ako root. A triviálna operácia ako zmazanie súboru mi nebude tvrdiť, že permission denied.

Na Viste/Win7 zadám heslo Administrátora => prihlásim sa ako Administrátor, procesy v task manageri tvrdia, že bežia ako Administrátor a napriek tomu nemajú prístupové práva Administrátora. A odmietnu urobiť triviálnu operáciu akou je zmazanie súboru s tým, že "permission denied". Navyše rozhodovať o tom, či proces má, alebo nemá prístupové práva na základe toho, či sa program volá setup/install/update, alebo nie ... je kravina ako hrom.

Na rozumnom systéme očakávam, že child procesy dedia security context rodičovského procesu. Ak sa prihlásim ako Admin vo Windowsoch, tak dostanem "shell" - prostredie umožňujúce spúšťať ďalšie procesy. A buď môžeš povedať, že dedenie security contextu medzi rodičovským a child procesom vo windowsoch nefunguje, alebo shell, ktorý si dostal po prihlásení ako Admin nemá security context Admina. Tak či onak oboje označujem za hnus.

[pht]

Raz som sa autentifikoval ako root, tak som root a každý proces, ktorý spustím a ktorému explicitne tie práva nezhodím, beží ako root a má práva ako root.

Tohle je UNIXový bezpečnostní model. S ním jsme si už užili dost, takže zkuste akceptovat, že existují i jiné modely. Například ten, že když se přihlásíte jako správce, tak nebude mít každý Váš proces práva správce, ale pouze ty, kde to explicitně povolíte. Aneb přihlášením na správce dostanete možnost něco takového povolit. Tento model je podstatně robustnější než UNIXový, neboť podstatně zužuje rozptyl toho, co můžete jako správce napáchat a přitom Vás v ničem neomezuje.

A odmietnu urobiť triviálnu operáciu akou je zmazanie súboru s tým, že "permission denied".

Možná to odmítne udělat triviálním způsobem, ale to je totéž jako když se Vás rm zeptá, jestli opravdu chcete.

Navyše rozhodovať o tom, či proces má, alebo nemá prístupové práva na základe toho, či sa program volá setup/install/update, alebo nie ... je kravina ako hrom.

IMHO to je jen o tom, že takové aplikaci povolíte všechno jednou, na rozdíl od povolování každé akce zvlášť. Jestli to je dobře nebo špatně je na diskusi, ale je to rozhodně lepší než ten Váš root-only model.

Na rozumnom systéme očakávam, že child procesy dedia security context rodičovského procesu.

Tohle je nesmysl i na UNIXu, viz seteuid. (Ano, při forku práva zdědíte, ale vzápětí je vykonáním spustitelného souboru ztratíte. Forkovat donekonečna jeden program není asi to co jste myslel.)

shell, ktorý si dostal po prihlásení ako Admin nemá security context Admina.

Kontext admina máte a opravňuje Vás k akcím, kterými můžete nakonec udělat co chcete. To je prostě fakt a za tím si stojím.

[Fluttershy, yay!]

Že jsem superuživatel znamená, že můžu všechno. Najednou přijde kdosi s nápadem, že superuživatel nebude moci všechno. To ale popírá jeho podstatu! Prostě superuživatel může všechno a ne aby musel pořád potvrzovat, že to opravdu chce udělat.

Že existuje jiný přístup může být třeba fajn, ale sem hom necpat! Tady je rootovo!

[petr_p]

Přesně tak.

Z toho můžu vyrůst, když uživatel ve skupině Administrators chce něco v nějakém adresáři (třeba domovském jiného uživatele) udělat. Systém mu to nedovolí. Podívám se na ACL k danému adresáři, tam je výslovně uvedeno, že skupina Administrators má plný přístup, přesto to nefunguje. V ověřovacím dialogu, kde člověk zadá svoje ID mu to ale vrátí, že má plná efektivní práva. Člověk musí explicitně danému adresáři přiřadit ACL záznam pro svoje ID, přitom se ho systém zeptá, jestli jako opravdu hodlá měnit ACL, pak musí prijít dialog znovu pod změněným kontextem a nakonec vše funguje.

Když jsem si četl, proč to je tak šíleně udělané (pomyslná kompatibilita, možnost nechat uživatele pracovat pod superuživatelským účtem a přesto blokovat privilegované operace), tak jsem hledal sáček na zvracení.

Víte co je nejzábavnější? Že runas cmd.exe dá úplně jiný kontext, než když člověk myší v nabídce vykliká spustit cmd.exe jako administrátor.

[pht]

Že jsem superuživatel znamená, že můžu všechno.

Například odpálit ICBM?

[rastos]

Příloha:

• shot.png (0 bytů)

Možná to odmítne udělat triviálním způsobem, ale to je totéž jako když se Vás rm zeptá, jestli opravdu chcete.

Nie, to nie je to isté. Viď príloha. Na Win7 člen skupiny Administrators spustil zo štart menu cmd a skúsil v ňom urobiť kópiu súboru MSASCui.exe v adresári "C:\Program Files\Windows Defender\". V Task Manageri vidno, že proces cmd beží pod užívateľom, ktorý je členom skupiny Administrators. Napriek tomu, že môže čítať zdrojový súbor a má Full práva na cieľový adresár, dostáva "Access denied". Nie je to preto, že by "copy.exe" malo suid na iného užívateľa, alebo sa na základe niečoho rozhodlo, že tú kópiu nechce spraviť. Ono skutočne ten OS API call vráti "Access denied".

[pht]

Tak ještě jednou a ještě jinak. Práva uživatelů na souboru jsou možná podmnožina politiky, ale není to celá bezpečnostní politika.

# ls -ld /etc /etc/shadow         
drwxr-xr-x 76 root root   8192 Dec  9 08:27 /etc
-rw-r-----  1 root shadow  798 Nov  3 14:45 /etc/shadow
# echo $EUID $UID
0 0
# rm /etc/shadow                                
rm: cannot remove `/etc/shadow': Permission denied     

Vidíte? Ani to nebolelo. Můžete mít přinejmenším nainstalovaný kernel modul, který příslušný syscall odchytí a zamítne. Můžete to tak mít ve windows, v linuxu, kdekoliv. Dělá se to z různých důvodů od bezpečnosti až po kompatibilitu, jak naznačil kolega petr_p. V žádném případě to ale nemění nic na tom, že jako administrátor systému nebo jako člověk který stojí fyzicky u systému máte možnost eventuelně dosáhnout svého (například odnahrát ten modul a smazat).

Už Vás slyším říkat "ale..."; jenže ono žádné "ale" není. Prostě to tak je, a i když byste rád slyšel, že UNIX a rwxrwxrwx je ta jediná a nejlepší bezpečnostní politika, tak to prostě tak není. UNIX byl navržen pro sdílení dat mezi pracovníky-kamarády a celá jeho multiuser filozofie je jen o tom, aby pepa nepřepsal omylem frantovi výsledky měření.

A ještě něco, co se Vám bude špatně poslouchat. UAC ve vistě je ve výsledku lepší systém zabezpečení než v Linuxu. Například fakt, že prohlížeč webu včetně všech skandálně nebezpečných pluginů běží sám od sebe v kontextu ve kterém nemůže přímo nikomu ublížit. Tohle dělá v Linuxu defaultně snad jen Fedora, ale tam SELinux hned vypínáte, že?

[rastos]

# rm /etc/shadow                                
rm: cannot remove `/etc/shadow': Permission denied     

Vidíte? Ani to nebolelo. 

Máš tam nejaký hnus

# ls -ld /etc /etc/shadow
drwxr-xr-x 66 root root 4480 Dec  9 10:44 /etc
-rw-------  1 root root 2269 Nov 18 09:36 /etc/shadow
# rm /etc/shadow
# ls -ld /etc /etc/shadow
ls: cannot access /etc/shadow: No such file or directory
drwxr-xr-x 66 root root 4456 Dec  9 10:45 /etc

Zafungovalo mi to na Slackware aj na Gentoo.

Můžete mít přinejmenším nainstalovaný kernel modul, který příslušný syscall odchytí a zamítne. Můžete to tak mít ve windows, v linuxu, kdekoliv. Dělá se to z různých důvodů od bezpečnosti až po kompatibilitu, jak naznačil kolega petr_p.

Či ten syscall vykoná program P alebo jeho child, alebo child toho child-u je v Linuxe jedno. Chová sa to konzistentne. Ale keby aj nie, tak ja som tvrdil (a preukázal) len toľko, že na Win7 sa to nechová konzistentne.

Prostě to tak je, a i když byste rád slyšel, že UNIX a rwxrwxrwx je ta jediná a nejlepší bezpečnostní politika, tak to prostě tak není.

Nedomýšľaj si, čo by som ja rád počul. Nemusíš sa trafiť.

/me ide obnovit shadow z backup-u

[pht]

na Win7 sa to nechová konzistentne

Chová se to konsistentně v souladu s instalovanou bezpečnostní politikou. Instalovaná politika nemusí být na každém systému "uživatel root může všechno" a/nebo "práva na souborech jsou veškerá pravidla".

Nedomýšľaj si, čo by som ja rád počul. Nemusíš sa trafiť.

Je dost jedno, jestli něco nechcete slyšet, nebo jen ignorujete. Výsledek je stejný.

[petr_p]

Problém je v podání typickém pro Microsoft – dané politiky není možné změnit nebo nejsou dokumentované. Efektivně běžný správce (bez nadstandardních vztahů s Microsoftem) si může akorát tak zoufat.

[Fluttershy, yay!]

...já jsem root a kdo je víc...

Chuck Norris.

[Mrkva]

nefunguje mi čtečka otisků prstů, na kterou jsem si nehorázně zvykl,

Fprint nefunguje?

[vogo]

jsem starej mazák a AuthenTec 2810 opravdu nepremává

[disorder]

no, mal som si najskor precitat diskusiu. mam to iste :(

[otasomil]

Linuxove distribuce jsou vicemene koncipovane, aby zacinajicimu uzivateli usnadnili prechod z windows.

Ovsem naopak ... to je peklo.

Toto ovsem uzivatele windows z principu jejich binarni povahy nemohou pochopit, ze nekdo se chce vrtat a drapat i v takovychto vecech.

Nedavno jsem testoval staricky notebook na win 7 a jak rychle jsem vratil Grub a Minisys.

A to jsem pouzival jen moji kolekci portable aplikaci na flashce, tzn nic jsem nemusel do widli pracne a zdlouhave instalit.

[Michal2]

co zase hrabe na disk? Který proces drží ten zatracený flashdisk?

To je spis neznalost nastroju pro windows. Process explorer ma v sobe neco jako lsof/fuser. Sledovani prostredku ti zas ukaze ktery proces do ktereho souoru zapsal/precetl kolik bajtu v nastavenem intervalu.

[vogo]

ale pořád to není ono, jinak sledování prostředků není zlé, ovšem než se k tomu člověk prokliká, lsof je lsof

[rastos]

Taký Process Explorer ti vie napr. povedať ktorý z threadov vyťažuje CPU a stacktrace toho threadu. Proces Monitor ti vie povedať, čo program prečítal v danom čase z handlu. A vidíš to v reálnom čase. Robiť niečo podobné pomocou lsof a strace nie je to pravé orechové.

[disorder]

asi mam podobny kus hw, tiez nemam driver na citacku, na ktoru som si na starom nb zvykol...

[Limoto]

Fiha, jak dlouho u těch vidliček setrvals?

[vogo]

od září... snad už nikdy víc

[jose17]

ovšem v tomhle případě sebou smetl i souborový systém, lépe řečeno jsem nenabootoval.

no tak zrovna vcera sa mi stalo presne to iste. zvlastne bolo aj to, ze fsck nic nehlasil az kym nedostal force flag. zato potom sa ale rozbehol. v lost+found rootovskeho fs mam 240 fajlov, dokopy 19 mb dat. nastastie pacmanovska databaza bola ok, takze stacilo zistit (po chrootnuti), ktore subory z nainstalovanych balikov chybaju vo filesysteme a preinstalovat. no a od vcerajska uz / radsej mountujem ako ordered.