Apache upgrade = biztonsági downgrade

Hát úgy kell beállítani a rendszert, hogy a T. user akivel apacs meg a php fut, ne lásson semmi olyat amit nem szabad neki. Nem egy nagy ördöngősség, és amúgy is érdemes megcsinálni :)

Hat ... Es a backup vagy vmi? ;-) Az hagyjan ha en irogatok vmi, de egy fejleszto cegnel azert ciki, ha egy gepen van minden, mert ugye tortenhetett volna mas is: pl hdd kampec vagy akarmi es akkor is ugrott volna. Vagy ez volt a Commodore koltseghatekonysagnovelesi intezkedesi kozul egy: nem backup-olunk, az sokba kerul :)

Egyébként tényleg a grsecurity patch része, a forrás, a mellette levő doksi és phcrack olvasgatása sokat lendít a tájékozódáson :-)

hello. gondolom, phcrack helyett phracket akartál írni.

Valamint a google használata, ami jól elindít mindenkit az alapokon. Csak meg kell keresni.

A google használata már elindított az alapokon, köszi, már meg is kerestem, google.com. a címe! ;P

Az külön izgalmas, ha valami alapján meg tudod mondani, hogy milyen infó merre mehet a gépen belül.

A hálókártyától a processzorig, vagy hogyan a gépen belül? :D

Egyébként a lényeg amit mondani akartam a sok rendszernél és amivel nem értek egy hunger-rel. Egy jó fejlesztő figyelemmel kísér más rnedszereket. Például miért ne használnál CARP-ot linuxon, ha az OpenBSD-sek megcsinálták és portolni kell?

Te használd nyugodtan, de ha én nem Linux alatt használom, akkor se kell rám haragudni. ;)

Egy jó fejlesztő nem lenézi a másikat, hanem tiszteli és tanul tőle, ha van mit, együtt gondolokodik vele.

Az elgondolásod alapján nem lenne egymás mellett párhuzamosan futó project?

Mint egy naiv, hozzanemerto, kulso szemely kerdezem: mi oka lehet az apache fejlesztoinek, hogy eldobjak az openbsd-sek altal irt patcheket, ha azok tenyleg jok, es sulyos hibakat javitanak?

Vicces valasz: openbsd arcmeret ? :)

Az OpenBSD-s Apache fork eleg sok mindenben elter az eredetitol... tobbek kozott a parent process sem fut rootkent es alapbol chrootol a /var/www ala, igy akarmilyen hiba is van a webszerverben vagy CGI-ben/PHP-ben akkor sem erheto el azon keresztul a teljes filerendszer. De persze ezen kivul meg rengeteg mas javitas is van, amely nem kerult be az apache fejlesztoi valtozataba.

Te kis vicces

A cikk azt sugallja, hogy az alap apache, amit az apache.org-rol toltok le televan komoly bugokkal, amit nem tudnak/nem akarnak kijavitani az apache fejlesztoi.

A hozzaszolasodbol azt szurom le, hogy amit az openbsd fejlesztoi "komoly bugok"-nak mondanak, azok inkabb design-beli elteresek, amelyek az apache fejlesztoinek nem tetszenek.

Most akkor hol az igazsag?

privilege separation nelkul kiadni valamit mar sulyos bugnak szamit :)

Jaj és persze akkor nem beszélve default chroot-ról.

ez elviekben mind szep es igaz, de sajna azon feltetelezesen alapszik, hogy a kernel hibamentes, ezt pedig en nem mernem egyetlen open source kernelrol sem kijelenteni...

Akkor STFU, es hasznalj sajat magad altal perditett apache-t. Es bizd magad a PaX -ra. Tudod OpenBSD is PaX kodot lopta szet, csak kar, hogy OpenBSD -ben a pax == read and write file archives and copy directory hierarchies

Ismét thuglife -ot láttuk/hallottuk... illetve az ő nagy arcát... :)

Ebbe mi volt a nagy arc? En csak eloadtam az elmeletem :)

latod, ha nem a vakhit vezetne es tenylegesen is megertened, amit olvasol, akkor rajohettel volna, hogy en nem csak az OpenBSD-rol beszeltem ;-)

En meg kifejezzen a PaX al szenbeni utalatomat fejeztem ki :)

A te saját, szép stílusodban.

Na mar te is ittvagy? Kezdem magam IRC en erezni. Tiszta szegyen.

Azért érdekes, hogy egy kis "apró" dologból mekkora flame tud keveredni... elég, ha csak thuglife megjelenik... :)

