FUD vagy igazság? A Linux nem biztonságos

Tipikus SCO2 a cég. Szépen kezdi elveszteni a piacait, és ahelyett, hogy használná a Linux-ot (lásd IBM), inkább úgy döntött, hogy ő az erösebb (lásd SCO).

;-)))

Pá pá zöld hegyek...

Szerintem következő azlesz hogy amig

linux # ISINTEGRITY-178B vagy linux nem "ISO INTEGRITY-178B" :) addig nem elég biztonságos...

Ja2: Egy rendszer nem attól biztonságos, hogy megfelel egy minősítésnek. A minősítésnek való megfelelés _bizonyítja_, hogy biztonságos!

A jelenleg érvényes viztonsági skálák zárt fejlesztésekre lettek kitalálva. Emiatt egy nyilt modellell dolgozó program alapvetően hátrányos helyzetből indul.

A megoldás az lesz/lenne, ha a _valódi_ biztonsági igényeket ujra összeírnák a katonai számítástechnikusok, és ujragondolnák, hogy ezeknek az igényeknek milyen metodikájú biztonsági teszt tudja ezt _garantálni_ úgy, hogy a nem indulnak (nagyon) hátrányos helyzetből a nyilt rendszerek.

Szerintem a lenyeg az, hogy a hadiipar evi tobb szaz milliard dollaros uzlet... Ebbol kovetkezik, hogy ennyi penzert en is ezt mondanam :)

Mondanál te bármit, ha azt hinnéd használ;-)

Mint ahogy én is.;-)

A kritikus rendszerek valoban mas vilag, ezeknek kulonbozo helyeken kulonbozo kovetelmenyeknek kell megfelni. De ez

nem feltetlen a 'DO-178B Level A' certifikacio.

Van olyan is, hogy: IEC 61508

handler

Aki nem tudja, hogy mikor kell csendben maradni, az sok pénztől esik el.

Ha mar EALx, akkor legyen teljes a kep:

"EAL7 rating doesn't require review of

the code, only a review of the architecture"

http://www.eros-os.org/pipermail/e-lang/2002-November/007768.html

Van néhány téveszme a cikkben.

Szerintem:

Geen Hill mondja:

>a titkosság az egyik alapja a biztonságnak,

Nem a biztonság alapja, hanem a hamis biztonságé. (mivel ninics semmi ellene szóló adat, azt hiszed, hogy nincsenek is ellene szóló adatok, pedig vannak, csak te nem tudod őket)

>a ``sok szem biztonság'' téveszme,

A kevés szem= biztonság akkor micsoda?

Semmi sem akadályozza meg a katonai beszállítókat, vagy a DoD-ot (US hadügymin.), hogy ráállítsa ugyanazokat a biztonsági szakértőket, és ugyanannyi ideig vizsgálgasság, mint a zárt rendszerekkel tennék.

>Security through Obscurity

Ez _kízárólag_ addig müködik, amíg az ellenfél fel nem fejti. Utána közel annyira belelát a dolgokba, mint az egyik fél. Mivel a rendszer zárt, és nagytekintélyü embereknek elhitték, hogy nem törhető fel, _és_ akkor már _senki_ sem vizsálja, a feltört rendszer átjáróház lesz. Ráadásul ezt még észrevenni is nehéz. A titkosításban is akkor jött áttörés, amikor meg lettek alkotva a nyilt kulcsu titkositasok.

Gondolom az EAL-ok azért lettek megalkotva, hogy akkor is lehessen valamit mondani a biztonsági szintről, ha nem lehet belenézni a kódba. Nem lenne egyszerübb a kód alapján eldönteni valaminek a biztonsági szintjét?

Majd jönnek az isec-es lengyel srácok, és találnak néhány 100 hibát a zöld hegyekben.;-)

Hogy is volt az, hogy egy hadihajon befagyott a windows, es be kellett vontatni a kikotobe, mert sajat erobol nem mozdult?

Az vajon megfelelt a kovetelmenyeknek?

Egyebkent siman el tudom kepzelni, hogy az o termekuk jobb, gyorsabb, biztonsagosabb. Miert ne lehetne egy specializalt cucc jobb az adott feladatra, mint egy altalanos? Es az is ertheto, hogy ezt szeretne mindenkivel tudatni, hiszen ez hozza neki a penzt.

