Názory k článku
Do ProFTPD byl propašován zákeřný kód
-
tak napriklad:
- http://kerneltrap.org/Linux/Abusing_chroot
- http://www.bpfh.net/simes/computing/chroot-break.htmlJe to sice uz stare, ale na ukazku/pochopeni je to mnohem lepsi, nez Vas predchozi prispevek.
>> návod zveřejňovat rozhodně nehodlám. Kdo chce, vygoogluje si ho sám.
Naopak, z bepecnostnich duvodu by se meli tyto problemy vsude resit. -
lojza (neregistrovaný)
V clanku na ktery to odkazuje je napsano, ze utocnici kompromitovali FTP server s distribuci zdrojovek a ty pozmenili.
Nikolov ze by nekdo z vyvojaru pridal zamenrne do zdrojovek nejaka zadni vratka.
Pokud nekdo ziska pristup k programu urcenych ke stahovani a pozmeni je, tak je uplne jedno, zda meni binarky nebo zdrojovky. Naopak ve zdrojovkach se pripadne backdoory lepe hledaji.
Spise to ukazuje na to ze je dobre, pokud vyvojari soubory nejakym zpusobem podepisuji (nevim zda je to pripadd ProFTPD). Pak se mezi stahovaci drive ci pozdeji najde nekdo, kdo podpis zkontroluje (a klic autoru nestahuje ale ma jej z drivejska) a na problem se timto prijde.
-
Michal Kára (neregistrovaný)
Snad pro-open source, ne? Přišlo se na to za pět dní, s minimálním reálným dopadem. Za jak dlouho by se na to příšlo, kdyby se někdo naboural do MS a vložil backdoor do některého jejich produktu? A nejsou tam náhodou právě teď nějaké podobné backdoory? Těžko říct, ověřit si to nemůžeme, tak musíme jen doufat...
(Ten kód tam nepropašoval oficiálně nějaký přispevatel, ale hacker, který naboural distribuční server.)
-
KapitánRUM (neregistrovaný)
Tohle je obecně bolest všech produktů na kterých se podílí dobrovolníci(Linux i Widlo) a dá se tomu jen těžko zabránit. Myslím, že jediné řešení je koncepčně nový systém, kde vše pojede ,,ve vlastním (para)virtualizovaném prostředí" a programy spolu budou moci komunikovat jen na úrovni portů a proudů.
-
KapitánRUM (neregistrovaný)
Abych to doplnil, myslím že i Linux se k tomu dobere.
Stačí pár větších průšvihů a lidi začnou přemýšlet jak ,,všechno" umístit do vlastního Jailu. Ke sdílení souborového systému (tím nemyslím uživatelská data) neexistuje jediný rozumný důvod. A až doba dozraje, určitě někoho napadne jakým způsobem ukládat uživatelská data, aby program měl přístup jen těm která skutečně potřebuje.Možná dojde i na různé druhy balíčků.
Virtualizovaný balíček - například soubor .Vjail fungující na všech systémech bez ohledu na knihovny pod univerzálním strojemZdrojový balíček - sloužící k přeložení programu jen k vůli kompatibilitě s instrukční sadou daného systému, výsledkem kompilace bude jeden soubor .jail tj. spustitelný soubor obsahující zároveň adresářovou strukturu (něco jako JAR v JAVA)
Pro programy jako je MC by měl operační systém zajistit automatické mountování k vůli konfiguraci. Konfigurační soubory přesměrované pomocí simlinků z ETC dovnitř těchto balíčků.
Ostatně podobná řešení už existují.
-
Jiří J. (neregistrovaný)
Problém je, že "jail" není komplet vlastní adresářová struktura včetně binárky, knihoven a všeho ostatního. Systém načte binárku do paměti, loader se podívá na dynamické závislosti na knihovnách, slinkuje to s binárkou a pak až pustí program (po chrootu). Program pak "uvidí" novou adresářovou strukturu, která může být úplně prázdná, rootem počínaje, přesto mu to z hlediska běhu stačí, protože už je celý v paměti.
Pěkná věcička na to je "fakechroot", doporučuji nakouknout, je to LDPRELOAD hook pro chroot tak, aby mohl chrootovat i non-root uživatel. Nebudeme přece věřit chrootovacím technikám v samotných programech ;) -
KapitánRUM (neregistrovaný)
Jaký je rozdíl mezi správou Linuxového serveru a řízením jaderné elektrárny?
Odpověď: Pro správu Linuxového serveru si musíte pamatovat podstatě víc věcí :-DTím nechci útočit na Linux, jen se člověk často prostě drbe s ohromným množstvím blbostí, různých obezliček, různých koncepcí a člověka to začne štvát. Pak může jen závidět Homeru Simpsonovi práci u řídícího pultu v jaderné elekrárně.
-
ad jail -- pomoci unshare lze udelat samostatny namespace, v nem potrebne adresare a pak "mount --move" na novy root a nakonec chroot a exec binarky z noveho rootu. Z takoveho prostredi uz nelze nikam utect.
(BTW, todle se pouziva (bez toho unshare) v kazdem systemu s initramfs, viz. man switch_root.)
Jinak designovat novy system neni treba, potrebne oddeleni aplikaci poskytuje napr. SELinux.
