[Probléma áthidalva] 500 OOPS: vsftpd: refusing to run with writable anonymous root

Sziasztok!

Én viszont pont azt szeretném, amit nem enged a vsftpd...

Már jó pár órát Google-ztam... Nem működik...

Valakinek ötlete? Alternatíva?

UPDATE: feltettem egy pure-ftpd-t és 5 perc olvasgatás és hack-elés után úgy megy, ahogy szeretném! :D Köszönöm!

Swifty

Hozzászólások

Senki? :D
--
Debian Linux rulez... :D

Nem ertem, mi a problema, ezen mit nem lehet erteni?

Q) Help! I'm getting the error message "refusing to run with writable root".

A) vsftpd is protecting against dangerous configurations. The cause of this message is usually dodgy ownership of the ftp home directory. The home directory should NOT be owned by the ftp user itself. Neither should it be writable by the ftp user. A way to fix this is:

chown root ~ftp; chmod -w ~ftp

Another cause might be an attempt to use chroot_local_user without setting up the directory ownership properly.

--
L

Neither should it be writable by the ftp user

Ennek sok értelme, van, hogy belépsz egy userrel, és nem tudsz írni a homejába...nem igazán értem, hogy kitől is véd ez. Minden esetre a workaround allow_writeable_chroot=YES

(mármint ez chrootolt usereknél működik)

Another cause might be an attempt to use chroot_local_user without setting up the directory ownership properly.

De mindegy, az eredeti problémát nem oldja meg :)
Csak érdekelne, hogy ez vajon mitől véd? Mert hogy használhatatlanná teszi annak, aki nem csak letölt, az biztos.

1. Nem "refusing to run with writable root", hanem "refusing to run with writable anonymous root"...

2. Ez a verzió van fent: 3.0.2-10 (bár mindegy, mert az újabbak közül mind ezt csinálja.)
Ezzel a konfiggal:

allow_writeable_chroot=YES
anon_mkdir_write_enable=YES
anon_root=/data/share/samba/shares/public/Scan
anon_upload_enable=YES
anonymous_enable=YES
connect_from_port_20=YES
dirmessage_enable=YES
listen_ipv6=NO
listen=YES
ssl_enable=NO
use_localtime=YES
write_enable=YES
xferlog_enable=YES

Az adott könytárra 0777-es jogok vannak kiosztva...

3. A kliens egy nagyon buta fénymásoló, ami anonymous-ként próbál feltölteni az FTP szerver gyökerébe szkennelt fájlokat... (Csak az IP címet tudom megadni, hogy hová szkennelhet...)

Szóval??? Érted már???

--
Debian Linux rulez... :D

?

anon_world_readable_only
When enabled, anonymous users will only be allowed to download files which
are world readable. This is recognising that the ftp user may own files,
especially in the presence of uploads.

Default: YES

no_anon_password
When enabled, this prevents vsftpd from asking for an anonymous password -
the anonymous user will log straight in.

Default: NO

Azért ezt nem teljesen értem az eddigiek után.
Én felraktam egy vsftpd-t, annyit csináltam, hogy engedélyeztem az anonymous usernek az írást és könyvtárlétrehozást, újraindítottam a szervert, a /var/ftp-re 0777-es jogot tettem és ettől kezdve gond nélkül tudtam bele írni. Illetve amire nem emlékszem és már kiirtottam: fogalmam sincs, hogy előtte vagy utána állítottam át a vsftpd userét, hogy ne root-ként fusson. De azt hiszem, előbb volt a user csere, utána a chmod 0777... A lényeg, hogy nekem gond nélkül pakolt fel bármit a vsftpd-vel anonymous userrel.

Valahol láttam emlegetni, hogy nem mindegy, inetd-ből fut (van még olyan?) vagy önállóan. Nálad mi a helyzet?

Nekem egy bizonyos könyvtárba kellene írnom...(Tulajdonosa nobody:nogroup... 0777 jogokkal) Persze lehet hogy mount -bind-olni fogom...

Aktuális konfigom:

