LINUXZONE






 >> Hlavní stránka

(1751/28.09.2010)


 >> Administrace

(161/05.08.2010)


 >> Literatura

(312/14.09.2010)


 >> Bezpečnost

(347/17.09.2010)


 >> Programování

(307/19.04.2010)


 >> Distribuce

(98/16.09.2010)


 >> Síťování

(86/03.06.2010)


 >> Lokalizace

(10/15.09.2004)


 >> Aplikace

(176/12.08.2010)


 >> Multimedia

(32/31.03.2006)


 >> Hardware

(45/02.03.2007)


 >> Začínáme

(229/09.09.2010)


 >> Aktuálně

(564/20.09.2010)


 >> RELAX

(213/28.09.2010)


 >> Jinde vyšlo

přehled ostatních serverů




 Coolhousing




Coolhousing - Vas poskytovatel dedikovanych serveru




 Přihlášení




Login:
Heslo:
 uložit v prohlížeči


Nejste-li ješte zaregistrováni, můžete tak učinit zde.





 Vyhledávání




Hledaný výraz:
v klíčových slovech
v titulku
v anotaci
v textu








 Reklama









 Servis




*   Vaše náměty a připomínky
Máte k Linuxzone.cz nějaké připomínky nebo náměty? Našli jste na stránkách chybu? Dejte nám o tom vědět pomocí formuláře nebo v diskuzi.
Komentářů: 60
*   Podpořte Linuxzone.cz
Chcete podpořit náš server umístěním odkazu nebo zveřejněním backendu? Zde najdete vše potřebné.
*   Pište pro Linuxzone.cz
Máte zájem podílet se na obsahu Linuxzone.cz ať už jako redaktoři nebo i jinak? Dejte nám o sobě vědět!





 Aktuálně z bezpečnosti




-- 
6.12.2005, 19:01
Na serveru informit.com vyšla ukázková kapitola týkající se práce s řetězci z knihy Secure Coding in C and C++. (lz)

-- 
3.12.2005, 12:34
Bugtraq: Format String Vulnerabilities in Perl Programs. (lz)

-- 
3.12.2005, 12:32
Linux Advisory Watch December 2nd 2005. (lz)

-- 
23.10.2005, 13:28
Rozhovor na téma klasické zálohování versus CDP. (lz)

-- 
23.10.2005, 13:24
Linux Advisory Watch October 21st 2005. (lz)

další >>





 Aktuálně o software




-- 
6.12.2005, 19:07
Potřebujete-li pod linuxem rozchodit bezdrát založený na čipsetech Broadcom 43xx, konečně existuje linuxový ovladač. (lz)

-- 
6.12.2005, 19:04
Byla uvolněna verze Xen 3.0.0 virtualizační technologie XEN. (lz)

-- 
6.12.2005, 18:59
Byla uvolněna verze X11R6.9/X11R7 RC 3 grafickérho rozhraní X Window System. (lz)

-- 
3.12.2005, 12:45
Co je nového okolo projektu Amanda (open source zálohovací software)? Více na osnews.com. (lz)

-- 
3.12.2005, 12:40
Jak to akuálně v linuxu vypadá s podporou SATA.. (lz)

další >>





 Aktuálně z IT




-- 
3.12.2005, 12:51
Novellu se daří prodej linuxových produktů, oproti loňskému roku se Novell dočkal výrazného nárůstu. (lz)

-- 
3.12.2005, 12:48
Třetí verzi licence GPL by měla být publikována během jara 2007. (lz)

-- 
23.10.2005, 13:20
V Peru nyní mají zákon, který umožňuje nasazení open source software ve vládní správě. (lz)

-- 
23.10.2005, 13:14
Proč se Microsoft bojí Google? (lz)

-- 
27.9.2005, 22:01
Peru má zákon podporující free software. (lz)

další >>





 Nejčtenější články









 Nejlepší články









 Anketa




Používáte nějaké rozšíření bezpečnostního modelu linuxového jádra?

Openwall (17%)

LIDS (11%)

Pax/Grsecurity (3%)

SELinux (6%)

RSBAC (1%)

jiné (1%)

používám standardní jádro (62%)







Linuxzone.cz - server o Linuxu pro programátory, administrátory a fanoušky.
Provozuje společnost Impossible.
ISSN: 1213-8738





Grsecurity (I)

V dnešním článku si povíme něco o tom, jak vypadá standardní bezpečnostní model na Linuxu, a seznámíme se s jadernými záplatami, který tento bezpečnostní model rozšiřují o další mechanismy, a ukážeme si, jak je využít pro lepší zabezpečení serveru.

Standardní UNIXový bezpečnostní model a jeho nedostatky

Standardní bezpečnostní model, jejž najdeme na většině UNIXových operačních systemů, asi není třeba příliš obšírně představovat. Základem je především systém práv definovaný v několika bitových maskách (specifikující u souboru práva pro vlastníka, skupinu, ostatní a popř. nastavující některé speciální bity, jako je SUID či SGID). Další velmi typickou stránkou tohoto bezpečnostního modelu je uživatel root – administrátor a uživatel s nejvyššími možnými privilegii (jinak řečeno uživatel, jenž může vše).

