Názory k článku Zavádíme omezení v OpenSSH
-
Radek Hladik (neregistrovaný)
Pokud uživatel potřebuje "jen shell", pak jsou dvě možnosti. Buď mu ten shell nějak ořezat, což často vede k problémům typu "já nevěděl, že ten prográmek XY umí spustit plnohodnotný shell", nebo pak omezit to, co může dělat třeba na firewallu atd. Prostě jako jakékoliv omezení jakéhokoliv uživatele.
Zajímavou alternativou je virtualizace, kdy se takovému uživateli udělá jeho vlastní virtuální stroj a tomu se omezí přístup k síti. Je to trochu silné kafe, ale na druhou stranu ten uživatel pak může mít třeba i root přístup.
-
<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%.
-
pepazdepa (neregistrovaný)
"tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA…= jane@example.net"
zde neni jasne to, ze se predpoklada, ze je to ssh na roota, pokud ne tak to nemuze fungovat, protoze sshd spousti uzivatelsky ForceCommand pod pravy uzivatele, iirc, takze pokud je to prihlaseni napr. na uzivatele 'jane' tak to neprojde, pac na nastaveni tun0 nema prava (nutne pouzit sudo nebo upravit prava na skriptu).
nebo se mylim?
-
Ondřej CaletkaZlatý podporovatel
Ano, musí jít o rootovský účet na straně klienta i serveru, jinak není vůbec možné SSH VPN navázat (vytvořit tun-zařízení).
-
Franta (neregistrovaný)
Díky za článek resp. celý seriál, patří k tomu nejlepšímu, co se tu dá v poslední době číst :-) Jen doplním:
1) Ad "Jedinou možností, jak zneužití bránit, je neumožnit uživateli na vzdáleném systému spouštět vlastní kód."
Naštěstí tomu tak není -- dá se použít AppArmor nebo iptables, takže uživatel může spouštět libovolné příkazy, ale nemůže navazovat síťová spojení -- resp. může navazovat jen taková, jaká mu dovolíme. Viz AppArmor vs. iptables – blokování sítě.
2) K tomu ProxyCommand -- jedna šikovná věc: máme např. X počítačů v nějaké síti (škola, práce atd.) typicky v jedné doméně a na všechny chceme přistupovat pomocí jedné přestupní stanice -- pak se hodí použití zástupných znaků %h a %p -- viz SSH přes SSH „proxy“ server.
ČLÁNKY DO MAILU