Nem mondtam, hogy csak ennyi a különbség az eredeti Apache és az OpenBSD fork között... Ha az apró bugok kijavítását akarod megnézni, hasonlítsd össze a forrást. ;)

Szerintem ez nem apro dolog. Nem tudom, hany olyan project van ami szembe mer szallni a dolgokkal.

Énse, de ettől még jobb, mint ha privsep se lenne és egy PHP-vel is akár olvasható lenne az egész fájlrendszer. Mert ugye nem csak puffer túlcsordulással lehet kihasználni egy hibát... ;P

Jobban mondva, nem csak puffer túlcsorduláson alapuló hibák léteznek. :)

Mindenki látta, hogy thuglife írt, oda van biggyesztve a nickje. Inkább az álláspontodat fejtsd ki, az talán még hasznos is lehet. ;)

4.4-es X-et hányan utasították el?

Mi a bajod vele? Most érettségizett! Legalábbis az érettségi most volt ;PP

Az OpenBSD szembe mer szallni a vilaggal! Jolvanakkor, ezekszerint az obsd lazado kamaszok os-e? :PP

Tudod mi a Te bajod? Hogy fiatal vagy. Majd mikor érsz ég egy két évet és munkába állsz, akkor _esetleg_ megváltozik a szemléleted. Voltam én is linux fanatikus, amikor azt hittem az mindenre jó. Ma használok/tam és adminisztrálok MacOSX-et, FreeBSD-t, régeben volt OpenBSD-m, mikor még nem volt divat, mint amikor Te felvetted, gondolom, használok linux disztribeket, ha kérik akkor SuSE-t, RH-t, mert ahhoz van hivatalos Oracle support, ami számít, ha a cég már kifizetett jó sokat egy Oracle licencre. Használok Debiant, sőt, windows-os szoftvert is. Ezt hívják úgy, hogy profizmus. Amíg téged a szüleid tartanak el, addig szerintem nem tudsz a való életről nyilatkozni. Ez persze nem szégyen, ha nem bunkó módon teszed meg, mert egyszerűen nem adatott még meg neked a lehetőség korodnál fogva. De ha bunkó vagy másokkal, akkor mit vársz?

Ami a priv separationt és a chroot-ot illeti. A chroot az egyik legnagyobb téveszme és a priv separation sem véf meg mindentől. A php moduljának be lehet állítnai sok mindent egyébként az apache konfigban, virthostonként is, de még jobban is akár. chroot-bol minden hülyegyerek ki tud törni. Hallottál a ptrace-ról és társairól? A védelemnek csak egy része lehet a chroot. Ha le van az is korlátozova. Mondok egy két kiinduló pontot: FreeBSD jail, RSBAC kerneles jail, RC modul, Balabit restrict, grsecurity :-) SEMMI nem nyújt egyedül teljes biztonságot.

Ezt a "chroot-ből minden hülyegyerek ki tud törni" dolgot vázolnád kicsit? :) Komolyan érdekel, nem kötekedésből írom.

Igen erre en is nagyon kivancsi lennek.

Kedves Ago. Azzal, hogy a sokféle rendszert használsz úgy gondolom, hogy nem vagy egyedül. Szinte mindenkinek aki komolyabb helyen rendszergazda (nagyképűen: rendszermérnök) annak több féle rendszerrel kell foglalkoznia. MI használjuk és karbantartjuk azokat, amelyeket mások fejlesztenek. Thuglife NEM rendszergazda, ő egy a fejlesztők közűl, akinek nem kell minden rendszert alaposan ismernie, hiszen egyhez köti a szíve és az alá fejleszt, azt javítgatja, használja. Természetesen mindenkinek meg van a saját kedvence és a fejlesztők különös tekintettel elfogultak azokkal a rendszerrel amelyek alá ők fejlesztenek. Thuglife stílusát lehet szeretni, nem szeretni, de egy valami biztos: halálra röhögi magát azon, hogy amit ő viccből elkezd gúnyolni, leszólni azt mások mennyire komolyan veszik és hogy megsértődnek rajta. Ez a fajta modor egyébként is passzol az OpenBSD csapat stílusához és ő nem akar kihúzó lenni, felveszi a Team szokásait, még ha azok sok embernek szúrják is a szemét. :-) Minden embernek el kell fogadni a véleményét, még ha nem is egyezik a miénkel. OpenBSD feltörhetetlen? Nem hiszem, hogy mondott volna ilyet, de ha igen, akkor sincs semmi... Szerintem több embertől hallottam 10 évvel ezelőtt ugyanezt a Linuxról.

