RBAC nebo sudo

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:RBAC nebo sudo
« Odpověď #15 kdy: 19. 12. 2016, 09:44:50 »
To je trochu přehnané. Javaman je čistokrevný troll, který se vás snažil vyprovokovat (a je to vidět na první pohled z nicku).

Youda napsal odpověď k věci a navíc takovou, která skutečně řeší tazatelův problém. Sice to neumí vysvětlit a má kolem toho blbé kecy, ale to je zde na rootu dnes bohužel spíše standard :-(

Chápu že to řešení má nevýhody, ale já osobně bych rád slyšel konkrétní problémy použití dockeru pro tento účel (samozřejmě s tím, že ten kdo dělá image nemá přímo přístup na server - kontejnery dělá vyrábí někdo jiný, důvěryhodný).
Nemám v tomto případě nic proti dockeru, mám něco proti tvrzení, že SELinux je na... ano, je to otravné, každej druhej návod na jakoukoliv kravinu začíná "Disable SELinux" (pokud se návod týká distribuce, kde je SELinux defaultně enabled, třeba CentOS, tak je to snad 90%) a lidi poslušně vypínají, aniž by věděli co a proč vlastně dělají. Ale strašně mě kálí, když někdo mele takový kraviny jenom proto, že je neschopnej něco pochopit.

Jinak, SELinux není řešením tohoto konkrétního problému, docker ano, s tím souhlasím.


Re:RBAC nebo sudo
« Odpověď #16 kdy: 19. 12. 2016, 10:12:24 »
Docker neresi bezpecnost produkcniho prostredi
S tim se da urcite souhlasit.

Tomuto divnemu procesu se rika change management a je soucasti ITILu.
Ale chapu, kam s tim na mistni studentiky, zabbix spravce si zkratka jprasi co chce a kdy chce. Min to zdrzuje
Tak kdyz uz se chceme mlatit po hlave ITILem a nadavat si do studentiku, tak soucasti ITILu je i nejaka ta service strategy, design, formulace SLAcek a konkretne jejich bezpecnostni casti (klicova slova: security management -> plan).

Cili je potreba se ptat, co chce tazatel dosahnout, proti cemu se chce chranit (service strategy) a teprve podle toho doporucovat reseni (service design).

Pokud se chce tazatel chranit proti potencialne zakernemu adminovi, tak Docker neresi vubec nic, protoze do toho na devu uvareneho docker image si muze dat zakerny skript, ktery z dockeru utece nebo jinak narusi jine casti systemu, protoze containers do not contain.

Cili abysme se jeste jednou placli pres hlavu ITILem, pokud skutecne tazatel chce dosahnout tohodle, tak by interni bezpecnostni audit mel implementaci pomoci dockeru zamitnout :)

Re:RBAC nebo sudo
« Odpověď #17 kdy: 19. 12. 2016, 10:18:30 »
Kdyby chtel neco jako PHP admin, MySQL admin, Apache admin nebo Zabbix admin je to vubec rozumne a prakticke delat pomoci SELinux/RBAC nebo jinej RBAC implementace?
Potrebuji, aby ruzni lide spravovali jenom vymezene aplikace (to jest editovani konfiguraku a aplikacnych dat a restart demonu) a nemeli pritom root pristup.
Jeste jedna, minimalne teoreticka, moznost, ktera tady nezaznela, je nasazeni configuration managementu. Spravovat stroje jenom pomoci CM (tj. bez nezdokumentovanych rucnich zasahu) je samo o sobe spravna vec. Takze abys dosahl toho, co chces, v principu ti staci jenom to, ze "neprivilegovani admini" nebudou mit primo na stroj pristup, ale budou moct jenom commitovat zmeny do CM a bud nekdo jiny bude zmeny schvalovat, nebo bude nejak technicky zabezpeceny, ze muzou commitovat jenom zmeny do casti, ktere maji pod spravou.

Jako princip je to snadny, ale implementace neni zadna zadek. Takze dost zalezi, kam bys to chtel nasadit. Do tymu s deseti adminy to asi dava smysl, do tymu se dvema tremi se to nevyplati, lepsi je duverovat (a riskovat).

Youda