G

>termekuk jobb, gyorsabb, biztonsagosabb

Ez így ellentmondás.;-) Vagy gyorsabb, vagy biztonságosabb.

"Tökéletesen biztonságos rendszer nincs, de minden rendszer biztonsága növelhető a teljes használhatatlanságig"

Az igazság nem azon múlik ki mered-e mondani vagy sem.

Nem fogok azért mást mondani, mint amit gondolok, még ha emiatt pénztől esek el:

Reggelente a borotválkozáshoz tükörbe kell nézni...

Gabriel

Hát nem is tudom.

Tudtommal az ürsiklókon is Debian fut. Oda elég jó, ide nem? (Még egyiknek sem lett baja szoftverhiba miatt.)

Másrészt azt megértem, hogy az F-16-osokra nem nyomnak linuxot, mert gáz lenne kiadni a forrást (gondolom a GPL miatt akkor is ki kellene:), de azért rendes szerverekre, PC-kre miért ne? A NASA is rengeteget használ, pedig ott sem publikus minden.

Nekem úgy tünik, hogy az ürge sorra sorolja azokat a "tényeket" amiket a Kevin Mitnick a könyvében sorra megcáfolt annak idején.

Na meg beette azt a sz@rt amit a minöségbiztosítási hazudozók nálunk is terjesztenek az ISO-9001 kapcsán. Mióta lesz valami biztonságosabb attól, hogy papír van róla. Inkább: ha biztosnágos, lehet róla papírt adni. Ezek vajon miért keverik rendre az okot és az okozatot?

Üdv.: Tamaas

A security by obscurity nem egy hulyeseg a katonaknal, nem vilagpiac ergo az ide szolo fejleszteseket nem vizualjak annyian mint amennyien egy altalanos celu fejlesztest, emellet aki nezi ezen szoftverek forrasat: a, fejleszti b., meg kivanja kerulni

Egy ilyen kornyezetben is figyelembe kellene venni azonban hogy az emberek gyarloak. Nem szivesen lennek a *****i helyeben mikor egyik alkalmazott kilep es megszallja a pacifizmus.

>forrást (gondolom a GPL miatt akkor is ki kellene:)

Ha a hadügy a copyright holder akkor nem. A GPL a továbbadásra mond feltételeket, ha nincs továbbadás, akkor azt csinálsz (saját használatra), amit akarsz.

Nézd meg a google-t. Alig adott ki valamit, de alkalmaz kernel hackereket is. Kérdem miért?;-))

Kódszinten agyontunniingolt rendszereket használ...

Nem azt mondtam, hogy hazudni kell. Nem kell hazudni.

Tudni kell mikor nem kell megszólalni...

Le tudna nekem foritani valaki ezt a reszt a cikkbol? Nem igazan ertem hogy mire gondol az illeto...

"If secrecy isn’t important to security, then why does Linus Torvalds keep the means of accessing the core Linux development tree a secret from all but a few people? Because if he published the details of his defenses, some jerk would break in and screw up the Linux development effort. Doesn’t the military have more important things to protect than the Linux development tree? Don’t they have people who want to attack them as well? Maybe they need a little secrecy, too."

Gondolom az EAL-ok azért lettek megalkotva, hogy akkor is lehessen valamit mondani a biztonsági szintről, ha nem lehet belenézni a kódba.

Olvasd el a HupWiki Common Criteria bejegyzese [www.hup.hu]t.

Tudtommal az ürsiklókon is Debian fut.

Nem. Csak volt olyan utja, amin felvittek Debiant futtato hardvert is.

Nagyjából (inkább értelem, mint szó szerint):

"Ha a titkosság nem fontos a biztonsághoz, akor vajon Linus miért korlátozza a hozzáférést a Linux fejlesztői fájához. Ha puplikálná a védelem módját, akkor néhány balfácán megtörné, és összezavarná a fejlesztést. Nem a legfontosabb feladat védeni a Linux fejlesztői fáját? Nincsenek emberek, akik meg akarják támadni? Nekik van szükségük kisebb biztonságra."

Az ürge ott téved, hogy keveri a read access, és a write access fogalmát.;-)