Chroot. "Minden hülyegyerek ki tud belőle törni". Ez ebben a formában nem igaz. Először is chrootoláshoz root jogok kellenek, leginkább a "kitöréséhez" is. Nem patchelt linux esetében valóban könnyű belőle kitörni (chroot "../../../../"), de ez nem igaz a BSD-kre és a grsec-el patchelt linux kernel is védelmet nyújt ellene (természetesen helyes konfig esetén). De ugye chrootban is root jogot kell először szerezni ahoz, hogy kitudj belőle törni.

Ptrace? Ép eszű embernek nincs is a kerneljébe fordítva, hacsak feltétlenül nincs rá szüksége...

RSBAC? RC? SE? MAC? Mind1ikkel védett rendszert törtek már meg, mert kernelben lévő kihasználható bug esetén semmit se érnek. Ami kicsit bizalomgerjesztő OpenBSD esetén, hogy a kernelben lévő hibákat sem olyan egyszerű kihasználni, mert kernel-szintű propolice van, amelytől ugyan lassabb az egész rendszer, de valóban biztonságosabb. Erre jó példa a 2.x - 3.4 exploitok (select() exploit, exec_ibcs2_coff_prep_zmagic() exploit, stb.) amelyek 3.3-ig tökéletesen kihasználhatók voltak (pedig 3.3-ban már volt propolice, csak kernel-szinten nem volt engedélyezve), de 3.4-ben már nem lehetett könnyen kihasználni privilégium-emelésre a hibát, csak local DoS-ra... A véleményem természetesen az, hogy "No Security in this crazy World" ;-) Udv.

Ezt most NEM ertem ... Miert, a closed source kernelek azok jobbak ilyen szempontbol? ;-)

ha már szerzett a chrootban egy root shellt, akkor gondolom magától értetődik, hogy hogyan kell kijönni... ;-)

mivel te irtal a legtobbet a chroot-rol, ide valaszolok, remelem, hogy azert a tobbiek is elolvassak.

a chroot()-bol valo kitoreshez nem feltetlenul szukseges maga a chroot(), megteszi mas is (mknod, ptrace, chmod, stb, nezzetek meg a grsec 'chroot restrictions' listajat).

egy kernel bug persze mindent ut, es ez ellen a kernelbeli ssp NULLA vedelmet nyujt, legalabbis az a fajta, ahogy jelenleg hasznaljak.

ennek oka az, hogy trivialis megtudni a kernelben hasznalt __guard erteket, annyi info leak van (es akkor nem is beszelve a kernel heap overflow-okrol, ahol az ssp se nem oszt se nem szoroz). az altalad emlitett OpenBSD bug-okra van mukodo exploit minden erintett kernelverziora, csak mivel mas, 0-day info leak bugra epulnek, nem publikusak.

a megoldas (amibol a userland is profitalna kulonben) az lenne, hogy ha a __guard erteke dinamikusan (futasidoben) valtoztathato lenne (ekkor pl. a kernelbeli ssp eseten minden kernelbe lepesi ponton minden taszk sajat __guard-ot generalhatna, az info leak nem erne semmit). sajna amikor utoljara felvetettem az otletet Hiroaki Etoh-nak, nem igazan fogta fel a jelentoseget (pl. nem hallott info leak bug-okrol...) es gyakorlatilag a dolog elhalt azon a ponton.

PS: akik olvasnak franciaul, spendernek volt egy cikke egy tavalyi MISC magazinban, abbol meg lehet tudni a chroot()-tal kapcsolatos reszleteket.

hat a PaX peldaul ;-). 3-4 eve a vilag 'bolcsebbik' fele azt sem tudta, hogy eszik-e vagy isszak az intrusion prevention-t (az Entercept-en kivul nem tudok hasonlo kaliberu cegrol abbol az idobol), ma meg mar a vizcsapbol is ez folyik.

Miért, original apache rootként fut?? Nálam amióta az eszemet tudom, www-data volt, vagy valami hasonló. Csak addig root, míg felbindel 80-as portra.

Chrootra meg ott van mod_chroot, vagy mifene. Alap chroottal az a gond, hogy ahhoz csomot kell szöszölni azzal, hogy a juzerek programjait az ember bepakolja a chrootba.

