Názory k článku Jemný úvod do OpenBSD

1) na ceskem mirroru isa nenajdete, je tam link na
ftp://ftp.eunet.cz/pub/os/OpenBSD/iso/
nejsou to originalni iso image, protoze OpenBSD (Theo Raadt) ma patentovanu strukturu souboru na tech originalnich kedesech a neni mozne je zdarma sirit (a asi ani vyrobit vlastni se stejnou strukturou, aniz byste porusili copyright).
Necekejte take, ze balik ktery na takovem neoficialnim image najdete bude mit u sebe i vsechny zavislosti. Vetsinou je obsazena zakladni instalace a zbytek mista je dotlacen baliky z ports. Ale bootuje to a je to rozhodne lepsi nez dratem do oka, takze diky za ne.


2)V clanku mi nejak unikl popis co najdete v zakladni distribuci - je to jen nekolik souboru (obycejne .tgz), ktere se vam do systemu rozbali (pokud nejaky z nich nevyberete staci jej jen rozbalit do rootu)
base31.tgz - system
comp31.tgz - kompilator
etc31.tgz - konfigurace
game31.tgz - hry
man31.tgz - manualove stranky
misc31.tgz - syst. data
xbase31.tgz - zaklad Xwindow (konf., *.h, libs)
xfont31.tgz - fonty
xserv31.tgz - Xserver
xshare31.tgz - textove soub spolecne pro vsechny arch.

zdrojaky najdete v src.tar.gz (vsechno co je v defaultni instalaci) srcsys.tar.gz (openbsd kernel)


2) prijemne na sprave baliku je to, ze prikaz pkg_add sam dela tranzitivni uzaver zavislosti a pokud jsou potrebne baliky v aktualnim adresari, sam je na instaluje. Neprijemne je to, ze pokud vse se neco najde je pekne urvanej, ale kdyz instaluje, tak ani nepipne (v defaultni konfiguraci) coz bych necekal od systemu, ktery ma byt v defaultni konfiguraci bezpecny.

Bohuzel v packages nejsou baliky jako gecko, mozilla, midnight-commander. Posunuji se sice mozna nazory vyvojaru OBSD od "mc je jedna velka bezpecnostni dira" k "mozna ze vam ho jednou i dame zabalenej, jestli najdeme cas", ale to je vsechno. Jeste ze mc se da zkompilovat a beha (az na potize s terminalem) v pohode :)

3) doufal jsem, ze si nektere veci pretahnu z linuxove partition, ale dlouho jsem nemohl tu partition namountovat. Pak jsem ji (/dev/hda5) nasel nekde jako /dev/wd0j nebo /dev/wd0k. BSD partition vubec vypada trochu odlisne :). S ext2fs si uz openbsd hrave poradilo a aj na msdos partisne videlo korektne dlouhe nazvy.

4) Nepovedlo se mi zatim namountovat openbsd partition (ffs) pod linuxem. V dokumentaci sice radi filesystem ufs s volbou "-o ufstype=44bsd" ale stejne mi to porad nejak nefacha. Nevim jestli je mozne partition table typu A6 pouzit pod linuxem ,nebo neco delam spatne.
Nevite nekdo?


5) take jsem nemohl najit ekvivalent linuxoveho /etc/ld.so.conf - seznam adresaru kde jsou sdilene knihovny. Je mozne sice rucne pridat "ldconfig -m /aaa/aa/adresar" ale po rebootu se to vrati zpet.
Ta spravna volba je v souboru /etc/rc.conf (myslim, ze se jmenuje shlib-dir ale z hlavy si nejsem uplne jist)

6) chybi mi modularni konfigurace inicializace ve stylu SystemV, ale nekomu to muze naopak vyhovovat mit vsechno pohromade na jednom miste. Vse co po rebootu nabehne spousti skript /etc/rc a co ma zapnout se rozhoduje podle /etc/rc.conf

Díky za postřehy.

Absence ld.so.conf by se mohla dát obejít nastavením proměnné LD_LIBRARY_PATH.

O tom, zda-li je koncepce skriptů SystemV lepší než BSD by se dalo polemizovat. V každém případě nelze vyčítat OpenBSD, že používá BSD model :-)

