Chroot, glibc, ftp, drošība.

[Maris-S]

Laba diena!

 

Nevarēju īsti izdomāt kur šo rakstīt, pie drošības vai serveriem, bet tā kā vairāk saistīts ar serveriem, tad izdomāju ka labāk šeit.

 

 

Tātad gribēju pajautāt, vai kāds ir pētījis un kaut ko sakarīgu atradis saistībā ar FTPd lietotāju ierobežošanu mājas direktorijā, ar chroot palīdzību, un drošību? Šis jautājums man radās pēc tā kā sakonfigurējot vsftpd ar lietotāju lockošanu mājas folderī, serveris pie savienojuma sāka rādīt kļūdu, ka nepieļauj savienojumus, ja tiek izmantots chroot un mājas folderim ir rakstīšanas tiesības. Salīdzinoši ātri atradu arī risinājumu, vsftpd ir opcija

 

allow_writeable_chroot=YES

 

kas ļauj noņemt šo ierobežojumu. Taču sākot meklēt iemeslus, kāpēc noklusēti nav pieļauta rakstīšana mājas folderī, sanāca atrast ka tas ir drošības apsvērumu dēļ, jo, ja nemaldos, 2009. gadā tika atrasta potenciāla ievainojamība glibc bibliotēkā, kas nekorekti apstrādājot chroot vidi var nolasīt, piemēram, FTP lietotāja mājas folderī ievietotu ~/etc/myconfig.conf, nu kaut kā tā, sakarīgu informāciju patiešām nesanāca atrast, ne kā tieši ievainojamība darbojas, ne kā to izmantot ar FTP serveriem. Iespējams, ka to nevar izmantot, ja nav shell pieeja FTP lietotājiem, bet nekur apstiprinājumu tam neatradu. Nesanāca arī sameklēt informāciju par to vai tā ievainojamība tagad ir izlabota. Domāju ka ir, jo diezgan daudz laika ir pagājis, kopš viņa ir atrasta, bet tad nav skaidrs, kāpēc vsftpd tomēr noklusēti neļauj mājas folderi veidot ar rakstīšanas tiesībām, iespējams uzskata ka chroot ar rakstīšanai atļautu mājas folderi potenciāli nav ļoti drošs, bet nu īsti nezinu.

 

Vēl viena no alternatīvām ir taisīt root folderi kā read only un iekšā likt vēl vienu folderi, piemēram, upload. Taču tas nebūtu labākais risinājums, jo dažiem lietotājiem ir sarežģīti paskaidrot kā vispār lietot FTP, kur nu vēl skaidrot par kaut kādiem read only un upload folderiem. Kā arī tas varētu būt mazliet sarežģīti, jo paši lietotāju folderi atrodas uz windows servera un tiek mountēti kā tīkla šāres, tāpēc tur būtu jādomā kā to sataisīt, ka tikai home folderos ir tikai lasīšana un apakšfolderos ir arī rakstīšana.

 

Ierakstīju šo jautājumu arī linuxquestions.org mājas lapā:

 

http://www.linuxquestions.org/questions/linux-security-4/vsftpd-and-chroot-4175431314

 

taču nesanāca atrast atbildi arī tur.

 

Tātad jautājums, vai kādam ir sanācis atrast kādu sakarīgāku informāciju par šo?

 

Izmantoju:

 

Slackware 14,

glibc 2.15,

vsftpd 3.0.2.

 

Jau iepriekš paldies!

[marrtins]

Hmm, nekad neesu uzdūries uz šāda "prikola". Vienmēr ir varēts ierakstīt iechrootētā home folderī.

Parādi savu vsftpd configu?

[F3llony]

Aplūko vsFTPD direktīvas:

 

local_root

chroot_list_enable

chroot_list_file

[Maris-S]

Laikam neizteicos īsti precīzi. Visumā sanāk pievienoties FTP serverim, ja izmanto

 

allow_writeable_chroot=YES

 

bet noklusēti šī opcija ir izslēgta drošības apsvērumu dēļ, jo vsftpd ražotāji uzskata ka tas ir potenciāli nedroši, ja lietotāji tiek chroototi home folderī un tam ir rakstīšanas tiesības, tikai home folderim, apakšfolderi tad var būt ar rakstīšanas tiesībām, piemēram folderis upload. Dažviet var atrast informāciju kā to apiet un kāpēc tas ir, bet nekur nav konkrēti aprakstīts potenciālais drošības bugs. Piemēram šeit, ieskaitot komentārus:

 

http://www.benscobie...t-inside-chroot

 

vai arī šeit (pirmais komentārs):

 

http://www.opennet.r...shtml?num=32459

 

bet šeit tiek rekomendēts tieši neizmantot home folderi ar rakstīšanas tiesībām.

 

 

Direktīva local_root arī redirektēs lietotāju uz cit direktoriju, no man vsftpd.conf:

 

