Dotaz: slax a jak ho zabezpečit na USB ?

[TomasABC32]

zdravím, chtěl bych se zeptat, jak řešíte zabezpečení OS Slax na USB flešce? Taky se mi nelíbí, že mi automaticky startuje do roota, ale s tím asi nic neudělám..

---

---

Odpovědi

[Pavel 'TIGER' Růžička]

Tak čistě teoreticky je možné šifrovat oddíl a zřídit uživatele. Ale nevím, zda li je Slax na takové použití zamýšlen.

[TomasABC32]

myslel jsem si to. každopádně asi stačí. Dík.

[Josef Kufner]

Tu flashku bych rozdělil na dva oddíly. Na začátku flashky bych nechal prostor pro Slax (s nějakou rezervou, kdyby příští verze byla trochu větší) a za to pak dal šifrovaný oddíl s uživatelskými daty. Bude to znamenat jen minimální úsilí na implementaci, snadné upgrady a to vše při rozumném zabezpečení.

Možný útok pak je v nepozorovaném dvojitém (napoprvé kopie pro přípravu, napodruhé modifikace) vypůjčení si flashky a modifikaci toho nešifrovaného oddílu, ale na to pomůže jen fyzické zabezpečení.

Pokud bys šifroval i systémový oddíl se Slaxem, pořád půjde upravit zavaděč, aby někam odlil klíč. Na jednu stranu by to komplikovalo útok (pridat skript do systému je snažší), na druhou by to asi nebylo moc snadné udělat, pokud s tím Slax už teď nepočítá. Asi by spíš bylo jednodušší si ověřit hash oddílu z už nabootovaného systému – útočník informaci na šifrovaném oddílu nezmění a pokud neví, že tam taková kontrola je, tak s ní ani nic neudělá (obzvlášť pokud binárka kontrolujícího programu bude na tom šifrovaném oddílu také, např. staticky sestavený Busybox). Taková kontrola je snadno implementovatelná a asi bych neplýtval časem na něco lepšího.

Jako takovou drobnost proti laickým uživatelům bych ten šifrovaný oddíl nevyráběl jako oddíl, ale prostě jen při inicializaci Luks uvedl offset, kde data začínají (třeba prostředek flasky, ať se to dobře pamatuje). Ostatní operační systémy pak takový "oddíl" neuvidí (neboť neexistuje), pokud flashku někam jen tak strčíš.

Aby taková flashka byla trochu praktičtější a nenápadnější, udělal bych na ní FAT32 oddíl třeba na polovinu kapacity flashky a ujistil se, že na flashce není fyzicky napsaná její skutečná velikost (v nástrojích na rozdělování disku to vidět bude, ale to už není tak moc na očích). Pak to bude prostě obyčejná flashka a nikoho ani nenapadne, že by tam mohlo být něco zajímavého.

[TomasABC32]

vyčerpávající řešení, děkuji.

[k3dAR]