anon_mkdir_write_enable=YES
anon_other_write_enable=YES
anon_root=/data/share/samba/shares/public/Scan
anon_upload_enable=YES
anon_world_readable_only=NO
anonymous_enable=YES
connect_from_port_20=YES
dirmessage_enable=YES
listen_ipv6=NO
listen=YES
ssl_enable=NO
use_localtime=YES
write_enable=YES
xferlog_enable=YES

Verzió: 2.3.2-3+squeeze2

Daemon-ként fut...

--
Debian Linux rulez... :D

a /var/ftp-re 0777-es jogot tettem és ettől kezdve gond nélkül tudtam bele írni.

Úgy, hogy ftp://xxx.yyy.zzz/blabla? Mert ezt az aktuális vsftpd nem engedi meg (tehát régi vsftpd-vel próbáltad).
Vagy úgy, hogy ftp://xxx.yyy.zzz/var/ftp/blabla? Mert ez utóbbi a kérdezőnek meg nem jó.

PONTOSAN!!!

Nekem ez kell:

1. User megnyomja a scan gombot a fénymásolón.
2. Fénymásoló FTP kapcsolatot hoz létre a szerverrel.
3. Azonosítja magát "anonymous" néven és "?" jelszóval.
4. Feltölt 1db PDF fájlt az "anonymous" gyökér könyvtárába... (put /1234567.pdf)

Nekem csak a 3. pontig jut el... Utána 500-as hibakód...

B*ssszus... Nem akarok semmilyen security dologgal foglalkozni! Én csak egy k*rva fájlt akarok egy könyvtárba feltenni... ENNNYI!!! :D

--
Debian Linux rulez... :D

Mit jelent a régi?
Reggel Centos 6.4-en próbáltam, most Debian Wheezy-n.
A CentOS alatti verziót nem ismerem, a debianos 2.3.5-3 verziószámmal bír.
Annyi van, hogy itt az anon_root directory-hoz az ftp usernek kell hozzáférést biztosítani, hiába adok meg másik usert a konfigban. (kicsit zombi módban vagyok, szóval lehet, hogy csak figyelmetlen voltam)

update: bocs, látom, neki 3.x van... Na olyat egyik meglévő rendszeremen sem találtam eddig. De megnézem még az ubit...

