Více kohoutů na jednom smetišti.

17.10.2011 09:52 | Přečteno: 1394× | Za vším hledej Linux | poslední úprava: 17.10.2011 09:52

Tento blog je spíš než blogpostem pokusem o vyvolání debaty, z níž bych mohl načerpat informace a dozvědět se, jak to dělají jinde. K jeho napsání mě přiměly jednak vlastní motivy z poslední doby, tak i poznámka z posledních jaderných novin, že jediný administrátor na údržbu komplexnějších systému asi nestačí.

Jak všichni víme, unixové stroje mají pouze jednoho roota. Z hlediska zastupitelnosti je však neúnosné aby tenhle účet spravoval pouze jeden člověk. Ovšem v případě, že má k účtu uživatele root přístup více osob, nutně, dřív nebo později narazíte.

Problém v součinnosti

V případě že více osob spravuje jeden systém se může stát, že v případě problémů začne stejný problém řešit více osob současně. A nebo také naopak - nezačne jej řešit nikdo. U nás to obvykle funguje tak, že se každý stará především o svůj písek. Jiné stroje řeší jen v případě, že mu je někdo výslovně svěří (kupř. při plánované dovolené), ovšem i tak až v případě, že se mu v případě problému nepodaří spojit s jejich "správcem" a problém přetrvává.

Problém v odbornosti a informovanosti

Nelze očekávat, že všechny osoby co mají spravovat nějaký systém mají stejnou úroveň odborných znalostí. Obzvlášťě v dnešní době, kdy objem toho co je nutné vědět oproti časům před pouhými pěti lety neskutečně nabobtnal. Bohužel na to neznám žádné jiné řešení než opravdu otevřený pracovní kolektiv, kde se všichni průběžně navzájem informují a radí.

S touto otevřeností souvisí i povědomí o tom kdo, na čem a co dělá. Je pochopitelně nemožné vědět o všem, takže základem všeho je kvalitní dokumentace, ve které je popsán s odpuštěním každý prd, byť by se to někdy mohlo zdát zbytečné. Zákon schválnosti říká, že největší záseky jsou právě na prkotinách.

Zpětná analýza problému

I v případě, že spravujete systém sami můžete zanedlouho dospět do stádia, že už si prostě nepamatujete co kdy kde a jak jste nastavili. Já jsem se tomu rozhodl čelit následujícími kroky - jednak jsem začal používat uložení aktuálního času v historii příkazů a pak také nechávám veškerou historii archivovat. A už se mi to i vyplatilo, neboť jsem díky tomu mohl - porovnáním historie ze dvou strojů zjistit, že za úplným kolapsem virtuálního stroje během mé dovolené byl zdánlivě triviální problém - a to, že kolega při řešení problému udělal přesně to udělat nikdy neměl - restartoval fyzický stroj, ze kterého virtuál měl připojená data a konektivitu, v domnění, že se tím problém vyřeší.

Zkrátka, jak se říká - mnoho psů, zajícova smrt. Zajímá mne tedy, jak se s tím potýkáte jinde. Předem díky za vaše příspěvky.

       

Komentáře

[Jan Drábek]

No, zatím moc nijak...

V nějakém texťáku mám zapsané jak udělám ty a ty úkony (protože se mi do měsíce podařilo zapoměnout).

[anton]

+1 my mame na to vo firme zavedenu vlastnu aplikaciu phpTODO previazanu s MySQL kde sa ulohy zadavaju, a jednotlive osoby s pristupom roota zapisuju vybavenost jednotlivych poziadavok (zapisuje sa cas a datum vybavenia/pridania poziadavky, priorita poziadavky, deadline poziadavky a pod. + poznamka ) - momentalne su tam poziadavky najstarsie z r. 2007 (od spustenia serveru). Velmi dobra vec!

[dad]

podobny napad meli u nas ve firme, jen je to napsane v perlu a jmenuji to admin-todo. Take si ve firme nysleli, ze je to dobra vec, az se prislo na to, ze i to admin-todo musi nekdo administrovat a ujala se toho vlastni skupina.

Mnozi to uz asi tusi! Aby si ti admini tech adminu neurizli vetev pod zadkem, tak pouzivaji vlastni tool, ktery nazyvaji admin-admin-todo. Takze pozor.

[Max]