LD_LIBRARY_PATH ovsem nefunguje pro set-uid programy (treba ssh, xterm (pokud nepouzivaji utempter), ...).

Co se tyce init-skriptu, tak BSD model je jiste prehlednejsi, ale pokud mate instalovat samostatne baliky ktere se spousti pri startu, je jednoznacne lepsi SysV model, kteremu staci pridat nekam par souboru, zatimco u BSD musite editovat free-formed shellscript, coz davkove neni uplne jednoduche.

-Yenya

Tak nevim, jestli FreeBSD dodrzuje BSD model, ale vetsina baliku si poradi pridanim spousteciho souboru do /usr/local/etc/rc.d/

nevim zda je to na openbsd stejne ale na freebsd je /usr/local/etc/rc.d ... jakykoli script tam nahrajete, spusti se po rebootu.

Ze bys Jéňo neovladal 'sed'? :-)))

Praveze tak jednoduche to neni - je treba v zasade osetrit dve situace:

- aplikace tam jeste neni. Pak staci echo "/spust/aplikaci" >>/etc/rc.local a tise doufat, ze pred koncem rc.local neni treba exit 0.

- aplikace tam uz je a nejak se spousti. Pak mate velky problem, protoze v zasade byste musel interpretovat cely obsah rc.local jako shell, abyste to poznal.

-Y.

"aj na msdos partisne videlo korektne dlouhe nazvy" - tahle veta me pobavila (8+3), ale myslena byla asi partisna typu vfat...

No praveze OpenBSD nema dva drivery msdos a vfat, ale prave jenom msdos, ktery je mozny pustit s autodetekci nebo mu pomoci option vnutit jestli je to jenom 8.3 nebo jestli to ma dlouhe nazvy.

BTW ta autodetekce se podiva do rootu te pratition a pokud tam nemate zadnej soubor delsi nez 8.3 tak to namountuje 8.3.

Problem s terminalem jsem vyresil nastavenim hodnoty "rxvt" do env. promenne TERM, funguje jak na lokale tak i treba z linuxu ci pres putty.

mc neni problem si zkompilovat z portu (ostatne jako hromadu dalsiho softu).
mozilla v packages neni zejmena proto, ze port je oznacen jako "BROKEN=core dumps in dynamic library constructor" (tvrdi se, ze chyba je v OpenBSD ld). Galeon nebo podobny udajne nekomu fungujou.

V mé kopii OpenBSD (3.0) byl port mc označen jako broken, proto si jej kompiluji přímo ze zdrojových kódů.

Broken byl oznacen proto, protoze program 'mc' je
nebezpecny, a pokud by ho pouzival superuzivatel
(coz vetsina mc-fanousku urcite udela), mohlo by
toto pouziti vest ke kompromitaci systemu.
Tedy Broken == SECURITY broken.

OpenBSD standardne pouziva MBR partisnu s ID A6.

Na OpenBSD partisne je pak separatni disklabel, ktere
tuto partisnu rozdeluje na dalsi BSD labels, napr.
wd0a, wd0e ...

Z pohledu DOSu, pripadne systemu ktere
pouzivaji DOS MBR oddily jako je Linux se tedy partition
s OpenBSD jevi jako jeden diskovy oddil (napr. hdc, hdd)
prestoze tento oddil je uvnitr OpenBSD rozdelen jeste
na dalsi "labels".

Techto labelu je standardne od a do h. Pokud system
pri pripojeni disku nalezne v MBR partition table na disku MBR partition, ktera neni ID A6, vyhradi pro
tuto partition specialni zaznam v OpenBSD labelu,
pocinaje wd0i a pripadne nasledujici wd0j, wd0k ...

Ad 4) Je potreba do kernelu (Linuxoveho) zakompilovat podporu pro "BSD disklabel" partition (volba File systems -> Partition Types -> Advanced partition selection -> BSD disklabel support). Pak pri dalsim bootu kernel nalezne nove partitions a ty muzete pomoci mountu -o ufs... primountovat. Samozrejme za predpokladu, ze mate i podporu pro UFS filesystem.