local_root
 This option represents a directory which vsftpd will try to change into after a local (i.e. non-anonymous) login. Failure is silently ignored.

 Default: (none)

 

bet vajadzētu panākt to, lai lietotājs paliek savā mājas folderī, nekur augstāk netiek un uzreiz patiešo tur var kaut ko rakstīt, bez visādiem upload folderiem. Vienīgais kā sanāca ir izmantojot:

 

allow_writeable_chroot=YES

 

bet jautājums ir, vai tas ir pietiekami droši, ja diezgan daudzās pamācībās, ieskaitot vsftpd dokumentācijā, to darīt nerekomendē?

Edited November 6, 2012 by Maris-S

[F3llony]

1. Kāpēc Tev obligāti jā-chrooto mājas direktorijā?

2. Bez allow_writeable_chroot izveido mājās mapi uploads, uztaisi rakstāmu, mājas atstāj lasāmas, local_root norādi ceļu uz uploads direktoriju. Pēc savienošanās klients nonāks /home/user/uploads, varēs navigēt augšup uz /home/user, bet augšupielādēt varēs tikai /home/user/uploads, kur lietotājs nonāks UZREIZ pēc autorizācijas.

[Maris-S]

Paldies par atbildi.

 

Īsti neder, jo tie visi FTP folderi iekšēji uzņēmumā ir pieejami caur parasto windows šāri, kā jau minēju sākumā, tā ir sanācis ka visi tie dati glabājās uz windowsīgā failu servera un tur noteikti kāds aizmirsīs aiziet uz uploads fodleri, vai sajauks vēl kaut ko. Ieskaidrot tiem kas pievienosies pa FTP, lai apskatās root katalogu, ja neatrod failu ir vēl sarežģītāk, jo gadās tādi, kas vispār FTP neprot lietot un tur jābūt priecīgam ka vismaz to ieskaidro. Nu vienkārši runājot visādas šāda veida apiešanas metodes radīs papildus sarežģījumus un agri vai vēlu kāds brīnīsies kur ir faili, nu tāpēc arī priekšniecībai varētu tā visa ķīmija nepatikt. Nākošā problēma būs protams tas ka tie visi folderi tiek mountēti no windows šārēm un tur atkal būtu jādomā kā labāk taisīt home folderi ar read only, nezinu vai var izmantot unix permissions un vai tās paliks pēc servera pārstartēšanas, neesmu to visu izpētījis, jo primārais tomēr ir sataisīt normālu home folderi ar atļauju rakstīt tajā.

 

Kā jau teicu, ir vairākas pieejas kā to sataisīt un man tās ir zināmas, bet jautājums vēl joprojām paliek tas pats, vai ir droši izmantot rakstāmu mājas folderi ar chroot, ja leitotājam nav shell pieejas? :) Cik īsti nopietnas ir tās potenciālās drošības ievainojamības? Jo sanāk ka visi brīdina, pat manuāļos, par ievainojamībām, bet neviens īsti nepaskaidro kā tieši un kādai konfigurācijai jābūt, lai tās izmantotu.

Edited November 6, 2012 by Maris-S

[ieleja]

https://lists.mindrot.org/pipermail/openssh-unix-dev/2009-May/027651.html

[F3llony]

Paldies par atbildi.

 

Īsti neder, jo tie visi FTP folderi iekšēji uzņēmumā ir pieejami caur parasto windows šāri, kā jau minēju sākumā, tā ir sanācis ka visi tie dati glabājās uz windowsīgā failu servera un tur noteikti kāds aizmirsīs aiziet uz uploads fodleri, vai sajauks vēl kaut ko. Ieskaidrot tiem kas pievienosies pa FTP, lai apskatās root katalogu, ja neatrod failu ir vēl sarežģītāk, jo gadās tādi, kas vispār FTP neprot lietot un tur jābūt priecīgam ka vismaz to ieskaidro. Nu vienkārši runājot visādas šāda veida apiešanas metodes radīs papildus sarežģījumus un agri vai vēlu kāds brīnīsies kur ir faili, nu tāpēc arī priekšniecībai varētu tā visa ķīmija nepatikt. Nākošā problēma būs protams tas ka tie visi folderi tiek mountēti no windows šārēm un tur atkal būtu jādomā kā labāk taisīt home folderi ar read only, nezinu vai var izmantot unix permissions un vai tās paliks pēc servera pārstartēšanas, neesmu to visu izpētījis, jo primārais tomēr ir sataisīt normālu home folderi ar atļauju rakstīt tajā.

 

Kā jau teicu, ir vairākas pieejas kā to sataisīt un man tās ir zināmas, bet jautājums vēl joprojām paliek tas pats, vai ir droši izmantot rakstāmu mājas folderi ar chroot, ja leitotājam nav shell pieejas? :) Cik īsti nopietnas ir tās potenciālās drošības ievainojamības? Jo sanāk ka visi brīdina, pat manuāļos, par ievainojamībām, bet neviens īsti nepaskaidro kā tieši un kādai konfigurācijai jābūt, lai tās izmantotu.

 