vzhledem k tomu ze Slax9 uz je stavenej na Debianu a pokud se nepletu jeden z duvodu proc TomasM presel na Debian je to ze nechtel pripravovat jadro, ale pouzit vychozi z distribuce, tak by nemel byt problem pouzit LUKS sifrovani na celou flasku a misto stavajiciho syslinux bootloaderu pouzit Grub2, sifrovat VCETNE /boot, tedy i /boot/grub/*, klic pro desifrovnai by se pak zadaval primo do Grubu jeste pred tim nez si nacte konfiguraci, zobrazi menu a pusti jadro a init ktere je vse na sifrovanem...

[TomasABC32]

nene, nepřešel, zůstávám věrny Mintu.. Se Slaxem experimentuji :D

[k3dAR]

no myslel sem TomasM(atejicek ) autor Slaxu, driv mel Slax postavenej na Slackware ale musel si pripravovat/patchovat/kompilovat vlastni jadro hlavne kvuli podpore AUFS, pak podpore SQUASHFS-LZMA(kterej vyvoj tehdy sponzoroval, protoze v te dobe byl dostupny mnohem horsi/pomalejsi/meneuciny format komprese SQUASHFS), dnes kdyz uz misto AUFS lze pouzit v jadre dostupny OverlayFS a Squashfs je oficilane s LZMA2 tak uz by to asi nebylo treba, nicmene i kvuli tomu se rozhodl kdyz ted ozivoval Slax ve verzi 9, ze jeho zakladem (= z ktere distribuce Slax vychazi) nebude Slackware, ale Debian a ten prave ma by default tu moznost co sem popisloval

[Josef Kufner]

To pak už není moc potřeba používat Slax a může na tu flashku rovnou nainstalovat Debian.

Nicméně použití Grubu a šifrování celého systému stále neřeší, že kus spouštěného softwaru bude nechráněný a potenciálně nepozorovaně modifikovatelný, aby někde uložil heslo k šifrovanému oddílu.

[k3dAR]

to neni pravda, Slax uz ted je postavenej na Debianu, upravy ktere sem psal jsou totozne jako by se upravoval Debian, to ale neznamene ze Slax=Debian, tedy pokud je ted chteno pouzit Slax, pridani sifrovani na tom nic nemeni

ano, Grub stage 1 a 1.5 bude nesifrovana, porad je to ale mnohem mene a mnohem komplikovaneji modifikovatelne, nez kdyz je nechranena i stage 2, /boot s jadrem, initramdiskem a rootfs

[k3dAR]

resp. nejde vyznamem nejde o upravy, ale jen o nastaveni...

[Josef Kufner]

Trochu složitější to možná bude, ale jestli překompilovat Grub, nebo přebalit initrd… Pokud útočník ví, co dělá, tak mu to zabere možná o chvilku déle. Pokud neví, tak ho zastaví ten FAT32 oddíl s trochou nezajímavých dat.

[TomasABC32]

no po malém hraní a snaze udělat ze slaxe trochu funkční systém, začínám k tomu být trochu skeptický. Nainstaloval jsem pouze několik málo programů na zkoušku jako terminál, telegram atd.. ale soubor v slax/changes/changes.dat narostl na neuvěřitelných 808Mb. To mi přijde docela dost. Samotná distribuce už zabírá na flešce přes 1,2Gb. A celkově se to brutálně zpomalilo.

Tak asi není dobrý si to vylepšovat, opravdu max. nabootovat, použít internet a zase vypnout :D

[Josef Kufner]

Tak asi není dobrý si to vylepšovat, opravdu max. nabootovat, použít internet a zase vypnout :D

Přesně k tomu to je určené

[k3dAR]

no jak sem psal je to Debian, to proc je Slax ve vychozim stavu tak malej je ze autor peclive vazil KAZDEJ balicek kterej pridava, jak uz v zakladnich systemovejch balickach i zakladnich knihovnachtam, ze neni DE(Desktop prostredi) ale jen WM(Spravce oken), neni tam pokrocilejsi terminal, ale jen xterm, atd, atd...

jakmile zacnes neco doinstalovat, tak i kdyz jde o neco mensiho, je DOST pravdepodobne ze si natahne i spousty zavislosti, ktere v bezne distribuci s DE uz mas nainstalovane jako zavislosti toho DE, nebo dalsich zakladnich/vychozich programu...
urcite si to videl (ale asi na to nedival) pri instalaci pomoci apt (ci apt-get), jak to jake balicky do dalsi doinstaluje, tak to kolik bude zabraneho mista (resp. zobrazuje se velikost balicku k stazeni (=komprimovane deb) a velikost co zabere na disku po instalaci(=rozbaleni archivu)... i kdyz v changes.dat (pokud se nepletu) se uchovavaji ve velikosti komprimovane(resp. s lepsi kompresi nez deb balicky)....
jeste 2 veci, pri instalaci deb pres apt se (v Debianu/Ubuntu/Mintu) uchovavaji stazene balicky v /var/cache/apt/archives, nevim ted jestli autor Slaxu nastavil aby se mazali hned po instalaci (coz v *buntu vsude hned nastavuju, ale pres synaptic a ted nevim kde bez nej :)
druha vec, i kdyz ti to ted hooodne narostlo, je DOST mozne ze tim ze se dotahli nejake zavislosti, instalace dalsich veci uz nemusi byt tak velka pokud uz ty zavislosti budou z predchoziho tveho doinstalovani dostupne... takze se da teoreticky rict, ze cim vic toho budes doinstalovavat, tim mene uz to bude narustat (mysleno nad ramec velikosti samotnych balicku toho co instalujes)...

[k3dAR]

neoveroval sem to, ale aby se deb automaticky mazali po nainstalovani(i kdyz manpage hovori po upgrade, tak nevim zda to plati i pro nove instalovane balicky), tak snad timto:

echo 'DSELECT::Clean "always";' | sudo tee /etc/apt/apt.conf.d/99AutomaticClean

[TomasABC32]

aha, děkuji za info. asi jsem potřeboval vědět něco o filozofii Slaxe..

[Pavel 'TIGER' Růžička]

To je spíše o filosofii debianu. Původní slax založený na slackware měl spíše svou filosofii i když stál na slackware. Přišel mi i mnohem propracovanější.