Tento bezpečnostní model se v praxi v různých UNIXových klonech osvědčil a používá se dodnes. Ale je dostačující na všechy případy? Prvním problémem jsou ona již zmíněná přístupová práva k souborům, jež jsou ze své podstaty poměrně omezená a nastavení práv tak často nutí administrátora k různým krokům, jako je např. vytváření velkého množství uživatelských skupin (a v některých případech ani to není uspokojivým řešením).

Dalším kamenem úrazu je uživatel root, kterýžto jako administrátor prakticky má veškerá možná práva. Některý software část těchto práv ovšem vyžaduje – typickým příkladem je většina síťových démonů, které poslouchají na privilegovaných síťových portech (<1024). A krom oněch potřebných práv tak program zcela zbytečně dostane plnou kontrolu nad systémem, což může být zneužito potenciálním útočníkem, pokud se v onom softwaru vyskytuje nějaká bezpečnostní chyba. Standardně se tento problém řeší tak, že program zahazuje EUID 0 v momentě, kdy již nepotřebuje speciální práva.

Dalším souvisejícím problém je nemožnost efektivní distribuce práv k systému mezi více administrátorů. Příkladem budiž situace, v níž potřebujeme svěřit administraci DNS serveru jinému člověku než tomu, který se stará o zbytek administrace systému. Nasnadě je povolení zápisu do konfiguračních souborů onoho daemonu, ale tím vyřešíme jen část problémů. Onen administrátor též musí mít možnost např. onen server restartovat či mu alespoň poslat nějaký signál (např. pro načtení nové konfigurace), což s sebou přínáší nutnost superuživatelských práv. Jistým řešením je sudo či podobný nástroj, který umožňuje administrátorovi nastavit, jaké příkazy (a pod jakým uživatelem) může daný uživatel spouštět ze svého normálního uživatelského účtu. Nicméně nejedná se o dostatečně flexibilní řešení.

Tyto a mnohé další podobné nedostatky se snaží rešit RBAC (Role Based Access Control) systémy, které do klasického bezpečnostního schématu zavadějí především systém rolí a k nim přiřazených práv. Rolí zde může být cokoliv – uživatel, skupina či cokoliv dalšího. Jednotlivým rolím jsou poté přiřazována práva. Opět se obecně může jednat o jakákoliv práva, ať už o přístupová práva k souborovému systému či povolené/zakázané systémové operace (příkladem budiž např. poslouchání na privilegovaném portu). Tato práva bývají označována jako MAC (Mandatory Access Control), a jak již název napovídá, jedná se o práva nadřazená klasickým DAC (Discrete Access Control) právům nastaveným uživatelem.

Řešení postavená na RBAC v Linuxu

RBAC mechanismy se objevují hned v několika patchích jádra (či rovnou distribucích). Prvním z nich je SELinux (Security Enhanced Linux) vyvinutý v NSA (National Security Agency), který je k dispozici jednak ve formě patche pro 2.4.x jádra a jednak jako LSM modul pro novější řadu 2.6.x.

LSM (Linux Security Module) představuje nový mechanismus v jádrech 2.6.x, který umožňuje jaderným modulům převzít kontrolu nad některými rozhodovacími mechanismy jádra. Přítomnost tohoto mechanismu je zcela jistě velmi významná pro zlepšení flexibility bezpečnostních mechanismů v Linuxu, na druhou stranu LSM též sklidilo poměrně silnou kritiku od autorů jiných bezpečnostních patchů (grsecurity, RSBAC) a ani jeden z těchto projektů nehodlá v budoucnu využívat možností LSM, které se autorům oněch projektů jeví jako nedostačující.

Dalším projektem, který na 2.6.x řadě taktéž využívá LSM, je LIDS. Jedná se o komplexní systém, který krom MAC mechanismů nabízí např. i detektor portscanů, propracovaný ACL systém pracující i na úrovni procesů a další možnosti.

Velmi silné možností nabízí též projekt RSBAC.

Nicméně my se v dnešním článku budeme zabývat patchem grsecurity, který je k dispozici pro 2.4.x a 2.6.x jádra.

grsecurity & PaX

Grsecurity (www.grsecurity.net) je sada záplat linuxového jádra, která v nové 2.x verzi příchází s RBAC modelem, který významně rozšiřuje původní MAC systém ACL práv definovaných pro jednotlivé procesy. Jeho nedílnou součástí je též záplata PaX. Ta přináší krom jiného dvě důležité vlastnosti. První z nich je podpora nespustitelných stránek na architektuře x86.

Na rozdíl od některých jiných architektur však x86 neumožňuje přímo označit stránku za nespustitelnou (přítomen je pouze 1 bit v tabulce stránek specifikující, zdá je možno na danou stránku zapisovat). PaX tedy implementuje nespustitelné stránky dvěma způsoby – první využívá rozdělení virtuálního adresního prostoru na tzv. segmenty. Deskriptory segmentů umožňují striktní nastavení, zda je daný segment spustitelný, čitelný či zapisovatelný (ovšem není možno nastavit všechny možné kombinace, ale podrobnější popis je již mimo rámec tohoto článku). Segmentování je nedílnou součástí správy paměti v chráněném módu architektury x86, ale většinou není příliš často využíváno v plné míře (vytvářejí se segmenty, které pokrývají celý virtuální adresní prostor).