Problēmas ir (lasīt ieleja linku). Pieņemu, ka root permisiju ieguve varētu būt problēma, right?

 

Iespēja 1: ceri, ka lietotāji nenoleakos pieeju trešajām pusēm.

Iespēja 2: uzraksti savu FTP serveri / modificē esošo no sources, kur hardkodē pieejas noteiktām direktorijām pēc lietotāja vārda.

Iespēja 3: (kā to dara normālas kompānijas) Izstrādā darba protokolu - shēmu un sistēmu ar instrukcijām, kā lietotājiem jālieto sistēma, kuru apstirpina vadība un nosaka, ka visiem lietotājiem tas ir saistošs. Rupjiem vārdiem - manuāli. Visi darbinieki ar to iepazīstas, izprintē un piekarina sev pie nagliņas, un seko šim manuāli punktu pa punktam. Ja kāds kaut ko kaut kur, un neseko tam, kas rakstīts manuālī - pa skaustu un siļķu mucā uz 15 dienām. Šajā gadījumā problēma ir darba organizācijā, ne tehniskajā pusē. Nemeklē tehnisku risinājumu komunikācijas problēmām, tāda nav.

[Maris-S]

Ieleja, paldies par linku, apskatīšos.

 

Problēmas ir (lasīt ieleja linku). Pieņemu, ka root permisiju ieguve varētu būt problēma, right?

 

Īstenībā tur ir tas galvenais jautājums, vai tajā ir tā problēma? :) Kā jau teicu diezgan bieži, ieskaitot vsftpd dokumentāciju, tiek ieteikts neizmantot chroot ar rakstāmu home katalogu, bet kā tieši tas ietekmē drošību, nekur nav aprakstīts, te domāju tieši saistībā ar FTP serveriem, būtībā jebkādiem, ne tikai vsftpd, jo bugs ir (bija) glibc. Vienīgais daudz maz sakarīgais ko atradu, ka varot pie kaut kādiem nosacījumiem serverim iesmērēt savu konfigurācijas failu, bet kā tieši un vai tikai FTP konfigurāciju, tā arī neatradu. Zināmā mērā to varētu uzskatīt kā root pieejas ieguvi.

 

 

Iespēja 1: ceri, ka lietotāji nenoleakos pieeju trešajām pusēm.

 

Domāju ar to būs viss labi, jo lietotāji diez vai būs ieinteresēti kādam atdot savu paroli.

 

Iespēja 2: uzraksti savu FTP serveri / modificē esošo no sources, kur hardkodē pieejas noteiktām direktorijām pēc lietotāja vārda.

 

Nebūs šoreiz īstā pieeja, jo, kā jau teicu, bugs ir (bija) glibc, lai gan tīri teorētiski varētu rakstīt FTP serveri, kam lietotāju lockošana ir realizēta ne caur chroot, bet nu par šādas idejas lietderību jau visi saprot ko varētu pateikt. :)

 

Iespēja 3: (kā to dara normālas kompānijas) Izstrādā darba protokolu - shēmu un sistēmu ar instrukcijām, kā lietotājiem jālieto sistēma, kuru apstirpina vadība un nosaka, ka visiem lietotājiem tas ir saistošs. Rupjiem vārdiem - manuāli. Visi darbinieki ar to iepazīstas, izprintē un piekarina sev pie nagliņas, un seko šim manuāli punktu pa punktam. Ja kāds kaut ko kaut kur, un neseko tam, kas rakstīts manuālī - pa skaustu un siļķu mucā uz 15 dienām. Šajā gadījumā problēma ir darba organizācijā, ne tehniskajā pusē. Nemeklē tehnisku risinājumu komunikācijas problēmām, tāda nav.

 

Piekrītu, bet dažreiz ir jātaisa tā kā vajag sataisīt, kā grib priekšniecība, klients utt., nevis kā vieglāk administrēt (un iespējams arī pareizāk). Īpaši, ja jau ir kaudze FTP serveru, kuri ir realizēti ar lockotiem lietotājiem un rakstāmu root folderi, īpaši jau uz windows serveriem, jo tur nav tāda chroot par ko domāt. Tātad, būs vienkāršs jautājums, kāpēc citiem var un mums nevar?

 

Tas kas man tagad interesē, ir problēmas būtība. Kā sataisīt jau risinājumi ir, bet nepatīk kaut ko darīt ja ir kādi drošības brīdinājumi, nenoskaidrojot par ko un kāpēc tie ir.

Edited November 12, 2012 by Maris-S

[Maris-S]

Ieleja, izskatās ka tajā saitē ko iedevi teorija ir uz to pusi, vienīgi tā ātri izlasot neizpratu visu, nav arī domu kā to attiecināt uz FTP, bet papētīšu sīkāk. Vēlreiz paldies!