Fórum Root.cz
Hlavní témata => Server => Téma založeno: sudoers 17. 12. 2016, 20:28:04
-
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.
-
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.
-
zbytečná práce, buď si na tyhle servisní věci udělel nějaký admin panel nebo služby odděl, jak píše tuxík. V životě nedokážeš dobře oddělit na úrovni jednoho serveru služby, aby ti tam někdo z těch lidí neudělal neplechu.
-
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
-
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
A jak Docker resi tazateluv problem? Docker interne neresi security a pokud date uzivateli pristup na docker socket, davate mu UID 0 na vas stroj, navic v auditu nenaleznete ani radek - moc hezky napad. Docker urcite smysl ma, ale trosku z jinych duvodu nez je nahrada RBAC na serveru.
-
Místo dockeru raději LXC, to má alespoj pořešený to, že se nedá z kontajneru dostat na root hosta ;D
Docker je taková hračka pro děti.
-
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
A jak Docker resi tazateluv problem? Docker interne neresi security a pokud date uzivateli pristup na docker socket, davate mu UID 0 na vas stroj, navic v auditu nenaleznete ani radek - moc hezky napad. Docker urcite smysl ma, ale trosku z jinych duvodu nez je nahrada RBAC na serveru.
Predpokladam zadani, kde se resi, aby admin Zabbixu nechtic nezkurvil Baculu resenou jinym adminem.
Pokud je admin Zabbixu navic zaskodnik, no tak bude jenom dodavatel zabbix containeru, vlastni deployment provede osoba duveryhodna
-
Doporučovat na zabezpečení něčeho Docker je vopravdu youdovina. ::)
-
Doporučovat na zabezpečení něčeho Docker je vopravdu youdovina. ::)
Tak pro pomalejsi mezi nami vysvetlim podrobneji.
Docker neresi bezpecnost produkcniho prostredi, prislusny buzzword je "DevOps".
Vlastnik aplikace dostane via service desk zmenovy pozadavek, ten implementuje v dev prostredi. Po otestovani a akceptaci je novy release sakumprask nasazen do produkce (treba jako docker container), kde spavce Zabbixu nema zadna prava. 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
-
Po roce od nasazeni jedu selinux spolecne s redhat idm(freeipa), mam vic nez 6 skupin admin roli a nespocet normalnich user roli a no problem. Ze zacatku je s tim tedy radnyho srani, to muzu potvrdit. Porad nekdo otravuje ze nemuze kde co, ale da se to resit.
Jeste me napada ceskej produkt czechpam, ale jestli to zije to nevim
-
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.
-
Tak pro pomalejsi mezi nami vysvetlim podrobneji.
Pro pomalejší zopakuju požadavek:
Potrebuji, aby ruzni lide spravovali jenom vymezene aplikace (to jest editovani konfiguraku a aplikacnych dat a restart demonu) a nemeli pritom root pristup.
ITIL a change management a další pseudomanagorské kokotiny si sakumprásk zasuň tam, kam slunce nesvítí.
-
Tak pro pomalejsi mezi nami vysvetlim podrobneji.
Pro pomalejší zopakuju požadavek:
Potrebuji, aby ruzni lide spravovali jenom vymezene aplikace (to jest editovani konfiguraku a aplikacnych dat a restart demonu) a nemeli pritom root pristup.
ITIL a change management a další pseudomanagorské kokotiny si sakumprásk zasuň tam, kam slunce nesvítí.
Heh, mozna nekdy casem prijdes na fakt, ze to, co zakaznik pozaduje a to co opravdu potrebuje, jsou obcas krapet disjunktni mnoziny...
A ze je dulezite prijit na racio PROC to pozaduje a nadhodit pak reseni treba uplne mimo limity puvodniho zadani. Ostatne hned prvni reakce v tomto threadu doporucila services rozdelit, ja s tim souhlasim. A protoze na Linuxu nejsou solaris zones, navrhl jsem docker.
Apropos, IBM ma na requirement managent v ramci Rational Suite nastroj Doors. To jenom, kdybys mel zase chute neco zasouvat nekam, tak at vis co.
-
Apropos, IBM ma na requirement managent v ramci Rational Suite nastroj Doors.
Slunce žbluňce...
-
...
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.
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ý).
-
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.
-
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 :)
-
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).
-
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.
-
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.