Jen k tomu UFS pod Linuxem...
Kernely 2.2 a 2.4 mi taky nechtely mountovat oddily vytvorene ve FreeBSD 4.5, a to z duvodu neuspechu testu pri cteni superblocku. Ve verzi 2.4.19-pre8 doslo k mensim upravam fs/ufs/super.c, predchozi ponekud proste testy na hodnoty urcitych promennych byly rozsireny, a s timhle uz mi zminene oddily Linux pripoji. Celkem snadno se tyto upravy daji udelat i do kernelu rady 2.2.

Pouzivam OpenBSD jako firewall, jako mail/DNS server, jako VPN brany, jako fileserver se sambou, senzory se Snortem+MySQL apod. Tohle vsechno ve mnoha instalacich. PF je podle meho kvalitni firewall a prechod od IPF me nijak moc starosti nenadelal. Nechci zadnou flamewar, ale v cem je Linux tak napred ve firewallu ? Co umi iptables navic co neumi PF ? Nove ve verzi 3.1 je mozne udelat v PF pravidla per-user a to jak pro lokalni pouziti, tak i vzdalene (uzivatel se pripoji/overi pomoci SSH a tim se mu udeli prava na pristup pres firewall). Stejne tak syntaxe PF je podle meho jedna z nejpovedenejsich.

Umi treba destination maskarading?

Pokud destination maskarading == port address translation, pak opoved je ano.

Treba stavovou filtraci a NAT vcetne souvisejicich ICMP
packetu? SNMP-alg pristup za 1:N nat branu? Oznacovani packetu a pozdejsi dotazy na packety s urcitou znackou? Zmenu TOS pomoci pravidel firewallu?

S tim overenim pres SSH je to smesne. Na pripojeni pres SSH si samozrejme muzu navesit jakykoli skript, vcetne modifikace firewallovych pravidel.

Navic Netfilter v Linuxu je obecne rozhrani nad kterym lze postavit ruzne filtrovaci/NATovaci a dalsi moduly, napriklad ipvs pouzivane pro load-balancing v clusterech.

Nevim, BSD [I]PF jsem videl kdysi davno, treba uz neco takoveho taky umi.

-Yenya

S tim SSH + pfrulez je to presne tak jak Yenya rika.

Koho by to zajimalo nejak vic, je tam programek authpf, kterej date uzivatelum jako shell a ono se jim to spusti po tom co se naloguji pres SSH (no jeste aby ne :) a nahodi to pravidla podle /etc/authpf/authpf.rules pripadne /etc/authpf/users/xxxxx/authpf.rules

Jako pocatecni myslenka to neni az zase tak spatny.
Kdyz nic jinyho je to dobra ukazka jako si sam nastavit pf (to je take to co jsem z toho potreboval, protoze dalsi dokumentace nic moc).


Ale jen tak mimochodem jedna z hlavnich chloub OpenBSD je ze "vsechno je super navrzene, vsechno prochazi auditem". Tenhle kod (authpf.c) jsem zrovna potreboval nejak ohnout a co nevidim. Kopirovani souboru je cut-and paste v jedne cca 200 radkove funkci. Uplne bezne se tam nezaviraji soubory, ktere uz nejsou potreba, nejaky memory leaky v parseru. Vsechno veci, ktere sice asi nepovedou k remote hole, a v beznem provozu si jich asi ani nevsimnete, ale asi bych je nepovazoval za cistej kod.

SSH & firewall - jo, to je fakt
stavova filtrace & NAT & souvisejici ICMP - jo, to umi i ipf
SNMP alg - ne
oznacovani packetu - ne
TOS - ne pres kod pf, ale pres ALTQ ano
Mam za to, ze zrovna pf ma delat firewall, load-balancig, QoS etc. bude delat neco jineho a nebude se to michat do kodu pro firewalling

ALTQ umi fakt i menit TOS u existujicich packetu, nebo jen podle TOS radit do front?