Když více administrátorů, tak jedinou možností je otevřený kolektiv a prostě mezi sebou komunikovat.

Jinak nepatřím mezi střelce, kteří používají historii příkazů a už vůbec bych nepatřil mezi ty, co si jí někam ukládají. V zásadě první věc, co dělám je :

HISTFILE="/dev/null"
MYSQL_HISTFILE="/dev/null"

Poučil jsem se tak od jednoho administrátora jednoho nejmenovaného serveru (docela big serveru), který měl shell pro uživatele, kteří byli dobře omezení, ale /root měl 644, všechny soubory historie měly 600, ale backup historie měl 644 :). A měl tam i backup historie mysql shellu a v něm krásně root heslo, které bylo shodné s rootem v systému, takže jsem měl jako obyčejný uživatel hnedle jedle roota a plný přístup k celému serveru. Od té doby všude historii vypínám a nechávám si jí jen u obyčejného uživatele a to jen někde. Pro mně je historie příkazů nebezpečná věc, kterou bych si měl hlídat a tak to řeším jejím vypnutím.
Zdar Max

[anton]

Typicky priklad Security through obscurity. Velmi nestastny pristup...

[rADOn]

To tedy neni. Cilova informace neni nijak skryta (obscurity), ale rovnou smazana a utocnik se k ni tedy nema jak dostat. Je to mozna hloupy napad z hlediska spravy, ale z hlediska bezpecnosti je zruseni historie jedine zlepseni.

[Aleš Kapica]

Na naše stroje s výjimkou lidí co je spravují uživatelé přístup vůbec nemají. Ti se pohybují pouze ve virtualizovaném prostředí. A systém, v jehož rámci pracují a v němž případně mají svůj účet je bezdiskový systém, který jakoukouli úpravu mimo uživatelský adresář po restartu zapomene.

[Max]

Nevidím v dlouhodobé historii žádný přínos a v současné relaci je historie uložena v ramce, takže pokud jsem přihlášen, tak do odhlášení historii mám.
Zdar Max

[nyan]

Obavam se, ze historie>/dev/null problem nevyresi. Skutecny problem je v tom, ze se zadava heslo na prikazovem radku.

I kdyz mate historie>/dev/null, jakejkoliv prikaz s heslem na cmdline je videt ve vypisu 'ps a'.

Kdyz uz heslo, tak bud v konfiguraku s pravami, nebo nechat program at o nej pozada na konzoli.

[rADOn]

Vsadim masovy kolac proti psimu sucharu, ze Maxe spis nez .bash_history trapi .mysql_history, pacz tam 1) heslo interaktivne zadat nejde a 2) do vypisu procesu neni videt.

[Max]

Přesně tak, a bash_history zahazuji projistotu, kdyby náhodou, protože každý má své chvilky.
Zdar Max

[Jakub Lucký]

Mluvíme-li o přihlašování do konzolového MySQL, pak to jde i interaktivně (a to několik let)

jakub@taniquetil:~$ mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 59
Server version: 5.1.58-1 (Debian)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

[pavlix]

(a to několik let)

Vím, jaks to myslel, ale neopustím si poznámku, že mě to jde vždy tak cca několik minut, než zapomenu heslo. Heslo do MySQL je z pochopitelných důvodů složité, ale uložené v /root. To si dovolím napsat veřejně, protože /root je chráněný proti přístupu, a root do MySQL stejně může. Takže zadávání hesla za roota je právě od tvůrců MySQL security by obscurity nejtěžšího kalibru. Na nutnosti zadávání mysql hesla v rootí konzoli není nic ani v nejmenším „secure“, spíš naopak. Na nutnosti uložení hesla ve zdrojácích/konfigurácích aplikací taky není nic „secure“. Naopak „obscure“ to je za všech okolností.

Pro mě osobně je to dostatečný důvod, proč se MySQL vyhýbat, když je tu PostgreSQL. (Stejně tak byl dostatečný důvod se mu začít vyhýbat kvůli absenci transakčního zpracování ve výchozím nastavení, ale ani náprava není důvodem k návratu.) Neříkám, že PostgreSQL nemá nedostatky, ale zatím se nikdy neukázaly jako kritické. A hromadu výhod proti MySQL má v konkrétních případech i SQLite, která rovněž co pamatuju neměla problémy s hesly ani s transakcemi.

