log69 blogja

http://opensource.osu.edu/sites/default/files/mactalk.pdf (2010)

Rövid, tömör prezentáció, érdekes hangvétel, néhol kritikával pl. SELinux gyenge doksijára.

Pozitív hangvétel Tomoyo-val kapcsolatban.

Nem telek be ezzel a bloggal:
http://kmandla.wordpress.com

Főleg CLI függőknek ajánlott, de nagyon termékeny sok infó.

A Software rész meg egy CLI program gyűjtemény:
http://kmandla.wordpress.com/software/

Hirtelen amit nem ismertem, slurm és bmon. Gondoltam megírom neki, hátha nem ismeri a nethogs-ot, de nem, persze hogy blogolt róla már :)

Átalakítottam tomld-t openSUSE 12.1-re és úgy tűnik, működik.

A /var/log/syslog-ot messages-re állítóttam, így Debian és Suse alapon is kompatibilis. A /var/local mappa hiányzik alapból, ezt megoldottam rekurzív mkdir-rel induláskor. Külön init script-et is kellett csinálnom. Ezt is még át kell néznem hogy megfelelő legyen. Ugye itt a Debian-os start-stop-daemon helyett startproc és killproc van. Egyelőre ez is működik.

Habár csak bugfix-eket akarok tolni most már csak a következő verzióba, néhány hasznosabb dolgot betettem az elmúlt napokban:

Mostantól az --info (-i) kapcsoló mutatja a fő domain neveknél egy csillaggal, hogy melyek vannak már kikényszerítő módban, és százalék értékkel a tanuló módúak mellett, hogy hol tartanak jelenleg. Ez mindenképpen szükséges, mert ezen kívül nem volt kényelmes és gyors rálátás az aktuális állapotra. Pl.:

*/sbin/dhclient
*/usr/sbin/unbound
/usr/bin/centerim-utf8 (4%)
/usr/bin/claws-mail (34%)
/usr/bin/irssi (0%)
/usr/bin/ssh (0%)
/usr/lib/apt/methods/http (0%)
/usr/lib/chromium-browser/chromium-browser (52%)
/usr/lib/openoffice/program/soffice.bin (0%)
/usr/sbin/dnsmasq (10%)
/usr/sbin/exim4 (1%)

Áthozom ide inkább ezt a szálat, hogy ne a Raw Therapee cikkjébe kerüljön a nem odatartozó téma.

Új kapcsoló --notify (-n)

A daemon részről paraméter nélkül elég, kliens oldalról pedig a lefuttatandó parancs paraméterekkel. Nem kell root jog. Ekkor a daemon fontosabb üzenetei buborékba dobálhatók.

Csomag telepítésekor ehhez menüpontot is tervezek létrehozni majd. Így 1 klikk telepítés, 1 klikk pedig a figyelés elindítása. Betettem alapértelmezetten egyébként a tomld.conf-ba, tehát nem kell semmit állítani telepítéskor ehhez.

Pl.:

# daemon indítása

sudo tomld -n

# és párhuzamosan elindítva a klienst

tomld -n "notify-send tomld"

Sajnos még több durvább hibákat találtam és javítottam a kódban. Továbbra is 0.39.

Ha valaki használja, akkor legyen szíves újra generálni a szabályokat. Egyelőre nem akarom bekapcsolni, hogy ezt automatikusan megtegye tomld (új szabály ID-t adva neki).

Olyan feature-t betettem, hogy az --info kapcsolónál a kikényszerítő módú domain-eket más színnel jelezze ki, így könnyen kaphatunk egy státuszt, hogy a meglévőkből mik azok amik már beértek, meg ez a kapcsoló használható akkor is, miközben fut a másik folyamat.

Plusz köszönet muczy-nak azon ötletéért, hogy a --learn kapcsolóval ne az összes domain-re vonatkozzon az átmeneti tanuló mód, hanem lehessen megadni is. Így most paraméter nélkül az összesre vonatkozik, ha megadunk paramétert (amelyek patternek), akkor az ezekre illeszkedő domain-ek lesznek csak átkapcsolva, és persze csak akkor, ha volt hozzáférés megtagadásuk.

Ha valaki használná, akkor legyen szíves frissíteni. Nem végleges a 0.39, de több fontos hibát is javítottam.

Köszönet muczy-nak a jelzésért és tesztelésért!

Tettem bele egy scriptet az egyszerű debian csomag frissítéshez: tomld/debian/debian_update.sh

Nemrég kiadtam és megjelent az első teljesnek tartott verzióm. Ehhez szeretnék írni néhány gondolatot.