Jenze firewall je jen jeden z mnoha pripadu kdy chce clovek nejak tridit a oznacovat packety. Tak proc pro to nepouzit stejny kod? V Linuxu se to samozrejme nemicha dohromady - je tam specialni tabulka filter pro firewall, tabulka nat pro preklad adres a tabulka mangle pro upravy TOS a dalsich veci. A tabulka ipvs pro virtualni servery/load balancing. Hezke na tom je, ze tohle vsechno bezi nad jednim frameworkem pro zpracovani packetu. A kdyz budu chtit, muzu si tam napsat i svuj vlastni modul ktery bude treba packety prvociselne delky zahazovat :-), protoze rozhrani je dobre definovane a popsane.

-Yenya

"...nabízí pouze méně dokonalou podporu žurnálování pomocí tzv. soft-updates..."

Soft-updates coby méně dokonalá podpora žurnálování? Nechtelo by to trosku lepsi studijni pripravu pred psanim clanku?

>Vyspělý generátor psudonáhodných čísel PRNG, který je
>dokonalejší než ten, co máme v Linuxu. Jeho entropickou
>náplň tvoří kromě běžných přerušení od klávesnice, myši
>a disku také třeba síťový subsystém.

/usr/src/linux/arch/i386/kernel/irq.c:
request_irq - allocate an interrupt line ...
Flags:
...
SA_SAMPLE_RANDOM The interrupt can be used for entropy

Z tohoto mi pripadne, ze nahodna cisla v Linuxu mohou byt ovlivnovana vsemi prerusenimi, pokud si o to driver rekne.
Kvality vlastnich generatoru si netroufnu porovnavat.

La'd"a

Používám OBSD již od verze 2.6 a nestalo se mi, že by
to někdo hacknul. A celkem to ani moc neupdatuju. Na Linuxech se mi to stalo 3x, obvykle přes bind a ssh.
OBSD je bezvadný v tom, že se nainstaluje, rozchodí a
pak se nechá fungovat bez nějaké velké údržby.
Tolik postřeh z praxe.

To jo, BSD jsou obecne podstatne bezpecnejsi nez Linuxy. Nedavno o to byla diskuze na debianplanet.org proc neni debian tak bezpecny jako treba OpenBSD. Duvody jsou zrejme dva, debian musi predpokladat mene zdatne uzivatele (to je ten mene zavazny argument) ale hlavne BSD obsahuje rekneme 10 velmi dobre zauditovanych demonu + kod jadra. Naproti tomu debian obsahuje x tisic baliku ruzne kvality ktere neni v soucasne dobe mozne kvalitne vsechny auditovat. To napriklad znamena ze v OpenBSD mate malo pripdane velmi maly vyber treba http demonu zatimco v debianu jich je opravdu dost. Je jasne, ze se daji zkompilovat se zdrojaku, ale nic moc... Zaver je asi jasny, kvalita a bezpecnost jsou protipol uzivatelnosti a rozsiritelnosti a pri konkternim reseni je treba volit mezi obema miskama na vahach tak aby reseni daneho probelmu bylo optimalni.

Pokud vam hackli Linux pres BIND a SSH, tak by vam mohli stejne dobre hacknout i OpenBSD pres BIND a SSH. Rozdil je jen v tom, ze Linux je rozsirenejsi a tedy pro neho casteji existuji binarni exploity. O bezpecnosti to ovsem vubec nic nevypovida.

-Yenya

o SSH se nema cenu bavit, to je pochopitelne stejne, ale BIND se v OpenBSD pouziva ve verzi 4, ktera sice postrada nektere ficury, ale zase je to lety provereny kod, ve kterem by uz moc der byt nemelo.
A mimochodem, ta mensi dostupnost exploitu neni vubec spatna. Da se to sice nazvat security by obscurity, ale v praxi to funguje celkem slusne :)
(Priklad z jineho soudku: to ze temer vsechny viry jsou pro Outlook urcite neni tim, ze ostatni MUA jsou bez chyby - akorat nejsou tak rozsirene)

Dobry den,
chtel bych se zeptat, jaky je rozdil mezi OpenBSD a FreeBSD (NetBSD), ktery je lepsi (casteji a lepe updatovan), a co z toho byste doporucili na Server (http server, firewall) Diky Tomas

