HD elérés tiltása [MEGOLDVA]

Linux-haladó

SZiasztok,

Van egy LIVE-cd-s (udev-et használ) testreszabott rendszerem és nem szeretném, ha azt használva a rendszer(felhasználó/én) hozzáférhetnék a gépben lévő merevlemezekhez (IDE/SATA/SDD...).

Hogyan lehet ezt megoldani? Sajnos a kernel boot paraméter hdb=noprobe nem látszik működni.

Üdv.:TamsA

ps.: Köszönöm a sok megoldási javallatot, van ami szimpatikus és van amihez meg nem értek (még), de legalább lesz út amit járhatok.
Első körben az udeves tiltást eszközöltem, de restricted kernel lesz a végső megoldás.

  • 10637 megtekintés

( trey | 2013. 08. 23., p – 10:03 )

Ha a kernelben nincs hozzá támogatás nem tudsz hozzáférni. Pl. fordítasz statikus kernelt SCSI disk support nélkül. 


 Device Drivers  --->
 SCSI device support  --->
  < > SCSI device support
  < >   SCSI disk support
  < >   SCSI CDROM support

 SCSI low-level drivers  --->
  < > Serial ATA (SATA) support

Vagy ilyesmi. Majd kicseréled a kernelt a rendszerben.

--
trey @ gépház

"Ha statikus a kernel, akkor nem is tudok modult betölteni?"

Ahogy én tudom (mondjuk 7-8 éve nem fordítottam saját kernelt) nem.

"Egyáltalán a SCSI-device fordíthó modulba?"

Természetesen. Külön az scsi disk, scsi cd-rom, scsi tape stb.

Egyébként moduláris kernel esetén is van mód a szigorításra. Van egy egyirányú kapcsoló:

/proc/sys/kernel/modules_disabled

Ezzel le lehet tiltani a modulok be- és kitöltését:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?…
http://www.outflux.net/blog/archives/2009/07/31/blocking-module-loading/

Ha egyszer beállítottuk "1"-re, akkor - elvileg - nincs mód már kikapcsolni reboot nélkül.

(Ubuntu-n legalábbis...)

--
trey @ gépház

( tamsa | 2013. 08. 23., p – 12:54 )

Na persze túrom a netet és ötelteket gyűjtök ...

Íme a +oldásom ....

  • készítsünk rule-t
    /etc/udev/rules.d/81-nohdd.rules 
    
KERNEL=="sda", OPTIONS+="ignore_device"
BUS=="usb", OPTIONS+="ignore_device"
  • tuti ami tuti törljük a device-okat
    rm -f /dev/sd*

Nos ehhez mit szósztok?

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

valamikor implementálom ... és beszámolok az eredményről.
Minden esetre a "kézi" mahináció sikeresnek tűnik ...
Rule-file készítése után service udev restart, majd rm -f /dev/sd* nem tudtam elérhetővé tenni a diszket. Sem partprobe sem más dologgal. Nyilván a szabály törlése más dolog.

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

( uid_7086 | 2013. 08. 24., szo – 14:09 )

Voltaképp mit szeretnél megakadályozni ezzel?
Véletlen károkozást?
Mire használod azt a live linuxot?
Nem lenne egyszerűbb virtuális gépbe tenni?

Igazából trey megoldása a tökéletes! A többi csak alternatív megoldások keresése.
Ez egy olyan LiveCD amit a munkahelyemen állítottam össze. Csak vpn+ rdp-re használják. Eddig nem volt vele semmi baj (most sincs) csak biztonsági aggályok merültek fel vele kapcsolatban (szerintem túlzóak) ezért érdeklődtem, hátha valaki belefutott már ilyenbe.

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

Attól kezdve, hogy külső eszközről lehet bootolni egy gépet, felejtős a biztonság szó ilyen jellegű használata. ;)
(mi a biztosíték rá, hogy a kedves power user nem tesz be a tiéd helyére egy GRML-t mondjuk?)
Olyan megoldást láttam, hogy BIOS password védett, külső eszközről letiltva a boot (USB, CDROM stb) és csak a cég szakemberei által telepített windows-t lehetett indítani, azt is a lehető legalacsonyabb jogosultságokkal. (és még ez sem jelent 100% biztonságot, mert akár a vinyót is kicserélheti egy kicsit is hozzáértő, max. nyoma marad)

