Názory k článku LIDS - Linuxový systém odhalení průniku 2
-
Ivan Daler (neregistrovaný)
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. -
Honza (neregistrovaný)
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. -
theo (neregistrovaný)
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. -
fru_fru (neregistrovaný)
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. -
anonymní
porad se mi nejak nedostava casu a odhodlani soucasne, tak abych si procet, jak je to vlastne napsany, takze prosim o to, aby ste me opravili, pokud se nekde krute seknu
I
docela dost linuxovych stroju je na x86, takze kam az mi pamet saha, tak linux a moduly bezi v ring 0 a uzivatelsky procesy v ring 3.
II
zpristupneni systemovych volani v userspace (1. rozhranni k jadru) by asi mohly byt realizovany pomoci deskriptoru brany v ldt/gdt toho ktereho procesu (brana s pravy ring 3 ukazujici na ring 0 deskriptor spustitelne stranky:offsetu).
III
2. vrstva k rozhranni jadra by asi byly kanaly(vsechny typy souboru) v podobe souboru proc, netlinku, atd. ktery ovsem k vytvoreni a fungovani potrebuji spolupraci jadra.
IV
neni mi moc jasny, na kolika mistech, jak a jestli se vubec pouziva sdilena pamet jadra a userspace, ale jestli jo, tak je to 1.5-ta vrstva?
V
proces-proces je asi prace ipc syscallu a kanalu podonych 2. vrstve k jadru
VI
no a neopravnene ziskavani je asi bud pres syscally donutit jadro aby udelalo nejakou blbost nebo pres zpracovani kanalu proces-jadro nebo proces-proces donutit druhy konec s vetsimi pravy udelat nejakou blbost.
VII
no a ted by me zajimalo co vlastne v tomdle scenari dela lids a co rsbac a co skutecne medusa? kam se kdo povesi o co jsou schopny ohlidat.
VIII
medusa hadam vlozi svuj kod misto puvodnich syscall-u a ty degraduje na obycejne interni funkce, ktere zavola jen v pripade, ze tomu nastaveni odpovida, tedy brany z ring 3 do ring 0 ukazuji na volani implementovane medusou a dovoli tak naprogramovat si libovolne restrikce, pokud se s tim nekomu chce parat - i kdyz uplne nejradi bych asi v nekterych situacich videl vymazani brany k spustitelnemu ofsetu v ring 0 z ldt a nechat proces bez milosti a moznosti pokracovat padnout(kdo vi jestli to meduza dela?)
IX
a dalsi co me zajima, jestli je nektery z techto patchu schopen pracovat s otevrenyma kanalama(vsechny typy souboru, pripadne i to co bude asi technicky nemozne - sdilenou pameti) a detekci stavu budoucich chyb pri zpracovani obsahu techto kanalu. podle toho co jesm slysel o lids by to mohl byt ten pravy bastl, ktery se tim pro konkretni zname pripady snad okrajove zabyva - trefil jsem se aspon priblizne? (+ asciarmor + stackguard a bylo by vystarany?) -
hkmaly (neregistrovaný)
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. -
Axatix (neregistrovaný)
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?
ČLÁNKY DO MAILU