En nem szeretnem hogy emberek megolesehez felhasznaljak a nyilt forraskodokat, de lehet hogy en vagyok tulsagosan erzekeny :)

Szvsz itt két szálra kellene bontani a dolgokat.

1/ Alkalmas-e a Linux realtime F-16 (stb) irányításra, ill. jobb-e erre a célra a Integrity-xxx?

Erre a válasz valószínüleg az, hogy az Integrity a jobb erre a célra, erre fejlesztették ki, sok milliárd dollárért (gondolom én) Na de ki mondta, hogy a Linux egy RT harci program? Ilyen erövel írni lehetne n db cikket, hogy jobb-e a linux szervernek, mint az Integrity? Vagy multimedia platformnak?

2/ Az írás formája és tartalma PR+FUD. Mivel a Linux-bashing biztosan bekerül a mediába, így aki eddig nem hallott a cégröl, most majd fog (és elolvassa a minden második mondatban lévö "bezzeg az Integrity..." részeket)

Sokmindent ír O’Dowd, és sokminden elhangzott a hozászólások között. Azért van néhány dolog, néhány urbánus legenda és tévhit, ami úgy látom mélyen gyökerezik a HUP olvasótáborában:

1. Annak, hogy EAL7 vagy EAL2 önmagában nem sok értelme van. A Common Criteria az EAL szinteket a kiválasztott protection profile-ra alkalmazza. Vannak előre elkészített, "népszerű" protection profile-ok (például a Controlled Access Protection Profile - CAPP - vagy a Labeled Security Protection Profile - LSPP -), de bárki, aki minősíttetni szeretne, kidolgozhat egy saját PP-t is. Az EAL szint a PP-nek való megfelelőség mélységét vizsgálja. Ha csak az EAL szintet adja meg valaki, az olyan, mintha egy emberről annyit mondanának, hogy "egyetemet végzett", de azt nem, hogy bölcsészkaron vagy elméleti matematikusként kapott diplomát. Hozzátenném (bár erről nincs szó a cikkben), hogy a Linuxot jelen állapotában maximum CC CAPP EAL4-es szintig van elméleti lehetőség minősíteni, az INTEGRITY-178B pedig TCSEC A1-es minősítést kapott, ami CC LSPP EAL6 vagy EAL7-nek felel meg. Az LSPP és a CAPP köszönő viszonyban sincs egymással, sajnos az LSPP lényegesen erősebb biztonsági profil.

2. Az EAL4-es az utolsó szint, ahol nincs forráskód elemzés. Efölött vagy fél-formális, vagy formális matematikai forráskód elemzés szükséges legalább a privilegizált szinten futó részekhez. Ez nagyon drága és nagyon lassú, mert jelenleg (tudomásom szerint) nem lehet automatizálni, matematikusokkal kell elvégeztetni. A cikkben leírt 1000$/sor teljesen reális.

3. Attól, hogy valaminek papírja van, még nem lesz biztonságosabb, valóban. Attól lesz biztonságosabb, hogy ahhoz, hogy ezt a papírt megkapja, minden változtatást formálisan, matematikailag bizonyítani kell. Innentől fogva a kód kritikus részei hibátlanok. (Gondoljatok egy olyan rendszerre, ahol elvi lehetőség sincs local root vag remote root exploitra. Jelentkezzen, aki szerint a Linux ilyen.)

4. A Linux jelenlegi fejlődési ütemét és a "célközönségét" tekintve esély sincs "komoly" CC minősítés megszerzésére. De fontos megjegyezni, hogy a kifejezetten biztonsági szempontokat szem előtt tartó általáos célú operációs rendszereket sem szokták LSPP EAL4-nél szigorúbban minősíteni. Pl. a Trusted Solaris is "csak" LSPP EAL4.

Összefoglalva: a cikkekben szerintem rengeteg olyan igazság van, amit itt a fórumban emberek ész nélkül támadtak. Valószínüleg az INTEGRITY-178B lényegesen biztonságosabb, mint a Linux, és atomfegyvereket vagy repülőgépeket lehet rábízni. Ami miatt mégis csúsztatás az egész, az az, hogy nem almát almával hasonlít össze. A Linux általános célú operációs rendszer, az INTEGRITY-178B nem. Az összehasonlítás akkor lenne igazságos, ha ugyan azok lennének az elvárások. Térjünk erre a biztonságosabb - nem biztonságosabb dologra vissza akkor, amikor az OpenOffice.org-ot tudom futtatni INTEGRITY-178B alatt is.

