Vlákno názorů k článku Zavádíme omezení v OpenSSH od Harvie .cz - <i>Z bezpečnostních důvodů není povoleno, aby uživatel vlastnil...
-
<i>Z bezpečnostních důvodů není povoleno, aby uživatel vlastnil adresář, ze kterého se později stane kořenový. Proto jsme založili uživatelem vlastněný podadresář upload, do kterého může uploader bez problému zapisovat.</i>
To je totalne napytel. uz nekolik let se to snazim na hostingovejch strojich vyresit tak, aby kazdej user mohl mit klasicky adresar v /home a vlastnit ho a zaroven byl do nej zamcenej nejakou rozumnou cestou, ktera by nevyzadovala haluze jako scponly (kterejm moc neverim).
useri proste potrebujou, aby se zalogovali do sftp a videli jenom svoje soubory. nemluve o bezpecnosti.
kdyz sem kdysi objevil reseni v podobe OpenSSH chrootu a locknuti na internal-sftp, tak mi svitla nadeje, bohuzel to neni aplikovatelny na normalni usery, ktery logicky vlastni svuj home a musi do nej umet zapisovat.
-
Radek Hladik (neregistrovaný)
Presne tak. Celou tuhle podminku nechapu a pridelava to spis jen starosti. Proste neni mozny beznyho uzivatele zachrootovat (rozumej usera, kterej potrebuje ~ zapisovatelne. Druhej problem, na kterej s tim narazim je, ze kdyz chci kus prostoru nekomu nasdilet. Typicky zakaznik ma web, prostor ma pristupnej pres sftp a potreboval by specialni pristup do jednoho podadresare. Samozrejme se to da resit pres symlinky, aliasy a spol... Ale je to opruz :(
-
Ondřej CaletkaZlatý podporovatelPodmínka na nezapisovatelný chroot je tam proto, aby si uživatel například nemohl vytvořit speciální soubory v adresáři
/dev, čímž by mohl za jistých okolností utéci z chrootu.Vnoříte-li ale uživatelský domácí adresář ještě do jednoho, můžete chrootovat ten nadřazený adresář a všechno funguje, jak má.
Sdílený prostor jde samozřejmě jaksi zcela proti myšlence chrootu. Řešit se dá asi jen mnohonásobným
mount --bind -
Radek Hladik (neregistrovaný)
Priznam se, ze nechapu, jak nezapisovatelny / (po chrootu ) muze ovlivnit schopnost vyrobit specialni soubor, na coz imho je potreba root. Nechapu, jak by myslenka chrootu mela byt proti sdileni... bezne chroot funguje tak, ze chrootovany proces sdili se systemem cast jeho stromu... Pokud by chrootovany proces nepotreboval sdilet soubory se zbytkem systemu, tak muze mit svuj separatni prostor...
Ale priznam se, ze mne je jedno, esli to bude pres chroot nebo jinak, ale potrebuju mit moznost omezit sftp do nejakeho podstromu a ne mimo. A chroot vidim jako nejjednodussi cestu pro openssh server, jak toho docilit... -
Santiago (neregistrovaný)
Je ale otazka, zda to je riziko, pokud v tom chrootu zadne takove suid programy nejsou.
Tohle omezeni (chroot na adresar vlastneny rootem, uzivatelsky podadresar) ma smysl pokud se ssh pouziva pro shell - pak v tom chrootu musi byt vytvorene zakladni prostredi (napr. /bin, /lib ..), aby uzivatel mel vubec co spoustet. U sftp-only pristupu, kde chroot je prazdny, v tom moc smyslu nevidim.
-
Radek Hladik (neregistrovaný)
Rozumím. Pokud uživatel může jen do podadresáře, tak si nemůže vytvořit /home/user/podadresář/etc/passwd a udělat chroot /podadresář/ a pak zkusit to su...
Samozřějmě, dá se argumentovat, že nemá k dispozici ten příkaz chroot. Ale na rozdíl od su je chroot přímo systmové volání.
A navíc to su musí v tom chrootu mít připravené od roota a je dost divné připravovat su a ne /etc a /etc/passwd -
Jirka (neregistrovaný)
Na chroot je skvely rssh (http://rssh.sourceforge.net/). Dela presne to co chcete.
-
Ondřej CaletkaZlatý podporovatel
O rssh jsem se nezmínil proto, že o možnosti chrootování v rssh jsem nevěděl (hlavně proto, že rssh nemá dokumentaci na webu).
O programu jsem věděl, ale řadil jsem ho do starého železa, někam k protokolu SCP a SSH verze 1 :)
-
VS (neregistrovaný)
Jednoduše to jde. Stačí udělat bind mount /home někam, a tam nastavit chroot. see http://forum.root.cz/index.php?topic=2331.msg18504#msg18504
-
taky jsem to dlouho resil a nakonec pouzivam reseni popsane v tomto clanku, jen jsem prizpusobil adresarovou strukturu, aby mi to tak nejak vyhovovalo. Proste mam:
/hosting1
/hosting1/html
/hosting1/logs
/hosting1/info
/hosting2
/hosting2/html
/hosting2/logs
/hosting2/info
...Kdyz ho chrootnu, vidi user normalne adresare html, log, info, ... a do tech uz muze. Zaroven je chrootnuty a to je presne stav, ktereho jsem chtel docilit. Ty vyse vyjmenovane adresare stejne chci, aby mi nemohl menit a mazat, protoze do nich smeruje document_root, logy apod. A jaky bordel si udela v podadresarich uz je jen na nem.
Prava mam pak:
drwxr-x--- 3 root hosting1 512 4 čvc 16:46 hosting1Proto si myslim, ze toto pro webhosting pouzitelne je. Ale pokud mate nutnost zapisovat primo do home adresare, tak to jde opravdu hure. Ale zjistil jsem, ze pokud po prihlaseni uzivatele zmenite vlastnika nebo i prava na ten jeho home, muze zapsat i primo do sveho adresare. Proste se ta prava hlidaji jen pri prihlaseni, ale to asi neni cesta.
Ja misto ohybani a upravy ssh ohnul adresarovou strukturu hostingu a vyhovuje mi to na 100%.
ČLÁNKY DO MAILU