És mivel apachot aki rootként futtat, az eleve valamit elszűrt. Betörő meg max az apacs userével (vagy a CGI/PHP userével) tudna mászkálni a filerendszeren, magyarul max defacelni tudna. Ezt pedig chrootolva is simán megteheti, ha van annyi hozzáférése a fileokhoz. Ha meg nincs, akkor chrooton nélkül sem feltétlenül lenne.

> sajna amikor utoljara felvetettem az otletet Hiroaki

> Etoh-nak, nem igazan fogta fel a jelentoseget (pl. nem

> hallott info leak bug-okrol...)

És ha most is felvetnéd neki...? :)

Eloszor is koszi a hozzaszolast.

Ha jol ertem, akkor te a __guard ertek alatt a canaryben levo random (vagy time hash) ertekre gondolsz, amely nyilvan a kulcspontja az egesz propolice vedelemnek. Azt mar olvastam rola, hogy sajnos nem annyira random mint amennyire kellene es 2 egymas utan levo pufferturcsordulassal konnyen meghatarozhato a korrekt ertek. Ami a kerdesem lenne az az, hogy szerinted mennyivel nyujt nagyobb biztonsagot a -fstack-protector-all kapcsolo hasznalta.

OpenBSD alatt egyebkent a / -en kivul a tobbi particio nodev kapcsoloval van felmountolva, ezert az mknod szinten kiesik a kitores listabol, a tobbirol meg nem tudok nyilatkozni, de pl. a ptrace nekem sehol sincs a kernelben.

Egyebkent szivesen olvasgatnek magyar leirasokat is az ilyen es hasonlo problemakrol, nincs kedved forumot nyitni rola? :D

hello. Na, van időm megint írni. A chroot kérdéseket megválaszolták már. Egyébként tényleg a grsecurity patch része, a forrás, a mellette levő doksi és phcrack olvasgatása sokat lendít a tájékozódáson :-) Valamint a google használata, ami jól elindít mindenkit az alapokon. Csak meg kell keresni. Egyébként ha nem is root vagy, akkor is rengeteg más lehetőséged van. Például, ha van tcp kacsolat kifele adatbázishoz stb. vagy ki tudsz jönni egyéb módokon a chrootból engedélyezetten. Ezért kell lekorlátozni minden létező módon a rendszerhívásokat, a kapcsolatnyitási lehetőségeket. Az külön izgalmas, ha valami alapján meg tudod mondani, hogy milyen infó merre mehet a gépen belül. Majdnem "host-tűzfal" ami kellhet. Van integritás és van információvédelem. Egy chroot csak a kezdet lehet, ami le kell korlátozni. Vannak egyébként jó projektek erre. Az,hogy megtörnek egy RSBAC-os gépet, előfordulhat. Ha volt kiemeltebb lokális joga és usere a webszernek/rdbms-nek/XY-nak. De van amikor még itt is lehet tenni sok mindent. Hosszú téma ez. Ja, és jó megoldás nincsen :-)

Trey-jel egyetértek, a rendszergazda és a rendszermérnök közötti különbségekről. Sajnos ma csak a pénz dönt az esetek 80%-ban, hogy kit választanak, pedig a rendszegzdák nagy részére ráillene a betanított segédrendszergazda jelző. Semmi kreítivítás, porgrmaozási alapismeretek legalább, nincs mélyebb ismeret. Kb., mintha lenne egy telefonközpont programozó eszközöd, be tudod álítnai, de nem tudod miért működik úgy ahogy, nem ismered az átviteltechnikát, stb.

Egyébként a lényeg amit mondani akartam a sok rendszernél és amivel nem értek egy hunger-rel. Egy jó fejlesztő figyelemmel kísér más rnedszereket. Például miért ne használnál CARP-ot linuxon, ha az OpenBSD-sek megcsinálták és portolni kell? Miért ne lehetne device mapper szintű dolga egy BSD-nek, dm-crypt-tel? Miért ne lehetne portolni X featuret vagy továbbfejleszteni azt, ha hasznos. Egy jó fejlesztő nem lenézi a másikat, hanem tiszteli és tanul tőle, ha van mit, együtt gondolokodik vele. Vagy az OSS lényege nem ez?