ui: persze mindez leginkább a főnökeidnek/megbízóidnak szólna, ha olvasnák. ;)

Többé-kevésbé biztonságos(abb) módszer: vinyó ki, hozzá való SATA/SCSI/ATA interface alaplapból kitép, boot kizárólag PXE, diszket meg nfs-ről/samba-ról alátenni.
Nem kell CD, én már nem tudom megkerülni (a BIOS-ban való diszkvezérlő letiltást csak azért nem tartom jónak, mert néhány BIOS-hoz láttam "generálnyitót", de pl. a notebookomnak is van olyan jelszava, ami nyitja a BIOS-t, ha elfelejtem a jelszót és ezt nem lehet módosítani, csak alaplap cserével vagy talán még azzal sem. Egyedül a titkosított diszkkel nem tud mit kezdeni, azt legyalulja, ha ezzel indítom a gépet)

A régi (nagyon régi), már nem használt desktop gépemben még AMI BIOS volt, ha jól emlékszem. Ezeknek volt interneten is megtalálható passwordjük, amivel bármikor be lehetett lépni az egyébként jelszó védett BIOS-ba is.
Újabbaknál ez talán már nem divat, de mérget nem vennék rá. ;)

A másfél-két éves Dell laptopomban meg olyan megoldás van, hogy ha elfelejtem a BIOS jelszót, felhívom a supportot, jelzem, hogy gond van, elküldöm e-mailben a számla másolatát, hogy enyém a kérdéses gép, akkor a gyári azonosítója alapján visszaküldenek egy jelszót, amivel bármikor be tudok lépni. Akkor is, ha elfelejtettem az általam beállított jelszót. Egyedül a jelszóvédett diszk van ilyenkor biztonságban, mert annak tartalmát állítólag törli, ha így indítom a gépet.

Ennél bővebbet nem tudok.

( johans | 2013. 08. 25., v – 08:19 )

Trey megoldásán kívül meg lehet ezt csinálni valamilyen kötelező hozzáférés védelmi modul (SeLinux, AppArmor, RSBAC stb.) használatával is, ami elegáns megoldás, csak konfigurálni jóval nehezebb.

Apparmor? Nem tudom, lehet, hogy hibásak az elképzeléseim róla, de úgy tudom, ott egyesével kell programokhoz profilt gyártani. Amihez nincs profil, az nincs korlátozva. Rosszul tudom?
(bár mintha ugyanez igaz lenne a SELinux-ra is, csak ott "gyárilag" kapsz egy jókora szabályrendszert, ami miatt nem annyira feltűnő...)

Tévedés joga természetesen fenntartva, ezért is a kérdőjel. :)

Apparmorban én sem vagyok otthon, de mintha lehetne child processre vonatkozó szabályokat tenni, ahol a child process lehet "*" is. És hát Linuxon mindenki /sbin/init ősanyánktól származik. (de persze nem biztos, hogy ez így a gyakorlatban is működik)
SeLinuxon biztosan nem igaz amit írsz, ott konkrétan valamilyen domainbe mindig tartozik az adott process, akár van rá külön szabály, akár nincs. És csak azt csinálhatja, ami az adott domainben explicit módon meg van engedve.

Vissza akartam rakni a SELinuxot, hogy megnézzek pár ezzel kapcsolatos dolgot, de feladtam.
A régebbi Debian verzión lehet, hogy normálisan működött, de Wheezy-n finoman szólva nem tökéletes.
Az auditd logját teleszemeteli olyan hibákkal, amiknek nem lenne szabad megjelenniük, úgyhogy rövid úton ment vissza a kukába a kis drága. :(
(sshd, rsyslog meg a bánat tudja, még hány program akadt fenn rajta, pedig a default-policy-t raktam rá)

( uid_7086 | 2013. 08. 26., h – 08:49 )

Kicsit gondolkodtam a problémádon. Kivételesen komolyan kérdezem: nem lenne megoldható, amit korábban említettem?
Külső boot eszközök letiltása, BIOS jelszóvédett, hálózatról bootolni a saját image-edet, (és ahogy mások javasolták) olyan kernellel amiből kivetted a diszk támogatást.
A PXE-t összehozni nem egy nagy szám, nekem is sikerült. (igaz, én debian telepítőhöz használtam, ahhoz volt step-by-step leírás)