[rADOn]

Pleteš si "security thru obscurity" a "klient-server" architekturu. Administrátorské nástroje které sahají přímo na databázi žádné heslo nepotřebují, přesně z důvodů které popisuješ. Řádkový klient je z hlediska serveru jen otevřený socket a musí tedy nějak prokázat svojí identitu. Jestli postgresí klient rootovské heslo nechce, docela by mě zajímalo jak tedy roota pozná.

[pavlix]

Pleteš si "security thru obscurity" a "klient-server" architekturu.

Tak z toho mě snad podezřívat nemůžeš :).

Řádkový klient je z hlediska serveru jen otevřený socket a musí tedy nějak prokázat svojí identitu.

Já v tom nevidím jediný problém.

Jestli postgresí klient rootovské heslo nechce, docela by mě zajímalo jak tedy roota pozná.

Mno... takže ty mě podezříváš z toho, že si pletu „security through obscurity“ s klient-server architekturou a nenapadá tě jediný způsob, jak může server poznat, že se na něj po lokální socketě připojuje root? Děláš si legraci?

[rADOn]

Nedělám. V nízkoúrovňové práci se sockety se nijak zvlášť nevyznám, takže by mě to docela zajímalo. Umím si představit pár způsobů jak něco takového zařídit "oklikou", ale všechny tak či onak zahrnují horší prasení než soubor s heslem. Jsem jenom zvědavý, zneužívání uid 0 k posílání sql dotazů nepovažuji za přednost ale za nešvar.

[pavlix]

Umím si představit pár způsobů jak něco takového zařídit "oklikou", ale všechny tak či onak zahrnují horší prasení než soubor s heslem.

A zeptat se OS by ti taky připadalo jako větší prasení než používat soubor s heslem?

Jsem jenom zvědavý, zneužívání uid 0 k posílání sql dotazů nepovažuji za přednost ale za nešvar.

PostgreSQL používá pro tento účel vlastního uživatele, takže k použití UID 0 vůbec nedochází (i když mě osobně by to nevadilo, ale někomu od postgresu asi jo). Mimochodem, pro ověřování uživatelů se u mnoha služeb místo UID používá login, má to některé vlastnosti odlišné od UID.

[rADOn]

Umím si představit pár způsobů jak něco takového zařídit "oklikou", ale všechny tak či onak zahrnují horší prasení než soubor s heslem.

A zeptat se OS by ti taky připadalo jako větší prasení než používat soubor s heslem?

A prozradit mi rovnou, že hledám sendmsg() typu SCM_CREDENTIALS by ti zkazilo zábavu?

Jsem jenom zvědavý, zneužívání uid 0 k posílání sql dotazů nepovažuji za přednost ale za nešvar.

PostgreSQL používá pro tento účel vlastního uživatele, takže k použití UID 0 vůbec nedochází (i když mě osobně by to nevadilo, ale někomu od postgresu asi jo). Mimochodem, pro ověřování uživatelů se u mnoha služeb místo UID používá login, má to některé vlastnosti odlišné od UID.

Nemyslím uživatele v db ale v systému – lidi co se přihlašujou na roota jen kvůli sql konzoli protože si neumí nebo nechtějí nagrantovat práva.

[pavlix]

A prozradit mi rovnou, že hledám sendmsg() typu SCM_CREDENTIALS by ti zkazilo zábavu?

To neznám.

Nemyslím uživatele v db ale v systému – lidi co se přihlašujou na roota jen kvůli sql konzoli protože si neumí nebo nechtějí nagrantovat práva.

Myslím, že to přeháníš. Obvykle je zásah do db součástí větší série administrativních zásahů (třeba zakládání systémových uživatelů apod), takže na toho roota nepřepínáš, ale jím jsi.

Ale jak jsem říkal, postgres má toto vyřešené, můžeš dát kterémukoli uživateli právo pustit sudo -u postgres, když potřebují plný přístup k DB.

A on není až tak velký problém pak napsat sudo -u postgres psql místo psql -U postgres, akorát v druhém případě musíš udělat z uživatele superusera, aby to bylo víceméně ekvivalentní.

A ono je pak vůbec nejlepší se přihlašovat na jednotlivé uživatele, když už mají vytvořené databáze, ať už přes sudo, nebo přes psql a heslo.

[rADOn]