thuglife-ból hiányzik a megfelelő alázat a többiek iránt, a másik munkájának elismerése (más társaságé). A másik a pénz. Hogy ő mindent ingyen csinált. Megnéztem a ports fát, valóban van 8-10 bejegyzése. Kernel és alaprendszer fejlesztésben benne van? Ha nincs, akkor mondhatnánk, hogy "csak csomagoló". De ez is fontos rész, amit el kell végezni valakinek, azonban hasznosabb a linux terén pl spender munkája, mint thuglife munkája obsd-ben. De például, ha Linus-t vagy Theo-t nézzük, akkor azonos fajsúlyú embereket látunk. De Theo talán ingyen dolgozik? Az, hogy ingyen ad valamit, az nem azt jelenti, hogy ingyen kap ő is mindent ezért cserébe. Nem full állásba nem kevés pénzért (mgérdemelten) akart Theo felvenni egy embert a DARPA pénzéből? Nem kért talán Kemp pénzt a full time munkáért? Az ő _fizetett_ munkájuk gyümölcsét élvezheti, ezért a pénzt kérő hasznos embereket nem lenézni kell, hanem támogatni. Kicsit eltért a témától, de megpróbáltam rávilágítani az általam gondolt jellembeli hiányosságokra és a ferde logikára bizonyos esetekben. Az igazi fejlesztők tisztelik egymást - persze flame szokott lenni, de pl volt amikor valaki lszarozta a qmailt postfix listán és, hogy valami szarul van megírva benne, ***** programozás, ezért nem megy valami. Venema viszont elküldte melegebbre az illetőt, mert mint mondta DJB-vel nem értenek mindenben egyet, de programozni tud és biztos, hogy ilyen hibát nem követett el, főleg, hogy csak egy embernek jött elő, aki bejelentette. Igaza is volt. Na, ez a normális viselkedés.

ez iden aprilisban volt, nem tudom, mit csinal/gondol azota. akkoriban kb. idaig jutottunk:

> If you can know the __guard value of a running SSP-enabled program by

> attacking the buffer overflow vulnerabilities, it must be a flaw of SSP.

> Do you find such a way?

info leaking can occur when the overflow is for *reading*, not writing.

a __guard az a C nyelvi szinten definialt valtozo, amit az ssp minden fuggvenyhivaskor bemasol a verembe (ezt hivjak altalaban canary-nak, vagyis ebbol sok lehet egyszerre a vermen, kb. annyi, amilyen melysegu a fuggvenyhivasi lanc az adott pillanatban), majd a visszeteres elott osszehasonlitja oket. azt nem tudom, mibol gondolod, hogy nem eleg random, az osszes felhasznalo akirol tudok (OpenBSD/Adamantix/Hardened Gentoo/Hardened LFS) eleg jo generatorbol nyeri az erteket, az kriptografiailag biztonsagosnak szamit.

az fstack-protector-all annyival jobb, amennyivel tobb fuggvenybe kerul ssp vedelem emiatt, nekem gozom sincs a gyakorlati szamokrol. mondjuk annyi ertelme biztos van, hogy ezaltal azok a fuggvenyek is vedve lesznek, amelyekben nem char[] alapu puffertulcsordulas van.

a nodev egy jo megoldas kiveve, amikor a chroot() gyokerkonyvtarak nem a /-en vannak es neked megis kell nehany device node... (/dev/null, /dev/zero, /dev/random, stb). pl. a linux-os ssp megoldasok tobbnyire a /dev/urandom-t hasznaljak entropia forrasnak, ill. vannak progik, amik nem tudnak a MAP_ANONYMOUS-rol es helyette a /dev/zero-val buveszkednek.

szerinted tenyleg van olyan, hogy closed source? meg a windows sem az ;-)

ugyan trey, ezt te sem gondolod komolyan. attol hogy valaki elvegez egy par hetes/honapos gyorstalpalot, attol o mar mernok, anelkul h a megfelelo matematikai/termeszettudomanyos alapokkal rendelkezne? mert lehet erre azt mondani, h aa mutass mar olyan rendszermernokot aki ul a gepnel es integral, ahhoz h egy rendszer mukodesevel (ugy kvazi dolgok megertesevel) tisztaban lehess, ahhoz igenis kell ez a fajta tudas, ami nem is konkret gyakorlati alkalmazasaban, hanem egy szemleletmod kialakulasaban nyilvanul meg.

nah ettol lesz valaki mernok.