Obecně jsou si všechny tyto systémy velice podobné. FreeBSD je nejrozšířenější, dobře etablovaný a dá se pohodlně používat i na desktopech. NetBSD je orientovaný na snadnou portabilitu a maximální možnou kompatibilitu s klasickými unixovými standardy (pokud něco takového vůbec existuje :-). OpenBSD má zase image vysoké bezpečnosti a širokou podporu kryptografie.

Co dát na server to záleží na vašich osobních preferencích, zkušenostech, atd. Klidně to může být i Linux. V praxi budete stejně na všech systémech používat podobný software (Apache, ftpd, OpenSSH atd.).

Pokud bych si měl vyzdvihnout jeden z těchto tří BSD systémů, tak právě OpenBSD, prostě proto, že s ním mám nejvíc zkušeností a kvůli argumentům, které jsem shrnul v článku.

Když sem si instaloval OpenBSD na svůj počítač, tak jsem zjistil, že po restartu to vůbec nechodí. Vůbec neproběhne kontrola biosu a je v .... Přitom NetBSD chodí v pohodě. Fakt sqelej OS :-(

No tak v tomhle pripade bych to videl spis na chybu mezi zidli a klavesnici. Nejspis doslo k chybe "Error 273: Incompetent user" ;-)

Tahle chyba to nebude, nebot kdyz ten disk z masiny vytahnu, tak to jinde funguje. Asi to bude tim, ze developeri udelali nejakou chybku v tabulce rozdeleni disku a ten komp to uz proste nerozdejcha.

Vzhledem k tomu, jak vy ten problem popisujete bych
spis souhlasil s predchozim prispevkem o te chybe
mezi..

O GPL licenci se me nechce moc debatovat. Souhlasim s
Gatesem.

Co se tyce IPTables versus packet filter, rad bych
od autora slysel kde je ten krok 'napred.
OpenBSD ma podle meho nazoru jeden z nejnovejsich a take
nejmoderneji navrzenych paketovych filtru.
Pokud bych si mel vybirat OS na firewall mezi Linuxem a OpenBSD, vybral bych OpenBSD.

Co se tyce zurnalovacich filesystemu, neni pravda, ze
soft updates jsou 'nedokonala podpora zurnalovani'.
SoftUpdates nemaji vubec nic spolecneho s zurnalovanim.
Jsou urceny pro frontovani pozadavku na zapis na disk,
kam jsou zapisovany po kvantech a specialne setridene,
aby nedoslo ke vzniku nekonzistence metadat filesystemu.
Narozdil od klasickych zurnalovacich filesystemu, ktere
si zapisuji kazdou operaci s metadaty do transaction logu, aby tak mohly eliminovat nekonzistence vznikle neuplnym nebo spatne zorganizovanym zapisem dat na disk v pripade vypadku.

OpenBSD nebude nikdy mit filesystem, ktery bude zurnalovaci, namisto nej bude mit stejne dobrou a cas mozna ukaze ze jeste lepsi implementaci filesystemu na bazi SoftUpdates. Pro zduvodneni se podivejte na srovnani implementaci zurnalovacich systemu a FFS softupdates od McKusicka:
http://www.usenix.org/publications/library/proceedings/usenix2000/general/full_papers/seltzer/seltzer.pdf

Jeste bych rad poznamenal, ze do zurnalovaciho logu ext3 v linuxu se zapisuje pouze metadata filesystemu a ne data souboru samotnych. Pri vypadku se vam tedy casto
stane, ze fsck obnovi napr. nazvy souboru v adresarich
a pripadne metadata souboru (inode), ale soubor je povetsinou prazdny.

Komercni podpora OpenBSD v Ceske republice existuje,
informace najdete zde:
http://www.openbsd.org/support.html (cast Czech Republic)

K dispozici je i ceska konference o OpenBSD users@openbsd.cz. Vice na http://www.openbsd.cz/cs/mail.html
Myslim ze podobne diskuse typu 'nenasel jsem /etc/ld.so.conf' by mely smerovat prave sem.