A on není až tak velký problém pak napsat sudo -u postgres psql místo psql -U postgres, akorát v druhém případě musíš udělat z uživatele superusera, aby to bylo víceméně ekvivalentní.

To je právě omyl – není to ani náhodou ekvivalentní. Pokud to není root, dejme tomu že ti nevadí mít jinou historii, inputrc a všechno ostatní. Ale uid 0 je nebezpečná hračka a uchylovat se k němu jen proto že jsem línej napsat „-u root“ je chyba.

[xkucf03]

Ale postgres přece není root – jsou to dva různí uživatelé v systému. Jako postgres se můžeš přihlásit třeba přes SSH nebo se na něj přepnout z obyčejného uživatele (ne z roota) takže ani chvíli nemusíš být uid=0.

[pavlix]

Mám podezření, že mluvíš o něčem jiném, než já, a ještě navíc silně nábožensky.

[rADOn]

Já mluvím o tvém příspevku o přihlašování se do sql konzole jako systémový root. Užití systémového uid k autentizaci je hezké, (teď, když už vím jak se to dělá , to jenom ten root mě nadzvednul.

[pavlix]

Já mluvím o tvém příspevku o přihlašování se do sql konzole jako systémový root.

Tak příště klikni na tlačítko „odpovědět“ u toho příspěvku, na který chceš reagovat. Ono to pak totiž vypadá, že tvé „není to ani náhodou ekvivalentní“ je reakcí na mé „aby to bylo víceméně ekvivalentní.“, které se týkalo UID postgresu.

Ono by to pak mohlo vypadat, že vůbec nevíš, o čem je řeč, a že si pleteš UID postgresu s UID 0.

A ne každý ti dokáže na dálku číst myšlenky, aby si uvědomil, že tím, co píšeš, myslíš vlastně úplně něco jiného.

Užití systémového uid k autentizaci je hezké, (teď, když už vím jak se to dělá , to jenom ten root mě nadzvednul.

A na kterého uživatele se mám tedy z toho roota přepnout, aby tě nenadzvedávalo, že administruju MySQL databázi?

[Aleš Kapica]

Pánové, nezdá se vám, že už jste v této debatě úplně jinde, než bylo původní téma?

[rADOn]

Tak příště klikni na tlačítko „odpovědět“ u toho příspěvku, na který chceš reagovat. Ono to pak totiž vypadá, že tvé „není to ani náhodou ekvivalentní“ je reakcí na mé „aby to bylo víceméně ekvivalentní.“, které se týkalo UID postgresu.

Však to taky tak myslím. Z hlediska serveru a jeho touhy ověřit kdo je "na drátě" je to sice ekvivalentní, ale z hlediska zbytku systému je to úplně něco jiného. Proces sql konzole může mít jiné uid, masku, číst jiné konfiguráky… nemít svůj vyladěný inputrc bych považoval za opruz v každém případě ale dejme tomu že to je moje úchylka. Co ale považuji za sebevražednou pitomost je spouštět sql konzoli pod systémovým rootem (uid 0). I když pominu cílený útok, představa že třeba hloupý překlep v tee může zrušit libovolný soubor v systému je dostatečný důvod.

Čili, abysme se dobrali nějakého konce téhle debaty, ověřování v db pomocí systémového uid může být šikovné pro "malou" službu (tj. služba i db jsou na stejném systému) ale pro všechno statní je to k ničemu – služby na jiných strojích potřebují nějaké ověření (soubor s heslem) a administrátorské zásahy je lepší provádět z jiného účtu, nejčastěji z úplně jiného stroje.

A na kterého uživatele se mám tedy z toho roota přepnout, aby tě nenadzvedávalo, že administruju MySQL databázi?

Administrace MySQL databáze je něco jiného a kromě pár krajních případů s tím nemá nic společného. Já to dělám taky, a kromě založení uživatelů po čisté instalaci jsem účet 'root'@'localhost' nikdy nepotřeboval. Ergo schopnost postgresu přihlásit se na něj bez hesla je hezká, ale prakticky je mi u prdele.

[rADOn]

Ne, on myslí zakládání uživatelů v databázi (GRANT usage ON *.* TO 'foo'@'%' IDENTIFIED BY 'heslovplaintextu') nebo úpravy nějakých vlastních tabulí s hesly (UPDATE users SET password = PASSWORD('heslovplaintextu') WHERE username='foo').

[Jakub Lucký]

jo, tohle jo, to uznávám, je konina...

[pavlix]

To je tím, že mysql vyžaduje heslo i v případech, kdy je jasné, že dotyčný je root. Návrhová blbost nejtěžšího kalibru.

[Aleš Kapica]

No ono totiž správcovské heslo do mysql nemusí být vůbec totožné s heslem roota.

[pavlix]

No ono totiž správcovské heslo do mysql nemusí být vůbec totožné s heslem roota.

To je vcelku známý fakt. Jen nevidím souvislost s příspěvkem, na který reaguješ.

[Ladicek]

Osobně těžce nesnáším, že Postgres umožňuje přebírat uživatele ze systému. Fuck, prostě ne! Chci kompletně oddělené databáze uživatelů. (No a že kvůli collation vyžaduje v systému vygenerované locale, tak nad tím už jenom bezradně mávám rukou.)

[pavlix]

Osobně těžce nesnáším, že Postgres umožňuje přebírat uživatele ze systému.

Mě schopnosti programů obvykle nevadí, spíš mi vadí jejich neschopnost. Zatímco Postgres ti dává vybrat, MySQL umí jen jednu možnost.

[okbob]

Také PostgreSQL uživatele ze systému nepřebírá.

Minimálně v několika v posledních verzích a ani nepředstírá, že by tam nějaká vazba byla.

Ale co pg dokáže, je použití autentifikačních systémů - např. "ident", takže zaloginovaný uživatel nemusí podruhé zadávat heslo při přístupu do db (pokud je to povolené - viz konfigurační soubory pg_hba.conf a pg_ident.conf).

S collation (resp. závislost na locales) se pg chová pouze jako správně napsaná unixová aplikace.

[xkucf03]

A soubory ~/.ssh/id_* doporučuješ taky smazat, nebo raději správně nastavit práva?

[RapMan]

Ahoj, v praci pouzivame gforge, veskere ukoly/problemy by se meli resit zadanim trackeru/bugu a je i videt aktualni stav a pridelena osoba, ke konfliktu by nemelo dojit. Ale chce to disciplinu.

[Heron]

Osvěčily se dvě věci. Jednak ticketový systém, kde se každý úkon někomu jednoznačně přidělí a je vidět v jakém stavu to je a jak dlouho to trvalo.

A také dokumentace, každá netriviální věc by se měla dokumentovat a psaní dokumentace by měla být součástí úkolu samotného. S tím je trochu problém, solitéři (kteří do týmu vlastně ani nepatří) dokumentaci zásadně nepíší.

[xxx]

Taky jsem pracoval ve frimě, kde se jelo podle ticketů a vše se dokumentovalo. Má to pár úskalí. První je, jak psal dad ,admin-admin-tool. Je třeba vymyslet systém, jak to adminy donutit používat. Asi jediná možná cesta je admistrativní. Co není vykázáno a zdokumentováno není zaplaceno, je sice fajn základ, ale může značně ovlivnit chuť k plnění některých úkolů. Typicky takových, kde je pak víc vykazování, než řešení problému.

[CEST]

U nas byl problem donutit uzivatele, aby do ticket systemu (OTRS) svoje problemy hlasili, misto zmineni problemu na WC nebo pri obede jednomu cloveku, kterej problem treba vubec resit nemohli. Pripadne pro dlouhodoby ukoly (mysleno ne problemy uzivatelu) zapisujeme do Jira.

Pak uz je to pohode. Proste si nekdo ten problem vezme. Pokud by nekdo z nas ten system ignoroval, tak by a) nemel co delat, b) bylo by videt, ze zadne tickety neresil.

Na linuxu mame LDAP autentizaci a autorizaci, s SSH LDAP pubkeys (nepovinne) a sudo. Bohuzel dost veci nelze bez primeho roota delat, takze zname i root heslo, ale spousty dalsich neosobnich hesel mame v textovych souborech zasifrovanych pomoci PGP. Ale jsme 3 linux/network admini, 2 windows admini a dohromady groupwise admini a nekterych dalsich vecech ruzne promixovani a proste spolu musime komunikovat a dokumentovat-bud ve wiki, v konfiguracich (napr. komentare v DNS zonach) nebo v popiscich ESX VM.