Igen, én sem. Persze, a hős Integrity védi a katonák életét, akik egész véletlenül kerültek egy másik országba.

Vajon az Integrity hány felhasználós, milyen szervereket tud futtatni? Az az érzésem, hogy a kutya lett a lóval összehasonlítva. Melyik őrzi jobban a házat?

Miert, mi iranyitja az F-16-ot? Integrity-xxx?

Akkor itt egy kis csemege:



F16 autopilot flipped plane upside down whenever it crossed the equator



Idezet innen: http://www.qucis.queensu.ca/Software-Engineering/archive/horror [www.qucis.queensu.ca]

De vannak itt mas nyalanksagok is:

http://www5.in.tum.de/~huckle/bugse.html [www5.in.tum.de]

Nem olvastam vegig a listakat, biztos lehet talalni nyilt forrasu peldakat is.

De ha a zart forras sem tokeletes, akkor minek fikazni a nyiltat?

Nem FUD. Ez a tiszta igazság. A DARPA is az OpenBSD -t valasztotta nem pedig a linuxot. (nem veletlenul)

Ezen nicsit mit veszekedni a linux kernel nem biztonságos.

Boo hoo

Tudod az regen rossz, ha egy biztonsagos rendszer fejlesztesere adott penzt az adott fejleszto egy bizonyos esetrol alkotott velemenye befojasolja. Ez nyilvan sokat elarul a prioritasokrol.

Masreszt meg az OpenBSD joreszt a TdR miatt olyan amilyen, ezert toleraljak neki a viselkedeset azok, akik ezt atlatjak.

Olvasd el az eredeti cikkeket is. Egy s/Linux/OpenBSD/g után minden állítás, ami eddig igaz volt, továbbra is az. Nincs minősítve, nincs bizonyítva, hozzáférhető a forráskódja, stb. Lehet, hogy inkább a licensze miatt választotta a DARPA...

Eleg nagyot tevedsz. Nem fogom elolvasni a cikket, mert

1) A velemenyem megvaltoztathatatlan

2) Annyira nem erdekel a linux, hogy else tudod kepzelni

"Open Source Doesn’t Makes Linux More Secure than Windows"

Ez nem is igaz linux es windows eseteben. De OpenBSD re ezt nemigazan tudjak rahuzni. www.openbsd.org eleg jo olvasnivalo lenne szamodra.

*********

The Common Criteria Says Linux Security Problems Can’t be Fixed

Ez is nagyjabol igaz, mivel a linux kernelben nagyon sok a ganyolas illetve akkora kodtomegrol van szo hogy szinte lehetetlen lenne fixelni. Es ami mar alapbol el van ganyolva es arra epulnek a cuccok, mar el van veszve. Ezt openbsd re szinten nem tudod rahuzni, mivel itt a "security mindenek elott" jelszo ervenyes. Addig nem kerul be semmi a treebe amig 100% ig nem tuti es nem lett leokzva. Hidd el nekem. OpenBSD forrasba nemigen fogsz ganyolast talalni.

********************

NSA Security Enhanced Linux (SELinux) is not the Solution

Ez eppen, hogy szegyen mivel minden ***** szemet kell ahhoz, hogy biztonsagos?? legyen a linux kerneled. grsec isten*****a meg mittudomen meg mi. Tiszta nevetseges. OpenBSD-re ezt sem tudod rahuzni.

**********************

Es itt mar meguntam a cikk olvasasat. Van jobb dolgom is.

Boo hoo

Egyik reszet sem lattam.

moo (ez mar jobb? :))

>Tudod az regen rossz, ha egy biztonsagos rendszer fejlesztesere adott penzt az adott

A biztonság, és a megbíhatóség politikusi fejekben nagyon közel áll egymáshoz. TdH IT szakember, nem politikai elemző. OK, hogy van véleménye, OK, hogy elmondja. Nade a trabulinról...