Nevýhodou tohoto způsobu implementace u PaX je omezení velikosti adresního prostoru aplikace na 1,5 GB z původních 3 GB (na x86 je sice velikost virtuálního prostoru 4 GB, ale standardně je poslední 1 GB rezervován pro jádro a aplikace mají k dispozici tedy jen 3 GB). Další, avšak poměrně malou nevýhodou, je omezená možnost modifikace LDT (lokalní tabulka deskriptorů) aplikacemi (není dovoleno vytvořit v LDT kódový segment). Naopak výhodou je velmi nízký (nebo téměř nulový) dopad na výkon.

Kromě toho nabízí PaX i další řešení tohoto problému, který nevyužívá segmentování, ale faktu, že dnešní CPU mají dvě TLB jednotky – jednu pro data a druhou pro instrukce. TLB (translation lookaside buffer) je cache, do níž procesor ukládá výsledky překladu adres při stránkování, aby nemusel při každém přístupu k paměti procházet obsah stránkovacích struktur. Oddělené TLB jednotky nalezneme na procesorech Intel Pentium a vyšších, u AMD je situace horší, jelikož tato možnost je na nich použitelná až od Athlonů/Duronů.

PaX u všech stránek takto chráněné aplikace, které mají být nespustitelné, nastaví tzv. supervisor bit, což způsobí, že při přístupu na tuto stránku z kódu s CPL 3 (Current Privillege Level, IA32 architektura definuje 4 úrovně kódu, první 3 jsou vyhrazeny pro jádro; nejnižší CPL 3 mají uživatelské aplikace) dojde k vyvolání page fault výjimky procesorem. V ní se provede klasifikace, zda se jedná o pokus o provedení instrukce (adresa instrukce, která způsobila výjimku, je rovna adrese přistupované paměti) či obyčejný datový přístup, a samozřejmě v případě pokusu o spuštění kódu aplikaci ukončí. V opačném případě pouze PaX dočasně odstraní supervisor bit a procesor si následně uloží tyto hodnoty do datové TLB (proto je důležité mít oddělené TLB, protože pokus o vykonání kódu by znovu vyvolal výjimku bez ohledu na to, že v datové TLB je stránka cachována jako přístupná). Při přístupu z kódu jádra nedochází k těmto kontrolám, protože jádro má CPL nižší než 3 a tudíž procesor nevyvolává page fault výjimku u stránek s nastaveným supervisor bitem.

Výhodou tohoto přístupu oproti segmentování je nezmenšování paměťového prostoru, jež má aplikace k dispozici. Naopak mezi jeho nevýhody patří nutnost oddělených TLB a určité zpomalení dané častějším vyvoláváním page fault výjimek.

Na druhou stranu je nutno zdůraznit, že obě tyto techniky mohou způsobit nekompatibilitu s existujícími aplikacemi jako např. wine. Na druhou stranu se jedná především o aplikace, jež nejsou až tak často používané na serverech (pro které je PaX především určen), a v případě potřeby je též možno tyto mechanismy pro určité aplikace vypnout pomocí utility chpax.

Závěr

Pomocí těchto systémů se tedy nabízí cesta k velmi bezpečně nakonfigurovanému systému, protože při správné konfiguraci bude mít každý program/uživatel jen velmi omezenou paletu možností a kompromitace jednoho programu zákonitě neznamená kompromitaci celého systému i přesto, že program vyžaduje některá speciální privilegia. Příště dokončíme povídání o možnostech grsecurity a některých vlastnostech PaX (zejména randomizaci adresního prostoru) a podíváme se i na praktickou část, tedy jak grsecurity nakonfigurovat a využít k zabezpečení serveru.

Další části seriálu:

Autor: Pavel Palát, 07. 05. 2004, 00:00
Sekce Bezpečnost, Komentářů: 5
Průměrné hodnocení: 0,15

o Poslat e-mailem
o Tisk článku
o Uložit do profilu


 Přispějte nám




Líbil se Vám tento článek? Můžete ho ocenit zavoláním na tel. číslo 906 460 134.
Cena hovoru za 1 minutu je 46 Kč.





 Hodnocení článku




Článek hodnotím jako:  [1] výborný   [2] dobrý   [3] průměr   [4] špatný   [5] hrůza  





 Komentáře




--

Pavel Palát, 08. 05. 2004 17:18
re












--

plysh, 08. 05. 2004 10:11
PAX a Java












--

Pavel Palát, 07. 05. 2004 12:59
re












--

glum, 07. 05. 2004 11:02
zajimalo by me jak na slozitou administraci prav












--

theo, 07. 05. 2004 09:30
no jo...















PŘIDAT KOMENTÁŘ ZOBRAZ VŠE >>










2002 © Impossible, s.r.o.   >> Kontaktujte redakci >> Právní upozornění >> Reklama