Ad SoftUpdates: Možná budou SoftUpdates efektivnější ochranou proti nekonzistenci dat než kdy bude žurnálování, ale současná implementace souborového systému v OpenBSD má k ideálnímu stavu daleko.

Jako velký přínos žurnálování vidím, že se snižuje doba downtime, neboť fsck nemusí procházet disk a opravovat nekonzistence. Tuto vlastnost zatím SoftUpdates systému OpenBSD neposkytují.

Ad Ext3: Ext3 není jediným žurnálovým ss v linuxovém jádře a je možné jej nastavit jak pro žurnálování souborových metadat, tak i samotných datových souborů - viz parametr data=ordered vs data=journal.

No, to je prave ono. Precete si to srovnani na linku nahore. Zurnal FS resi opravitelnost dat "after system crash". SoftUpdates nic takoveho neresi, protoze v prvni rade nema nastat ten "system crash". SoftUpdates jsou skutecne o necem jinem.

Dobrá dost teorie, zkuste si praktický test. Vyzkoušejte vypnout síťovým vypínačem počítač s OpenBSD. Uvidíte dlouhý průběh fsck, který pravděpodobně najde a většinou i opraví nějaké chyby souborového systému. Žurnálový systém by tento downtime zkrátil na minimum. OpenBSD zatím takovou feature nemá a to jsem také konstatoval v článku.

Až budou SoftUpdates fungovat tak, že žadné nekonzistence nebudou (nevím jak by toho mohly na úrovni sw dosáhnout) a žádný fsck proto nebude nutný, tak mi teprve nebude žurnálování v OBSD chybět.

Ja teda nevimn jak vy, ale svoje servery vypinam korektne a mam u nich UPSky, tak nevim, proc by se mel, v tomto pripade kontrolovat FS. Prece ten server jen tak nezbuchne ?

Viz http://openbsd.cz/faq/cs/faq14.html#SoftUpdates
"Protože soft updates jsou jako celek stále ve vývoji, je nadále nutné fsck(8) v případě, že počítač je náhle vypnut bez správné ukončovací sekvence. Tato skutečnost bude ale opravena v budoucích verzích."
A taky http://www.mckusick.com/softdep/index.html
"...Snapshots and back-ground fsck are available in FreeBSD 5.0 and later..."
Takze pocitam, ze casem to v OpenBSD bude taky. Na druhou stranu je nutne si uvedomit, ze politika OpenBSD je pouzivat pouze opravdu stabilni a provereny kod, takze nektere vlastnosti se do nej dostavaji pomaleji nez do jinych systemu.

> Myslim ze podobne diskuse typu 'nenasel jsem
> /etc/ld.so.conf' by mely smerovat prave sem.
Prominte, ale clanek se jmenuje Jemny uvod do OpenBSD a tohle byla jedna z prvnich veci, a ktere jsem narazil, tak jsem se s ni i s jejim resenim tady podelil. Opravdu si myslim, ze je to to spravne misto, az si po precteni clanku nekdo rekne "jee to je super, zkusim dalsi OS"

Ja bych spis doporucil precist si FAQ http://opensd.cz/faq/cs/, afterboot(8) http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot
a navazujici manualove stranky...
Kazdy system je trochu jiny a neni na skodu se s nim trochu seznamit, nez se zacnu na neco ptat.

To by me zajimalo, jak muze byt PRNG bezpecnejsi nez /dev/random v Linuxu. Pouzivat jako zdroj entropie udaje ze site je _nebezpecne_, protoze v krajnim pripade muze utocnik kontrolovat jake packety prijimate. Muzete vase tvrzeni o "vyssi bezpecnosti" PRNG nejak podlozit, nebo je to jen nejaky OpenBSD FUD, ktery jste si nekde precetl?

Selskym rozumem mi prijde, ze pokud neni uplne jasne jestli sitove packety neni nahodou mozne posilat predikovatelne, tak bezpecnejsi bude ten nahodny generator, ktery tohle do sve entropie nezahrne.

Relevantni odkaz je napriklad http://www.uwsg.iu.edu/hypermail/linux/kernel/0012.2/0413.html

-Yenya

relevantni odkazy:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c