Ha valaki szerverre telepíti, akkor az /etc/tomld/tomld.conf fájlba betehet e-mail értesítést, pl. a helyi root-nak és egy külső címre:

[mail]
root
someone@somewhere.org

Itt a mailer binárist fix-en tárolom a kódban biztonsági okokból: /usr/sbin/sendmail
Ha valakinek más útvonal kell, akkor fordítsa le azzal a beállítással, itt az idevonatkozó kódrészlet:

char *mail_mta  = "/usr/sbin/sendmail";

Elkészítettem a folyamat ábrát tomld-hez.

Mivel régóta upgrade-elgetem a fő debian rendszeremet a notimon (etch'n'half ha jól rémlik), ezért gondoltam nyomok neki egy ilyet root-ként:

debsums -s

Jól tettem, sok .mo nyelvi fájl hiányzott, meg az md5sums bejegyzés is néhány fontosabb csomaghoz (binutils, netbase stb.). Gondolom a régi upgrade miatt itt-ott lehet hiányos volt a csomag, mivel testing-re is váltottam korán kétszer is, amely még azért tartalmazhatott hibát. Ugye ez lefuttat egy md5sum ellenőrzést a /var/lib/dpkg/info/*.md5sums fájlok alapján, és megnézi, hogy az adott csomag fájljai a helyükön vannak-e és épek. Amelyik csomagra panaszkodott, azt újratelepítettem:

Végeztem tomld Python-ban írt kódom funkcióinak átkódolásával C-be (majdnem egy nagyságrend lett a sebesség különbség egy nem mérvadó méréssel úgy, hogy valamelyest többet dolgozik a C megvalósítás). A jelenlegi v0.35-ös verzió már használható manuálisan szabályok egyszerű létrehozására, de még biztos sok hibát tartalmaz.

Amit meg szeretnék most valósítani, az az, hogy automatikusan megmondjam, hogy egy adott process-hez mikor jött el az idő, mikor a tanuló módból átkapcsolom kikényszerítő módba (lehet hogy még beiktatok egy engedő módot, ez a 2-es szint a 0-3 tartományban, ahol naplózza a hozzáférés megtagadást, de megengedi, tehát csak log-ot gyűjteni jó). Ugye így néznek ki a szintek:

https://bugzilla.novell.com/show_bug.cgi?id=668381

http://sourceforge.jp/projects/tomoyo/lists/archive/users-en/2011-June/…

v0.32

Ez az első teljesen működő C verziója tomld-nek. Sok tesztelés szükséges, sok hiba lehet még.

A python verzióhoz képest egyetlen dolog hiányzik még, ez a fájlok nevében a véletlenszerű minta felismerése. Ezt teljesen átdolgozom.

Ha meglesz az automatikus kikényszerítő mód, amely felismeri mikor gyűlött elég szabály az adott domain-hez és így mikor kell átkapcsolni kikényszerítő módba, akkor teljes lesz a program. Onnétól hiba vadászat és sok dokumentáció meg tesztelés kell. meg debian csomag az egyszerű telepítéshez, ami szolgáltatásnak beállítja egyből.

Most fedeztem fel, hogy van gtk-s felülete az Audacious-nak. Nekem nagyon bejön a skinned-hez képest.

audacious -i list

Available interfaces:
  gtkui           - GTK Foobar-like Interface
  headless        - Headless Interface
  skinned         - Audacious Skinned GUI

audacious -i gtkui

Írom át a python kódomat C-be. A felénél túl vagyok.

Úgy gondolom, hogy jó sebességet tudtam már python-ból is kihozni a regex modullal, mivel ott natív kód futott és a legtöbb text manipulációmat ezzel csináltam. Illetve optimalizáltam is sokat. Úgy, hogy sok beépített függvényt használtam, az egyik rendező rutinom 0.6 sec alatt futott, ezt C-ben 0.1 alatt sikerült kihozni.

Mivel C-ben nincs dinamikus string kezelés, ezért az előre nem látott méretekhez egy fix nagy méretet foglalok mindenhol. Ez kicsit szívás lett, mert így /usr/bin/time -v paranccsal azt mutatja, hogy a max rezidens memória foglaltságom 207 MB lett egy alap futtatásnál (sok belső ciklus miatt is elfutott ez a méret). Ez python-nál 40 MB körül van mindig. Most ezt sikerült lefaragnom 5 Mb-ra. Ez már elég jó, viszont a stringek miatt a VM mérete még hatalmas.

"Mindkettő kell" >> http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/

Egyéb infó:
http://wiki.debian.org/DNSSEC
https://unbound.net/

Teszteltem Win XP SP3 alatt is unbound-ot, jól működik. A Win-es telepítőnél nem kell a root key-vel szórakozni, felteszi magától. Gyakorlatilag 2 lépés: unbound win-es telepítővel feltesz + interface DNS átállítása localhost-ra.

Itt lehet tesztelni a DNSSEC-et: http://test.dnssec-or-not.org
szerk.: http://dnssectest.sidn.nl

(Figyelem, csak óvatosan! Működő DNSSEC esetén Borat képe néz vissza a teszt oldalról! ;))

"DNS security extensions now available for Debian's zone entries."

http://www.debian.org/News/2011/20110512

http://wiki.debian.org/DNSSEC

Forrás itt.

"An estimate of how much RAM you would need to make a 99.99% guarantee that there never is OOM (out of memory) for this workload."

"Normally the kernel will overcommit memory. That means, say you do a 1GB malloc, nothing happens, really. Only when you start USING that malloc memory you will get real memory on demand, and just as much as you use. So you sort of take a mortgage and hope the bank doesn't go bust. Other cases might include when you mmap a file that's shared only when you write to it and you get a private copy of that data. While it normally is shared between processes. The Committed_AS is a guesstimate of how much RAM/swap you would need worst-case."

Nem stimmelnek az adatok a github fiókomban. Tegnap este óta megváltozott pl. a 52 week participation adat, illetve a Graphs/Traffic is hülyeségeket mutat random módon, mondjuk ezt már 1-2 hónapja tapasztalom reg óta.

Másnál nincs gond?

Mindig a bash beépített time parancsát használtam eddig sebesség mérésre, de most felfedeztem a /usr/bin/time parancsot. Előnye hogy egy rakás statisztikát kiír a folyamatról a parancs futása végén. Ilyen pl. a felhasznált idők, felhasznált legnagyobb rezidens memória méret, egyéb I/O statisztika.

Példa chromium-ra pár oldal meglátogatása után:

/usr/bin/time -v chromium-browser 
        Command being timed: "chromium-browser"
        User time (seconds): 8.08
        System time (seconds): 2.53
        Percent of CPU this job got: 11%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:34.75
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 266960
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 63674
        Voluntary context switches: 38128
        Involuntary context switches: 9406
        Swaps: 0
        File system inputs: 2104
        File system outputs: 24808
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

http://www.cyberciti.biz/tips/howto-use-openbsd-in-the-corporate-enviro…

eredeti link:
http://undeadly.org/cgi?action=article&sid=20110420080633

Csináltam egy videót tomld 0.29 bemutatására Ubuntu 10.10-en. A rendszer virtualizálva volt KVM-en, úgyhogy a látható 1 másodperces sebesség a valóságban csak 1-2 tized körüli.

720p hd felbontás elérhető

Firefox-hoz való szabály generálás látható pár percen belül. Persze elvégezhető minden alkalmazáshoz, ez csak egy gyors demo és nyilván jobb ha a böngészőhöz is egy egész napos használat után futtatjuk másodszorra tomld-t a kikényszerítő módba kapcsoláshoz.

Mostanában többet spam-melek tomoyo témában, de nem igazán volt eddig ilyen minőségű dokumentáció Tomoyo-hoz.

Jamie Nguyen teljesen újraírta a Tomoyo 1.8-as doksiját. Hátha érdekel valakit. Elérhető itt:
http://tomoyo.sourceforge.jp/1.8/

A szabályok generálásához idő kell. Hogy mennyi, az a folyamat sikeres használatától függ. Hiába az automatizmus, ha a folyamat sokáig nem nyúl egy fájlhoz vagy nem hív meg egy metódust, akkor lehet, hogy az be sem kerül a szabályok közé. Márpedig jó lenne mielőbb teljessé tenni a szabályait minden domain-nek.

A begyűlt szabályok számának görbéje az idő függvényében ezért sajnos hiperbolikus. Egyre kevesebb szabály jön idővel érthető módon.

Ezért imho jó lenne fenntartani egy kialakított infrastruktúrát, ahol a más által kitaposott szabály rendszert (ami neki idő/energia és pénzbe került) feltölthetik a domain neve alapján. Ezzel sok idő spórolható, és ez felhasználóként összeadódik, ami már komoly időt ad ki. Illetve a szabályok egyre teljesebbé válhatnának a hozzáadott "javításokkal".