Ha ennyire nem érdekel a Linux, akkor miért fikázod tiszta erőből, ahogy és amikor csak bírod? :DD

Mert nem birom szo nelkul hagyni.

az OpenBSD hivok mind mokas emberek ;-). ha 100% tuti kod kerul csak be, akkor mi magyarazza a kulonbozo security meg reliability bejegyzeseket itt: http://openbsd.org./plus35.html ?

002: SECURITY FIX: May 5, 2004 -> Pathname validation problems have been found in cvs(1)

---

IMHO ez nem teljesen OpenBSD eredeti software.

RELIABILITY != SECURITY

viszont a linux kernelben havi rendszeresseggel van 1 local root.

Ha OpenBSD fanatikus lennél, fel sem tennéd ezt a kérdést. Természetesen az összes hiba még azelőtt került bele az OpenBSD forráskódjába, mielőtt OpenBSD lett, így az nem az OpenBSD fejlesztők hibája, ők csak javítják azokat.

Új kódban is találtál hibát? Kizárt, különben is, bizonyítsd be, hogy remote rootot tudsz vele szerezni. :)

akkor ezek mik:

SECURITY FIX: A reference-counting bug exists in the shmat(2) system call that could be used by an attacker to write to kernel memory under certain circumstances.

SECURITY FIX: An IPv6 MTU handling problem exists that could be used by an attacker to cause a denial of service attack against hosts with reachable IPv6 TCP ports

SECURITY FIX: Several message handling flaws in isakmpd(8) have been reported by Thomas Walpuski. These allow an attacker to delete arbitrary SAs.

SECURITY FIX: It is possible for a local user to cause a system panic by flooding it with spoofed ARP requests

RELIABILITY FIX: OpenBSD's TCP/IP stack did not impose limits on how many out-of-order TCP segments are queued in the system. An attacker could send out-of-order TCP segments and trick the system into using all available memory buffers.

RELIABILITY FIX: An improper bounds check makes it possible for a local user to cause a crash by passing the semctl(2) and semop(2) functions certain arguments.

RELIABILITY FIX: It is possible for a local user to cause a crash via sysctl(3) with certain arguments.

es a tobbi, van itt minden ami szem-szajnak ingere.

aszondod, hogy a linuxban havonta van local root - linux mint kernel? mert akkor az ugye csak az elmult egy evben 12-t jelente...mik lennenek ezek? szerintem csak ossze-vissza beszelsz ;-)

Es ebbol hany nyujt lehetoseget arra hogy emeld a privilegiumaid?

Ket dolog van. Az egyik az hogy meg senkit nem koteleztek arra hogy linuxot hasznaljon. Linuxot csakis az hasznal aki akar es csakis sajat felelossegere. A fizetos szoftverekkel is pontosan ugyanezt teszi az ember csak kozben kiraboljak ...

A masik dolog meg szerintem az hogy ez a hir egyaltalan nem idevalo. Ez az egesz egy rossz reklamkampanynak esetleg elmegy mert ugye igy lehet egy kis ingyenes reklamot szerezni egy cegnek ... lasd SCO es tarsai ...

Ja es meg egy dolog ... ki kerdezte ezt az embert ? Ki kerte fel hogy nyilatkozzon ??? Es miert ???

Mi tartott ilyen sokaig? Mar azt hittem valami baj van, hogy OpenBSD-rol van szo, es sehol egy PaX-os beszolas.

netchan

Rögtön az első?

Jók az ilyen vélemények (havi rendszerességgel van 1 local root).

Az, hogy egy szoftverben hány hibát találnak milyen rendszerességgel nem biztos, hogy összefüggésben van azzal, hogy valójában mennyi hiba van benne. Lásd a múltkori elmélkedést, amelyik hasonló alapról indulva oda jutott, hogy a Windows 95 a legbiztonságosabb OS, mert abban régóta nem találtak komoly hibát. (hogy a Windows for Workgroupsról ne is beszéljünk)

A kezdeti nagy fellángolás után egyre kevesebben használnak OpenSSH-t, mert az általános vélemény, hogy az ssh.com féle jobb. Konkrét adatokat nem tudok, de én legalábbis kevesebb hibáról hallottam az elmúlt három évben ssh.com, mint OpenSSH tekintetben.