Re:RBAC nebo sudo
« Odpověď #18 kdy: 19. 12. 2016, 10:21:27 »
Jestli chceš jenom restart, nastav sudo na konkrétní příkazy. Jestli chceš kompletní správu, vykašli se na *admin, naděláš si problémy. Pokud řešíš malé prostředí, smiř se s tím, že ti kdokoliv rozdrbe cokoliv, pokud řešíš něco většího, nemá víc služeb na jednom serveru co dělat a o to je to jednodušší. Jinak SELinux je rozhodně dobrá věc, bohužel to většinou končí jeho vypnutím. Nastuduj di, jak to funguje, udělej si vlastní šablony a budeš king.

Selinux je naprosto debilni technologie, kterou jde se skripenim zubu rozjet pro staticke servicy typu Apache Httpd. V pripade dynamickych frameworku typu Zabbix, kde user pridava alertscripty a userparam scripty a aPHP stranky, to nebude fungovat nikdy.

Tazateli doporucuju Docker a dilcim adminum dat spravu vybranym containerum, uvnitr containeru si admin muze delat co chce

A hlavne muze zmeny nejprve poradne otestovat na dev prostredi a pak finalne deployovat jednim container pullem.
Pise se rok 2016
Ty vole.... teď jsem jinde slíbil, že se nebudu hádat s javoušem a je tu další tupec. SELinux je technologie, která se snaží řešit bezpečnost mezi službami a jestli nevíš, o co jde, tak o tom aspoň nepiš kraviny. Že seš na to moc blbej neznamená, že je ta technologie špatná. Znamená to pouze to, že seš na to moc blbej. A jdeš rovnou k javoušovi, už na tvoje kraviny nereaguju.

Heh, s mistnimi trolly je sranda :)
Ze Selinux resi bezpecnost mezi sluzbami jsem nevedel, myslel jsem, ze je to implementace ACL, clovek se porad uci.

Pred nedavnem kolega delal balicky pro par opensource nastroju (Zabbix, Puppet, Bacula) se specifickym pozadavkem, ze tyto aplikace nesmi lezt mimo svuj adresar v /opt - takze tempy, logy, pidfile, vsechno hezky v /opt/zabbix apod.

A toto jsou dojmy z teto akce:
Je nebetycny oser cokoliv zmenit nad uroven zmeny predzvykaneho selinux booleanu
Dokumentace komicka
Ze jsem po tydnu laborovani pri beznem pouziti aplikace se zbavil auditnich hlasek znamena jedine, user jeste neprovedl nestandarni operaci, ktera samozrejme lehne. Vlastni aplikace pritom nerekne ani slovo v.gui, ani do logu.
Format audit logu svou citelnosti a relevanci obsahu temer dosahuje idealu windows event logu.

Selinux politiky sedi v jedne centralni hromade hnoje, co tam nekdo nekdy pred lety kydl, to tam sedi uz naveky. Pokud je prislusna politika ve verzi treba 5.x a vyse, znamena to, ze se o to nekdo stara a mozna to i funguje. Pokud je ve verzi 1.x, znamena to, ze na politiku maitainer sere a je nefunkcni, bud nechrani nic, nebo naopak brani applikaci korektne fungovat.
A konfigurace je taky velike labuzo, pokud po tydnech laborovani najdu funkcni konfig, neexistuje zpusob, jak jej z devu prnest na produkci. Nejlepe se osvedcil zpusob cmarani poznamek o zmenach na papirek, pak navrat dev image do cisteho snapshotu pred zmenama a odzkouset to odznova - potom zopaknout na produkci treba Puppetem.

A kdyz je rec.o puppetu, ten zustal unconfined, nenalezen zadny zpusob, jak jej oselinuxovat, aby se do toho nemuselo hrabat s kazdym novym puppet modulem.

Pis dal, tvoje prispevky me zajimaji.

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:RBAC nebo sudo
« Odpověď #19 kdy: 19. 12. 2016, 10:51:16 »
Pardon, příště přiložím kompletní dokumentaci, abych nemusel zjednodušovat.
Jestli týden řešíš přepnutí SELinuxu do permissive a použití audit2allow, je mi tě líto. Tuhle debatu končím.