Názory k článku
LIDS - Linuxový systém odhalení průniku 2

-16:CAP_SYS_MODULE
-17:CAP_SYS_RAWIO
-18:CAP_SYS_CHROOT
+22:CAP_SYS_BOOT

Cisla udavaji poradi techto globalnich ACL schopnosti v konfiguracnim souboru /etc/lids.cap.
Nehraji jinou roli, proto jsem se o nich nezminoval.

tak jsem mluvil s jednim skalnik linuxakem a on tvrdi, ze lids je neskutecnej bastl a ze jedine Medusa (http://medusa.fornax.sk/)...

Muze mi k tomu nekdo, kdo do toho vidi, neco rict? Je to pravda?

Ja jsem zase mluvil s jednim skutecnym hackerem a on tvrdi ze linux je bastl a jedine *BSD ;-)

Muze mi k tomu nekdo, kdo do toho vidi, neco rict? Je to pravda? ;-))

PS: Not flame, please ;-)

No, kazdy ma nejake nabozenstvi! Jinak je pravda, ze *BSD jadra jsou o dost cistci nez linuxova, jenze toho umi tak 1/10.

Ja se napr. uz dlouho odhodlavam k tomu, ze nekam BSD nasadim. Jenze to pro me znamena praci navic, vsude totiz Linux nahradit nemuzu.

Nesmite dat prilis na subjektivni dojmy. Nejextremnejsi nazory maji lide, kteri nejsou v obraze a navic kazda liska chvali svuj ohon.

Za vice objektivni kriterium lze povazovat ten fakt, ze na http://www.insecure.org/tools.html v
Top 75 Security Tools pro Linux o Meduse ani dalsich podobne zamerenych softwarovych zaplatach linuxoveho jadra neni ani zminka. LIDS je uveden i mezi 50 Top Security Tools.
Myslite, ze by tam uvadeli bastl?

Podivejte se rovnez na prispevky k prvnimu clanku, vcetne informace o Meduse.

diky.. jsem do minuleho dilu ke sve smule nejak nekoukl. myslim, ze mam ted spoustu nametu na premysleni (a pokusy :)

Rozdil mezi LIDSem a Medusou je hlavne v komplexnosti. LIDS je opravdu bast, coz neni nutne pomluva - je hodne jednoduchy a upravuje docela malo veci v kernelu, zato ale zpusobem, ve kterem se tezko hleda system.

Medusa oproti tomu je obrovsky moloch, ktery ma dost komplexni navrh a spoustu funkci. Normalnimu smrtelnikovi vetsinou staci LIDS. Za zlaty stred mezi jednoduchosti a moznostmi povazuju grsecurity.

tak tak. grsecurity se da v pohode konfigurovat (btw: zkousel jsem si ted hrat i s lids -- ono to nema zadnou konfiguraci primo v jadre? heh :) a az na par detailu umi v podstate totez co lids (teda aspon na kolik jsem to srovnaval) a obcas i neco navic. je zvlastni, ze o grsecu tady jeste nikdo nic nenapsal.

jedine s cim odobne systemy maji problemy je, ze kdyz jadro opatchujete vice ruznymi vecmi (jako treba 2.4kove jadra cryptoapi), tak se to tezko snasi a musi se potom rucne upravovat makefile a podobne, coz je dost otravne.

ale napsal.. sd na hysterce :) (jeden z prielomu...)

mluvil jsem o tom, ze o grsecu nikdo nic nenapsal TADY (tj. na root.cz). samozrejme ze sd psal neco v prielomu (o grsecu vim od nej :).

ano, kazdy mame nejake nabozenstvi to je asi O.K. dokud se kvuli tomu nezacnem vrazdit ;-)

rekl bych, ze hlavni rozdil mezi LIDS a Medusou je v tom, ze medusa poskytuje hodne obecny framework, nad kterym se da implementovat takrka libovolna bezpecnostni politika.

vidim to tak, ze pokud budu chtit prinutit medusu, aby se chovala uplne stejne jako LIDS, tak se mi to povede, bude to stat nejake to usili, ale myslim, ze je to resitelne. obavam se, ze obracene (t.j. LIDS jako Medusa) to asi fungovat nebude. medusa ma proste obecnejsi pohled na vec.

hlavni nevyhodou tohoto obecnejsiho pristupu je to, ze medusa je pracnejsi na konfiguraci, nez zde zminovany LIDS nebo grSec. take myslim mohu rici, ze valna cast adminu ani nepouzije vsechny featury, ktere medusa nabizi. valna cast adminu sec patche nepouziva vubec.

medusu bych doporucil kazdemu, kdo ma chut a moznost si vyzkouset postavit nejaky ten honeypot. myslim si, ze na tyhle srandicky je uplne idealni.

osobne pokud bych spravoval nejake servery asi bych taky dneska sahnul po nejakem grSecurity, staci to bohate na to, aby to zastavilo script kiddies. a nestoji to tolik casu a usili to nakonfigurovat jako medusu.

pokud nekdo chce slyset skutecna a fundovana porovnani mezi medusou a ostatnimi RBASC, tak at si stahne ze strahova (sh.cvut.cz) videa z OpenWeekendu II. probehla tam solidni disputace na toto tema.

posledni nedostatek medusy je ten, ktery pouze obcas jevi znamky zivota. je to skoda, ale kdo vi... jeji cas treba teprve prijde.

II Kdepak, pro syscall se pouziva interrupt, konkretne 0x80.
III /proc, /dev a podobne nejsou nic jineho nez
dohoda o tom jak do syscallu read/write vrazit funkcnost navic.
IV Myslim ze pouze ve funkcich copy_from_user a copy_to_user ... kazdopadne VZDY je to ze strany kernelu
V proces-proces je mozne realizovat tunou zpusobu. IPC, pojmenovane sockety, fork, ... vite ze pres socket jde poslat file descriptor ?
VI Nejcasteji jde o kanaly proces-proces, presneji fork.
VII Predpokladam ze prepisuji syscally.
VIII Neni to presne, obvykle se nahrazuji funkce, tj syscall zavola to same misto, ktere po par detailech v assembleru skoci na funkci z tabulky. A tuto tabulku lids/meduza meni, alespon to predpokladam.
Vis ze exit je syscall ? Nejak jsem nepochopil co dosahnes odpojenim procesu od kernelu. Co ho misto toho ukoncit ?
IX Jak jsem rikal, sdilena pamet se pouziva pouze ze strany kernelu a vsechny soubory jedou pres syscally. Tedy no problem, pokud jsem pochopil.

Mohl by mně někdo vysvětlit k čemu je dobrý přepínač -i. Viz níže. Děkuji
$LIDSBIN -A -s /usr/bin/perl -o /var/spool/postfix.in/deferred -j WRITE -i 4

Vyznam prepinace -i je vysvetlen v clanku LIDS III.

mam system debian a v nom kernel 2,4,26 s lids, a pri READONLY na passwd a shadow, pre login su, mi login vypisuje chybu ze subor je iba na citanie a odmieta ma prihlasit, uz ste sa stym niekto stretol? okrem toho mam pre fsck.ext2 nastavene CAP_SYS_RAWIO -j GRANT, ale pri boote roby aj tak problemy,,, vsimol som si ze je to nastavene v lids.conf, ako to dostanem do lids.boot.conf, okrem prekopirovania existuje na to nejaky parameter, a je to nutne do toho dat?