Ha azt vesszük alapul, hogy a Linux kernel és az OpenSSH között a kód méretét tekintve milyen viszony van, és hány hiba került napvilágra a két oldalon, akkor azt hiszem a Linux kernel nyert.

Sajnos, mert míg a kernelben lévő hibákkal általában ritkán lehet távolról bejutni egy gépre, addig az OpenSSH erre kiválóan alkalmas. :((

-)))

----------

thuglife

Ez eppen, hogy szegyen mivel minden ***** szemet kell ahhoz, hogy biztonsagos?? legyen a linux kerneled. grsec isten*****a meg mittudomen meg mi. Tiszta nevetseges. OpenBSD-re ezt sem tudod rahuzni.

Miért fáj az neked, hogy valaki kiad a tiszta linux kernelforrásfában pl.

egy patch -p1 -E parancsot? ;-)))

Szeretem, mikor olyanok beszélnek a biztonságról, akik az alapfogalmakkal nincsenek tisztában.

"The Common Criteria Says Linux Security Problems Can’t be Fixed"

Ez ugye azt jelenti, hogy a Linuxot nem lehet CC LSPP EAL7-re minősíteni. Elárulom, az OpenBSD-t sem lehet. Mert nincs benne Bell-LaPadula modellen alapuló kötelező hozzáférés védelem. Egyébként sorold már fel légyszíves, hogy az OPenBSD milyen biztonsági minősítéseket kapott meg, mert a www.openbsd.org-on egyetlen egyet sem találtam.

"NSA Security Enhanced Linux (SELinux) is not the Solution"

A SeLinux ugye egy kötelező hozzáférés védelmi framework, amit a cikk írója egy kicsit leszól (mert csak technológiai demónak indult, de aztán kinőtte magát). De legalább van, és legalább szabályozható vele az információ áramlás. Ilyennel minden trusted operációs rendszer rendelkezik, de a marha biztonságos OpenBSD-ben nincs. A 2.6-os sorozatú vanilla kernel része, nem kell hozzá patchelni. A grsecurity-t meg csak te emlegetted eddig.

ps: MSDOS. 25 éve nincs remote exploit a default installban.

A grsecurity-t meg csak te emlegetted eddig.

Van valami gond a grsecurityvel?

Az 1.9x-esben is van MAC , a 2.0-sban meg már RBAC van.

Nekem nincs semmi bajom vele, vannak részei, amit használok. De azzal ugye te is tisztában vagy, hogy amit ők MAC-nak meg RBAC-nak hívnak, az valójában nem az?

hint: létrehozol egy fájlt. Be tudsz-e rajta olyan jogosultságot állítani, hogy minden ebből a fájlból származó produktum elérhető legyen "A"-nak, de ne legyen elérhető "B"-nek, még akkor sem, ha "A" oda akarja adni "B"-nek? (A származtatást csinálhatja A is, tehát mondjuk lemásolhatja magának a fájlt). MAC esetén ezt meg lehet oldani.

minden ebből a fájlból származó produktum elérhető legyen "A"-nak, de ne legyen elérhető "B"-nek

hú ezt most konkretizáljuk példára, mer' így elméletileg most nem tiszta éjjel negyed 2kor...-)

(jesszusom holnap(?) izé ma fél nyolctól meló...!)

sz'al mondjuk csinálok oscon userként a home crafty könyvtáramban egy book.sh szkriptet...

ezt, és ennek utódait hogyan tudom odaadni más usernek? -)))

oscon usernek csak a saját könyvtárába van joga írni. amit viszont a többiek meg eleve nem látnak.

grsec patchel (1.9.x) még arra is tudok korlátozni, hogy melyik alkalmazásból legyen látható, írható, egyéb a file.

Tehát mondjuk csak mcedit-el lehessen szerkezteni, és csak kedit-el legyen olvasható, ill. csak sh-val lehessen futtatni. amúgy általában az egész /home meg ne is látszódjon.

Mondjuk konkrétan pluszban a book.sh szkript fájlnak jogában ezt így kétségtelenül nem tudom beállítani grsec-ből/simán, hogy a létrehozó osconnak ne legyen joga módosítani az általa létrehozott fájljogokat.