AKkor nem neztel eleg jol korul. Igen van src be is munkam. Es sok mas egyeb dologgal is foglalkozok. De ez most itt lenyegtelen. Azt, hogy en kit tisztelek meg kit nem az csakis ram tartozik. Hidd el nagyon nagyon keves embert tisztelek és azt is elhiheted nekem, hogy ebbe Linus is benne van. Persze ettol meg nem kedvelem a linux kernelt. Arra pedig csak annyi lenne a valaszom, hogy ki hasznosabb, hogy mindeki potolhato. spender-is es en is. De, hogy kicsit letorjek az egodbol, elarulom azt, hogy te is. Es azt is hidd el nekem, hogy zamomra spender munkaja valahogy nem hasznos. Azt is elhihetetd, hogy az en munkam vagy akarmely mas OpenBSD developer munkajat is leszarja spender. Es mivel en sok embert lenezek, ezért én egy ***** fejlesztö vagyok, a te velemenyed szerint. Erted szerintem meg sut kint a nap.

hol allitottam en ezt?

en csak annyit allitok h ilyen MCE MCSE es hasonlo szerencsetleneket ne csufoljunk mar mernoknek. mert nem azok.

elbeszelunk egymas mellett megint (esku, ez az uccso postom ebbe a topicba;) szal en meg csak annyit mondtam, h regebben a mernok szonak volt becsulete. ma mar nincs, koszonhetoen h elkezdtek ezeket a kattintgatos droidokat is igy becezni :D szummaszummarum, nem ertek egyet az elnevezessel (most nem fogom meg egyszer elmagyarazni, h mitol lesz -- sztem -- vki mernok).

Van. A Commodore Amiga UNIX :) (AMIX)

Tortent ugyanis hogy az ESCOM a Commodore megvasarlasa utan gyanutlanul leformazta a fejlesztoi gepet, ezaltal veglegesen megsemmisitve a forraskod egyetlen letezo peldanyat.

Nem egy (linuxos) szerveren lattam azt, hogy a .php scriptek annyira jol voltak megirva, hogy szinte az egesz filerendszert olvasni lehetett. Belertve /etc -t is. Chroot az ilyen hibak "kivedesere?" is megfelelo szerintem.

Az src-t meg sem néztem, mivel nem állok neki cvs-ben keresgetni, ha úgyis van lent ports-om, abban egyszerűbb keresni.

Az, hogy hiányzik belőled a tisztelet azok iránt, akik elértek valamit, téged minősít. Ezek az emberek ugyanis nem úgy értek el valamit, hogy átgázoltak másokon, hanem úgy, hogy sokat dolgoztak érte. De látszik, hogy magadból indulsz ki, ugyanis nem kell letörnöd az egodból, pontosan tudom, hogy én is pótolható vagyok, soha nem hittem másként és bennem megvan mások tudása iránti alázat. Ha csak Obsd-t használsz, akkor is hasznos lehet számodra spender munkája, ha megnézed milyen öteleteket lehet belőle meríteni például, milyen stílusban kódol, van-e ami szebb megoldás. Az utolsó mondtaról nem nyilatkozom :-) Ezeken a flamewarokon és melyik rendszer jobb, azon már régen túl vagyok.

A linuxos szerveren levő php, ami tud fájlrendszert olvasni kicsit bugyuta hozzászólás volt. Miért, ha obsd-re teszik, akkor nincs szarul megírva? Ha ez alapján belátnak a db-be, ahol user adatok is lehetnek, akkor mit érsz azzal, hogy nem látom a /etc/passwd-t? Amúgy is mit érsz azzal? A felhasználói jelszóval már lehet alakítani csúnyább dolgokat. Mindig az adat az értékes, nem a gép. Te max egy - nem láttam a munkádat és ha látom sem biztos, hogy jól meg tudom ítélni - tehetséges, de emberileg nem brilliírozó ember vagy. Neked a többiek ellenségek. Egy normális embernek a versenytársak ellenfelek. Mint a sportban. Persze a sportszerűség is kihalt a vadászpuskákkal.

Ezt azért irtam, mert en meg nem lattam olyan linux distrot ahol default chrootolna apache. Persze ha tevedek akkor elnezest kerek.

Trustix, Adamantix(?), volt egy skandináv is... , volt egy RSBAC alapú orosz, ahol ha jól emlékszem jailben volt (Alt), de ez utóbbi sem biztos, mert ott elég sokat változtattak dolgokon. Egyébként van jónéhány házi megoldás (értsd: sok kis disztrib), amik használnak ilyen megoldásokat. Én abban hiszek, amit az ember maga állít össze. Az olyan lesz, amilyennek lennie kell. Igaz, ez időbe kerül.

lol