Jiste si pro a proti uz preberete sam. Pro ostatni dodavam par vynatku z tohoto zdrojaku.
*
* Sources of randomness from the environment include inter-keyboard
* timings, inter-interrupt timings from some interrupts, and other
* events which are both (a) non-deterministic and (b) hard for an
* outside observer to measure. Randomness from these sources are
* added to an "entropy pool", which is mixed using a CRC-like function.
* This is not cryptographically strong, but it is adequate assuming
* the randomness is not chosen maliciously, and it is fast enough that
* the overhead of doing it on every interrupt is very reasonable.

* As random bytes are mixed into the entropy pool, the routines keep
* an *estimate* of how many bits of randomness have been stored into
* the random number generator's internal state.

*
* When random bytes are desired, they are obtained by taking the MD5
* hash of the contents of the "entropy pool". The MD5 hash avoids
* exposing the internal state of the entropy pool. It is believed to
* be computationally infeasible to derive any useful information
* about the input of MD5 from its output. Even if it is possible to
* analyze MD5 in some clever way, as long as the amount of data
* returned from the generator is less than the inherent entropy in
* the pool, the output data is totally unpredictable. For this
* reason, the routine decreases its internal estimate of how many
* bits of "true randomness" are contained in the entropy pool as it
* outputs random numbers.
*


* If this estimate goes to zero, the routine can still generate
* random numbers; however, an attacker may (at least in theory) be
* able to infer the future output of the generator from prior
* outputs. This requires successful cryptanalysis of MD5, which is
* not believed to be feasible, but there is a remote possibility.
* Nonetheless, these numbers should be useful for the vast majority
* of purposes.
*

Tak jsem nepochopil, co timhle chcete rict. Ty popsane vlastnosti ma Linuxovy /dev/random taky (akorat pouziva SHA namisto potencialne mene bezpecneho MD5). Diskuse nad clankem pana Petricka byla o tom, jestli (a kolik) entropie zahrnout do poolu od preruseni od sitovych karet. Random number generator funguje tak, ze se pres 1-cestnou funkci (SHA nebo MD5) do poolu cisel hrnou nejaka data a zaroven se nekde drzi dolni odhad toho, kolik opravdu nahodnych bitu v tech datech je. Tohle pak pouziva /dev/random v Linuxu jako odhad toho, kolik opravdu nahodnych dat muze vydat ven (na rozdil od /dev/urandom, ktere vydava nahodna cisla na zaklade tohoto poolu ale bez toho odhadu skutecne nahodnosti).

Cili vami popsane vlastnosti umi Linux samozrejme taky. Spor je jen o to, jestli tam zapocitavat i preruseni od sitovych karet. Pokud teze autora clanku zni "v OpenBSD je RNG bezpecnejsi nez /dev/random v Linuxu", pak ja tvrdim ze je to nesmysl prave kvuli tem IRQ od sitovych karet.

Je neco nejasneho?

-Yenya

"Selskym rozumem mi prijde, ze pokud neni uplne jasne jestli sitove packety neni nahodou mozne posilat predikovatelne, tak bezpecnejsi bude ten nahodny generator, ktery tohle do sve entropie nezahrne."

To IMHO ukazuje, ze selsky rozum neni adekvatni prostredek k posuzovani bezpecnosti PRNG.

Co kdybyste misto prazdneho placani uvedl nejaky argument
pro sve tvrzeni? Zatim v teto diskusi zadny nepadl.

-Yenya

Mozna tu doslo jen ke slovnimu nedorozumeni "entropie/odhad entropie".

Tvrdim, ze :

"pokud neni uplne jasne jestli sitove packety neni nahodou mozne posilat predikovatelne, tak bezpecnejsi bude ten nahodny generator, ktery tohle do sve entropie zahrne, ale do odhadu sve entropie to nezapocita / zapocita velmi konzervativne"

Potencialne neni zvlast nebezpecne, ze generator ovlivneny vstup nacte (nahoda se nemuze zmensit), ale pokud bude spatny predpoklad o nahodnosti vstupu, bude nadhodnoceny odhad nahody v poolu generatoru.