Tehát mondjuk ha a book.sh egy közös mappában van, akkor a book.sh tulaj, és csoprtjogait a létrehozó tulaj oscon chown, chgrp-vel ugye senkinek nem tudja átadni, viszont az any-t minden további nélkül átteheti rwx-re. ennek meggátolására a grsec 1.9.x önmagában valóban nem elegendő.

gany gany gany

Ok, akkor kicsit konkrétabban.

1. Belép Onson user. Azt mondja, hogy vi /tmp/secret Aztán ha leírta a titkait, beállítja a jogosultságokat.

2. Belép A user, akinek jogosultságot adott Onson . Azt mondja, hogy cp /tmp/secret /home/A. Aztán mond olyat, hogy vi /home/A/secret, majd :w secret2 stb. A végén a kapott fájlt - a származtatott dokumentumot - A user visszamásolja a /tmp-be, mondjuk secret2 néven, és mond egy chmod a+rw /tmp/secret2 -t.

3. Belép B user. Nem tudja elolvasni a /tmp/secret2-t.

Ha ez elképzelhető, mondjuk azért, mert Onson, A és B különböző biztonsági szinten vannak, akkor MAC.

Van rá működő exploitod? Nekem linux kernelre van sok a current kernel előtti verziókra mindd... ;)

Egyébként shmat nem OpenBSD specifikus, hanem az összes BSD-t érintette, de kb. olyan nehéz a kihasználása (főleg OpenBSD alatt), hogy gyakorlatilag local DoS-on kívül másra nem jó.

"és most hol vannak a robotok?

hol van a lebegő autóm?

hol vannak az űrállomások?

hol a teleportáció?

hol van a számítógéppel vezérelt otthonom és a tablettából készülő ebédem?

és ki fog engem meggyógyítani?"

;-))

keverjuk a szezont a fazonnal, mi? ;-) kernel patch != distro. ha valaki grsec-t akar distro formaban, akkor ott a hardened gentoo, egyszerubb installalni mint az OpenBSD-t es persze biztonsagosabb. ha csak a PaX erdekel (meg esetleg RSBAC) akkor meg ott a vhol debian alapu adamantix. szoval ha ertelmes osszehasonlitast akartok, akkor tessek azokat osszemerni, ne 'apples to oranges', ahogy angolszasz videken mondjak.