Látom nincs megoldás a problémámra... :(

Tud valaki olyan FTP szervert, amelyik nem korlátozza az anonymous felhasználót, hogy hova írhat?

Köszi!
--
Debian Linux rulez... :D

Mondjuk ha a /var/ftp könyvtárra 0777 jogot adsz, az "megoldja" a gondodat - feltéve, hogy a CentOS-ban telepítéskor aktiválódó SELinux nem pofázik bele.
Hogy ez esetedben mekkora biztonsági problémát jelent, azt neked kell eldönteni. Annyira nem ismerem az ftp szerverek működését, hogy ezt a könyvtárat használják-e valamire azon túl, hogy az anonymous userek ezt érik el.
(lusta voltam utánajárni alaposabban, hogy milyen userrel próbál az ftpd beleírni, ezért említettem a 0777-t)

Hát ez a téma két dologra volt jó:
1. Egy életre megutáltam, a már amúgy sem kedvenc kategóriás SuSE-t... Gyalázatosan ócska, ha nincs GUI... :( (konkrétan a YaST a virtualbox-os konzolon használhatatlan, úgy összezagyválja a képernyőt)
2. Adalék az első ponthoz, roppant érdekes csomagokat hoznak össze. Pl. a yum nem telepíthető mert konfliktusa van más csomagokkal, a vsftpd-ből meg valami olyan verzió kerül fel a hivatalos repoból, aminek a működése még véletlenül sem egyezik a neten talált infókkal. Konkrétan lenne egy allow_writeable_chroot/allow_writable_chroot paramétere, amit ugyan elfogad, de tojik rá, ugyanakkor a vsftpd.conf-ban nyoma sincs.
Ráadásul a man-t is külön kellett felrakni, mert szerinte egy szerverre az is felesleges :(

Olyan ftp daemont keressél, ami nem csak a saját home-jába tudja chrootolni a felhasználót, hanem akármilyen könyvtárba, vagy a home-ja alatt egy alkönyvtárba. Halvány emlékeim szerint mintha a proftpd tudott volna ilyet (évek óta nem használom).
Az ugyanis security hole, ha az anonymous felhasználó tudja írni a home könyvtárát. chroot nélkül a / lesz az ftp struktúra gyökere (ahova nyilván nem írhat), a vsftpd chroot megoldásával pedig a saját home-ja lesz az ftp struktúra gyökere (ahova meg jó szívvel nem lehet megengedni, hogy írjon).

Miután megoldódott kérdeznék: valaki meg tudná magyarázni, miért jelent akkora biztonsági kockázatot ha a chrootolt / könyvtár anonymous user által (pontosabban az ftp szervert futtató linux user által) is írható, hogy egyáltalán nem működik ez a variáció a vsftpd egyes verziói alatt?

Ismereteim szerint ez kizárólag annyira ad lehetőséget, hogy a belépés nélkül teleszemeteljék azt a könyvtárat. De a szemetelésre akkor is megvan a lehetőség, ha alkönyvtárba tolhatja az anonymous a szemeteit. Akkor hol a gond?

Márvolt, de tessék: a glibc (és egyéb library-k) elvileg tölthetnek be további library-ket, plugin-okat és konfig fájlokat pl a /lib, /etc mappákból bizonyos hívások hatására, mert ezek néha alapoznak arra, hogy oda úgyis csak a root írhat. Ne ezt állítja feje tetejére az user által írható chroot mappa..

Ezt láttam, csak nem értem, mennyivel okozhat több gondot ha az ftp user által írható a gyökér könyvtár, mint ha nem anonymous-ként írhatja valaki a sajátját. Attól, hogy accountja van a gépen, még nem lesz feltétlenül megbízható és ha jól láttam olyankor a használt user nevében fut az ftpd. Arról nem beszélve, hogy ilyen alapon pl. a csomagszűrőt is kötelezővé lehetne tenni. (értsd: ne akarjon a szoftver okosabb lenni az embernél!)

Ahogy nézem az a probléma, hogy ha a glibc ráfut egy hibára, akkor betölti a /lib/libgcc_s.so.1 libet. Chrootban ez meg a ~/lib/libgcc_s.so.1 lesz
De ez miért csak az ftp-t érinti? sftp-t mondjuk miért nem? Vagy bármilyen más szoftvert? Azért az, hogy egy user tudjon írni a homejába, elég alapvető követelmény.
És vajon ez a glibc probléma fixálva van már?

Várj, várj, várj...

Kezdjük azzal, hogy adott egy mappa valahol a fájlrendszeren (azaz nem a valódi gyökér), (amiről azt sem tudjuk, hogy van-e rajta "noexec"), ami valójában az FTP szerver anonymous felhasználójának a gyökér mappája...

- Ha ez chroot nélkül van megoldva, akkor "nehézkes" a "kitörés" ellenőrzése...
- Ha ez chroot-tal van megoldva, akkor hiba esetén betölthetné a ~/lib/libgcc_s.so.1-et ???

Költői kérdés: Nem egyszerűbb/ésszerűbb a (~)/bin (~)/lib könyvtár írás-/létrehozás jogát elvenni???

Wazzz...

--
Debian Linux rulez... :D

Basszus! Most esett csak le, hogy miről beszéltek a többiek! :(((
Rohadtul nem értettem, miféle kitörésre gondolhattak... egészen mostanáig. :(
Konkrétan az nem jutott el a tudatomig, hogy ez az írható könyvtár valóban egy chroot-olt környezet / directory-ja.

Hm. Így viszont - ha működik, amit most megérteni vélek - valóban komplett életveszély a chroot-olt környezetben a root írhatósága. :(

Akkor viszont a köv. kérdés merül fel bennem: nem a chroot efféle kivitelezése a gázos? Zombi mód ismét bekapcsolt, szóval a részletezéstől inkább eltekintek. ;)

Ezzel az egésszel nem volna baj, ha a vsftpd tudná azt a helyzetet kezelni, hogy a ftp protokollon elérhető hierarchia gyökérkönyvtára ne egyezzen meg a processz gyökérkönyvtárával. Azaz legyen virtuális chroot is: az aktuális chroot gyökeréhez képest egy alkönyvtárat lehessen megcímezni az ftp-n keresztül gyökérként.