Tvrzeni, ze "pridani ovlivnitelneho vstupu generatoru jinak dobry generator nepokazi" pripadne dolozit muzu.

Tohleto je samozrejme neco jineho. S touto formulaci souhlasim. A je to v zasade ve shode s tim, co jsem tady tvrdil - ze pouziti sitovych packetu jako zdroje entropie neni mozno vykladat jako duvod pro to, ze by byl generator v OpenBSD bezpecnejsi nez v Linuxu. Je to asi na urovni jako kdybych ja tvrdil ze ten v Linuxu je bezpecnejsi, protoze pouziva SHA misto MD5.

Podle doposud uvedenych argumentu se mi to jevi tak, ze oba RNG maji v zasade stejny algoritmus cinnosti, jen se trochu lisi v tom, co do sveho poolu nahodnych cisel zahrnuji a jaky odhad entropie tomu prisuzuji.

Mym cilem nebylo ukazat ze OpenBSD ma generator nahodnych cisel uplne spatny (to neni pravda). Jen jsem se ohradil proti tvrzeni autora clanku, ze je lepsi nez v Linuxu a proti argumentu, kterym tohle sve tvrzeni podporoval.

Mimo tuto diskusi bych se jeste chtel zeptat: Linux ma dva vystupy RNG - /dev/random (odtud lze nacist jen tolik nahodnych bitu, kolik je dolni odhad entropie v poolu; pri pozadavku na dalsi nahodny bajt se cteni zablokuje do ziskani dostatecneho mnozstvi entropie) a /dev/urandom (ktery da libovolny pocet bitu, i s tim omezenim, ze to nemusi byt uplne nahodne). Plus samozrejme souvisejici funkce v kernelu, aby TCP stack nemusel cist /dev/random pro generovani sekvencnich cisel. Ma neco takoveho OpenBSD (abych si mohl rict: ted chci skutecne nahodna data; pokud nejsou, radeji si pockam nez bych dostal neco mene nahodneho)?

Toz tak.

-Yenya

Co me v posledni dobe na OpenBSD-projektu docela vadi je ta hlaska v rubrice "daily changelog" (... momentalne nemame dost casu abychom udrzovali prehled aktualnich zmen ...). Chapu, ze maji vyvojari jiste dulezitejsi veci na praci nez si psat denicek, ale na druhou stranu - kde se ma chudak uzivatel dozvedet o objevenych potencialnich problemech nez se mu dostane do ruky nova verze ... ? Je to skoda, tahle "vychytavka" byla fakt RuleZ :-(.

subscribni si source-changes announci a mas to superprehledne k dispozici

Zdravím, s OpenBSD si už taky asi týden lehce pohrávám (když mám chvilku volna) a chtěl bych se zeptat, jestli je možné z něj vytvořit systém na jednu disketu pro firewall?
Možná by se ten firewall dal také bootovat ze sítě (3Com 905B) z Linux serveru? Každopádně aby v samotném počítači pro firewall nebyl žádný pevný disk...

Firewall na jednu disketu -- Jde to, ale nevidim v tom budoucnost. Bootovani ze site -- to nejde - potreba preportovat PXEboot z NetBSD.

Ahoj,
zkousel jsem ted vypalit bootovatelne CD OpenBSD 3.1 a ... funguje to uplne bez problemu, az jsem se lekl.

Postup:
1) Rekneme, ze mate adresar /mnt/openbsd
2) vytvorte v nem adresar /3.1/i386/
3) zkopirujte do nej to co je v ekvivalentnim adresari na nejakem ftp mirroru treba ftp://ftp.openbsd.cz/pub/OpenBSD/3.1/i386/

4) na zbytek kedesa (adresar /mnt/openbsd) nacpete co libo, kam libo
5) vytvorte si image bootovatelneho cd pomoci mkisofs
mkisofs -R -J -l -b 3.1/i386/cdrom31.fs -c boot.cat -o /mnt/openbsd.iso /mnt/openbsd
6) tento image upecte
cdrecord -v dev=0,0,0 speed=4 -data /mnt/openbsd.iso

Dobrou chut :)