nem ertem, azon tul, hogy a legelso emlitett local root (vagyis rosszabb, local direkt kernel exploit, lasd meg http://archives.neohapsis.com/archives/bugtraq/2004-02/0141.html), mit szamit? az eredeti allitasod az volt, hogy "Addig nem kerul be semmi a treebe amig 100% ig nem tuti es nem lett leokzva." a fenti lista 100% ellentmond ennek ;-).

szerintem amit leirsz az nem MAC altalaban (ahogy en ismerem, ez csak egy altalanos kategoria mindenfele access controllra), hanem egy specialis fajtaja, amit multi-level security-nek (MLS) hivnak es a grsec-ben ez egyaltalan nem cel (es irgalmatlanul nehez megcsinalni, mert ugye egy komplex OS-ben sokfele rejtett csatornara van lehetoseg, ahol nem megengedett modon aramolhatna informacio).

Irgalmatlanul nehéz: RSBAC-cal és SeLinuxal is egészen jól megoldható. (SeLinuxnál a default szabálybázis helyett kell egy Bell-LaPadula szabálybázis. Nem olyan bonyolult.)

MAC: a DAC és a MAC között pont az a különbség, hogy DAC esetén az adat tulajdonosa döntheti el, hogy mit tesz az adott adattal, míg MAC esetén elsősorban a biztonsági cimkék döntik el, hogy mit tehet az adattal. Ezért (kicsit sarkítva) amit én leírtam az MAC, ami ezt nem tudja, az DAC. Tudom, hogy a grsec-ben ez nincs megoldva, és azt is tudom, hogy nem is cél. Csak arra akartam rávilágítani, hogy a gsrec-ben MAC-nek hívott izé valójában nem MAC.

De ha a MAC-DAC különbségre jobb definíciót tudsz adni, akkor hajrá.

se az RSBAC se a SElinux nem tesz semmit a rejtett csatornak eltunteteseert (es akkor most kernel bugokrol nem is beszelek, ami ugyebar kepes minden ilyen rendszert agyonvagni, lasd Argus Pitbull Challenge 2-3 evvel ezelott). te arra gondolsz, hogy ha a trivialis info szivargast meg lehet akadalyozni, akkor mar meg van oldva a problema - hat sajnos nincs. ez a szituacio kb. ahhoz hasonlit, ahogy az ujabb 2.4/2.6 kernelek 'megoldjak' a noexec mount/ld.so problemat - a trivialis eset tobbe tenyleg nem letezik, de 'semmibe' nem kerul kijatszani annak, aki egy kicsit is tud programozni es tudja, hogyan kell return-to-libc stilusu tamadast szimulalni.

MAC/DAC/grsec: a pontossag kedveert a grsec 1.x-ben 'process based MAC' van, a 2.x-ben pedig 'role based AC', amirol te irsz az meg egy meg masabb fajta, 'labeled security' (magyaran a kulonbseg az 'access control' 'finomsagaban' van, de ettol meg mindegyik 'mandatory' a maga absztrakcios szintjen).

na ezert irtam az elejen, hogy a MAC egy altalanos gyujtofogalom, sokan sokfele dolgot hivtak mar annak (ezt persze lehet jonak ill. rossznak minositeni egyeni izles szerint, ami nekem fontos az az, hogy egy adott megoldas jo-e a valos eletbeli problemamra vagy sem, mindegy minek hivjak).

A MAC fogalmán ne vitatkozzunk, tényleg nincs értelme. Sajnos sok gyártó sokmindent hív annak, ami valójában nem az, csak jól hangzik. Ez amolyan hacker/cracker vita lenne.

A kernel bugog természetesen agyonvághatják a rendszered, lévén segítségükkel megkerülhető a védelem.

A rejtett csatornákban viszont szerintem nincs igazad. Ha két proces:

- nem látja egymást

- nem lehetséges közöttük IPC

- nem láthatják/használhatják ugyan azokat a fájlokat

- nem küldhetnek egymásnak signalokat

akkor a maradék lehetséges covert channel néhány igen-igen kis sávszélességű. lassú, és bonyolult módon kihasználható. A fenti négyes pedig megfelelő policy segítségével elérhető.

1. a grsec melyiket nem kepes a 4 kozul?

2. a problema a rejtett csatornakkal nem az, hogy milyen a savszelesseguk, hanem az, hogy egyaltalan leteznek. a te altalad hasznalt MAC fogalom garantalt informacio elvalasztast jelent (ha jol ertettem legalabbis), ez esetben rejtett csatornanak egyaltalan nem szabad leteznie, se kicsi se nagy savszelesseggel.

na, reszemrol lassan atesunk az offtopic kategoriaba, tovabbi eszreveteleket inkabb emailben vagy a grsec forumon keretik tenni ;-).

Mi a helyzet a cut&paste-tel? Egyszerű, mégsem hinném, hogy meg tudnád fogni.

Az első válasz is csak arra kívánt rámutatni, hogy az OpenBSD-be koránt sem csak olyan kódsorok kerülnek be, amelyek 100%-ig biztonságosak.

Az, hogy ez egy általános BSD hiba volt és az OpenBSD-nél nehezebb kihasználni, egy plusz pont, de csak ettől nem lesz automatikusan a legbiztonságosabb operációs rendszer.

finoman szólva nem túl életszerű példa, de jogos a grse valóban nem tudja gátolni a tulaj megváltozását a /home/*-be másolás során.

na gyere nyomd fel az itthoni cuccomat, ha annyira gánynak találod...;-)

adhacc rosszindulatú webcímet rákattintok, küldhetsz emailben rosszindulatú binárist, megpróbálom elindítani...de valami azt súgja nem fog összejönni. (noexec+TPE)

mondjuk még posix acl-el is erősítve szerintem teljesíti az elvárásaid.

Pedig meg lehet csinálni. RSBAC-cal sikerült megakadályozni modnjuk két xterm között, ha a policy szerint tiltva van.

Nem érted. A tulajdonos megváltozik. Szakadj el a diszkrét hozzáférésvédelmi modellektől.