linux

Titkosított partíciók elérése Ubuntu CD-vel

sudo apt-get install cryptsetup lvm2
sudo /etc/init.d/cryptdisks start
sudo cryptsetup luksOpen /dev/sdXX name

Ezután a /dev/mapper alatt megtalálhatóak lesznek a titkosított partíciók eszközfájljai.

Szoftveres vagy hardveres RAID1?

Szoftveres! Mert:

  • Az asztali gépek alaplapjain lévő, esetleg olcsóbb PCI-os RAID kártyák nem sokat csinálnak amúgy sem hardverből, ez is szoftveres RAID – álcázva. Mert különben minek is kellene hozzá külön driver?
  • Ha elfüstöl az alaplap, RAID kártya, vagy egyszerűen csak szeretnél újabb deszkát, akkor sincs probléma – a szoftveres RAID ugyanúgy fog tovább működni az új alaplappal is, míg az (ál)hardveres lehet, hogy hardverfüggő. Megéri kockáztatni? Nem az adatok a fontosak? Elvileg azért RAID1, hogy az egyik winyó hibája esetén az adatok még megmaradjanak, ne legyen SPoF. Ha ilyen olcsó (ál)RAID vezérlőt használsz, akkor a RAID vezérlő lesz az SPoF. Pár év múlva szinte lehetetlen lesz egy mai alaplapot beszerezni, ha más lappal, vezérlővel mégsem lennének elérhetőek az adatok.
  • Sebesség szempontjából ugyanott vannak.
  • A winyót át lehet vinni másik gépbe is minden gond nélkül, még RAID vezérlő sem kell hozzá.
  • Jobban konfigurálható. Nem kell hozzá kliensprogram, az oprendszer alapból tudja. Linux és Windows is. Akár menet közben is állíthatod, nem kell hozzá újraindítani a gépet.
  • Nem kell az egész lemezt bevonni a tömbbe. Lehet csak egy-egy partícióból (partíciópárból) RAID1-et építeni, a nem túl fontos adatoknak így több hely marad.
  • Nem kell RAID vezérlő sem.

Ettől függetlenül legyen biztonsági mentésed! Ha ellopják a gépet szőröstül-bőröstül, akkor ... – nos, az ellen nem véd. Az se baj, ha a biztonsági mentés helyileg is máshol van, nehogy a géppel együtt vigyék a hordozgató winyót, vagy a DVD táskát is. A biztonsági mentés pedig legyen titkosítva, mert ha ellopják, akkor rossz kezekbe kerülhet minden személyes adatod.

(A fentiekben természetesen csak az otthoni, asztali gépek esetéről van szó.)

Szoftveres RAID partíciók elérése Ubuntu CD-vel

A régebbi Ubuntu verziók (pl.: 6.06) a CD-ről való bootolás után rögtön létrehozták a szoftveres RAID partíciókhoz tartozó eszközfájlokat (/dev/md*), ami nagyon kellemes egy esetleges rendszerösszeomlás utáni helyreállítás esetén. A 8.04-es verzió viszont már nem így működik, ott a következő parancsokkal lehet előcsalni a /dev/md* eszközöket:

sudo apt-get install mdadm
sudo mdadm --assemble --scan

Az mdadm csomag nincs rajta a lemezen, úgyhogy internetelérés szükséges az apt-get sikeres futtatásához.

Hibás hosszú í Eclipse alatt

A notebook billentyűzetéről lemaradt a hosszú í betű (angol kiosztás). Enélkül az AlgGr+J kombinációval lehet előcsalni az említett betűt. Ez azonban Eclipse alatt a Join Lines funkcióhoz egy billentyűzetkombináció is, noha a gyorsbillentyűk listájában ez nem látszik, hiába is keresünk ott az „AltGr+J”-re

A pontos ok a wikipedián az AltGr címszava alatt szerepel:

„... Windows began to allow all keystroke combinations involving AltGr to be typed by using Ctrl+Alt in its place.”

És tényleg, Windows alatt az AltGr hatása teljesen megegyezik a Ctrl+Alt kombinációéval, míg például Linux alatt ez nem így van. Ezután a Ctrl+Alt+J-re beállított billentyűkombinációt törölve Eclipse alatt is előcsalható a hosszú í betű.

További adalék, hogy Windows alatt a Shift hatástalan az AltGr+J mellé, a nagy Í betűhöz az AltGr+I-t kell használni. Nálam Linux alatt az AltGr+I és az AltGr+J mind Shift gombbal, mint Shift nélkül is működik.

Titkosított pendrive Linux és Windows alatt root jog nélkül

Most nézem, alig írtam tavaly szeptember óta, az egész elfér az oldalsó tízes listában. Ez a bejegyzést még valamikor az őszi félévben kezdtem el, azóta sem jutottam a végére. Már nem is fogok, de később még esetleg jól jöhetnek az itt leírtak.

Az előző félévben elég sok laborom volt, többnyire Windows XP-s gépekkel, rendszergazdai jog nélkül. A gépeken persze sosem voltak fent a kedvenc programjaim, mint a Firefox, Putty, WinSCP stb. Ezeket pendrive-on hurcolásztam magammal, de jó lett volna titkosítani is a fájlokat, ki tudja mikor hagyom el az eszközt. Windowsra is létezik pár on-the-fly titkosító, de ezek telepítéséhez adminisztrátori jog szükséges, másrészt telepíteni sem lett volna kedvem minden labor előtt.

Az előbbiek miatt kezdtem el egy olyan titkosítási megoldáson dolgozni, amihez nem szükséges rendszergazdai jog. A félév végére nem fejeztem be teljesen, azóta meg már nincs is rá szükségem, a most használt gépekhez van root jogom és tudom használni a LUKS-os megoldást, amiről már korábban írtam.

Szóval laborokon tipikusan Windows XP-s gépek előtt ücsörgünk, saját pendrive-val, de jobb lenne, ha a rajta lévő adatok titkosítva lennének. További igény, hogy a titkosított adatok Linux alatt is előcsalhatóak legyenek.

Kész megoldás hiányában nekiálltam barkácsolni, amihez olyan GNU/GPL licences eszközöket használtam amelyek léteznek mind Linux, mind Windows alá.

Először jelszavas ZIP fájlokra gondoltam, amelyeket egy-egy batch fájl csomagolna ki és be, hogy lehetőleg csak egyet kelljen kattintani (illetve begépelni a jelszót). Ahogy nézegettem a man oldalakat, úgy tűnik, hogy nem minden ZIP tömörítő kezeli ugyanúgy a titkosított fájlokat, valamint az USA jogi korlátozásai is bejátszhatnak. Persze, ha én viszem a zip- és unzip.exe-t is, akkor ez nem annyira gond. Viszont ha már titkosítani kell, akkor legyen GnuPG, biztos ami biztos alapon. Tud szimmetrikusan is kódolni, alapértelmezetten CAST5 algoritmust használ, bár biztosan le lehet cserélni, ha nem tetszik. Windowsos portja természetesen van.

A GPG-vel viszont annyi baj van, hogy könyvtárat nem tud titkosítani, csak a fájlokat darabonként, így a titkosítás előtt valamivel előtte össze kell csomagolni a fájlokat. Erre a ZIP is használható. (A fájlonkét történő titkosítás az eredeti fájl- és könyvtárnevek meghagyásával egyébként sem szerencsés, ezekből is lehet információkat kinyerni.)

A tömörítés után még törölni kell az eredeti fájlokat. Ezt a ZIP is képes megtenni, de ezt nem szabad rábízni. Törlés helyett inkább felül kell írni őket. A felülírást kihagyva egy kicsit is felkészült támadó bármikor vissza tudná állítani őket, hiszen törlésnél csak a fájl bejegyzése törlődik, az adatok még ott maradnak a lemez blokkjaiban. Ugyanez a helyzet a GPG által titkosított eredeti ZIP fájllal is.

Mágneses elven működő lemezeknél a felülírást többször is érdemes megejteni, tudomásom szerint viszont a flash-nél ezt elegendő egyszer végrehajtani ahhoz, hogy ne lehessen többet kinyerni a pendrive-ról a korábbi adatainkat. (Bár azért vannak kétségeim.)

Erre a felülírásra az Unix/Linux-okon régóta megtalálható shred tökéletes, neki is van Windows portja.

Az eddigi háromlépéses titkosítási művelet összefogható egy batch fájlba. Pontosabban kettőbe. Az első a pendrive bedugása után dekódolja a ZIP fájlt, majd kitömöríti, végül törli a ZIP fájlt, illetve a titkosított változatot is. Lehúzás előtt a másik fájl pedig ugyanezt eljátssza visszafele: tömöríti a titkosítandó tartalmakat, titkosít, majd felülírja és törli a titkosítatlan fájlokat.

A folyamatból látszik, hogy (legrosszabb esetben) csak az eredeti tárterület harmadát lehet csak hasznos adat tárolására használni. Egyharmad kell az eredeti fájloknak, egyharmad az ZIP fájlnak, a harmadik harmad pedig a titkosított ZIP fájlnak. Ezen kívül még szükséges némi hely a segédprogramok számára is.

A sorrenden picit lehet optimalizálni. Ha a dekódolás után rögtön töröljük a titkosított fájlt, és csak utána kezdjük el kicsomagolni az így létrejött ZIP-et, akkor a rendelkezésre álló tárterület harmada helyett akár felét is hasznosíthatjuk. Ugyanez érvényes az eltávolítás előtti titkosításra.

Beszerzendő fájlok

A fentebb vázolt rendszer összerakásához a következő listában felsoroltam a beszerzendő programokat. Töltsd le mindet, hozz létre a pendrive-on egy \bin könyvtárat, majd másold bele az említett binárisokat. Bár mindegyik valamilyen szabad licenc alatt érhető el, mégsem akartam kész csomagot készíteni. Félek, hogy a későbbieknek nem frissíteném és elavulttá válnának az összeállításban szereplő programok. Ez egy GnuPG-ben előforduló biztonsági hiba esetén különösen nagy veszélyt jelentene.

Ha ezek megvannak, akkor a következő két bat fájlt kell a pendrive gyökérkönyvtárába tenni.

pack.bat

Ez a batch fájl tömöríti és titkosítja a secure könyvtár tartalmát. Esetleg érdemes lehet a tömörítés mértékén állítani (-2 kapcsolóban nagyobb számot kell megadni – 9 a maximum). A -T hatására a tömörítés után még le is teszteli az elkészült archívumot.

Nyerhetünk még némi időt, ha a ZIP kimenetét rögtön átadjuk a GPG-nek (bin\zip -r - secure | gpg --output secure.zip.gpg --symmetric), de ekkor a -T kapcsoló hatástalan, így elmaradna ez az ellenőrzés.

@echo off
echo pack.bat by palacsint - 2007. 10. 27. - http://palacsint.hu/ - GNU/GPL

bin\zip -T -r -2 secure.zip secure
if errorlevel 1 goto zipError
echo "Zip OK"

bin\find.exe secure -type f -exec bin\shred --iterations=1 --zero --remove {} ;
rd secure

bin\gpg --output secure.zip.gpg --symmetric secure.zip
if errorlevel 1 goto gpgError

echo "gpg OK"

bin\shred --zero --iterations=1 --remove secure.zip

exit /b 0

:zipError
echo "ZIP error"
exit /b 1

:gpgError
echo "gpg error"
exit /b 2

unpack.bat

Végül a dekódolást és kitömörítést végző batch fájl:

@echo off
echo unpack.bat by palacsint - 2007. 10. 27. - http://palacsint.hu/ - GNU/GPL

if NOT EXIST secure.zip.gpg goto fileNotFound

bin\gpg --output secure.zip --decrypt secure.zip.gpg
if errorlevel 1 goto gpgError
bin\shred --zero --iterations=1 --remove secure.zip.gpg

echo "gpg OK"

bin\unzip secure.zip
if errorlevel 1 goto unzipError

echo "unzip OK"

bin\shred --zero --iterations=1 --remove secure.zip
exit /b 0


:unzipError
echo "unzip error"
exit /b 1

:gpgError
echo "gpg error"
exit /b 2


:fileNotFound
echo secure.zip.gpg not found.
exit /b 3

Valami hasonló összerakható Linux alatt is shell szkriptként.

Titkosított pendrive Linux és Windows alatt

A napokban vettem egy új pendrive-ot amit szerettem volna oly módon titkosítani, hogy mind Linux, mind windows alól tudjam írni és olvasni is. A titkosított részből elég lett volna egy kisebb darab, de mivel a Windows nem képes flashdrive-on több partíciót rendesen kezelni, így maradt az egy nagy titkosított partíciós megoldás. A lépések a következőek voltak:

  1. Particionálás
  2. Linux kernelben a Device Drivers / Multi-device support (RAID and LVM) / Device mapper support bekapcsolása. (Gondolom a Crypt target support is kellhet.)
  3. cryptsetup luksFormat /dev/sdc1
  4. /etc/crypttab fájlba a következő: corscrypt /dev/disk/by-uuid/abc... none luks,check=vol_id,retry=1
    Az UUID-t keressük ki a fenti könyvtárból.
  5. /etc/fstab fájlba: /dev/mapper/corscrypt /mnt/corscrypt vfat rw,gid=1000,uid=1000,dmask=0227,fmask=0337,noexec,user
  6. cryptsetup luksOpen /dev/sde1 sde1
  7. mkfs.vfat -F 32 -n CORSAIR /dev/mapper/sde1
  8. cryptsetup luksClose sde1
  9. /etc/init.d/cryptdisks start Ez a parancs berakja a /dev/mapper/ -be a cryttab-ban megadott eszközfájlt, amelyen keresztül elérhetjük a titkosított tartalmakat. Ha nincs rajta fájlrendszer, akkor nem megy, ezért kell a luksOpen és luskClose az mkfs-hez.
  10. mount /mnt/corscrypt

Lecsatolás:

  1. umount /mnt/corscrypt
  2. /etc/init.d/cryptdisks stop

Windows alól a FreeOTFE-vel használható, A File / Linux volume / Mount partition menüpontot kell választani.

Egyelőre FAT32-vel használom, az Ext2 IFS-es driverrel még nem volt kedvem próbálkozni.

További olvasnivaló:

LIRC módok, lircmd

Már régóta terveztem, hogy beállítom a távirányítómat a mostanában használt programjaimhoz, mint Amarok, Totem, és nem csak a régi mplayer-es beállításokkal használom. Ez még a Sarge-os időkből maradt, azóta nem nyúltam hozzá, valamint akkor a Totemnek sem volt LIRC támogatása, Amarok helyett pedig XMMS-t használtam.

Most sor került erre is, és érdekes dolgokat fedeztem fel. Egyrészt a lircmd a LIRC mouse daemon-t takarja, ami egeret tud emulálni X (és gpm) alatt. Eddig is fent volt ez a démon, de különösebben nem foglalkoztam vele, nem is tudtam, hogy pontosan mire való. Másik újdonság számomra a módok használata. Elnézve a forrás melletti Changelog fájlt ezek valószínűleg csak nekem újdonságok, bár magyarul még nem láttam róla sehol részletes leírást.

Szóval lircmd. A LIRC weblapján van róla jó doksi, lefordítani nem akarom, de röviden annyit, hogy a lircmd eredményeként kapunk egy egeret a /dev/lircm eszközfájl alatt. Ezt az X simán tudja használni, csak arra kell figyelni, hogy az xorg.conf-ban is ugyanazt a protokollt adjuk meg, mint amit a lircmd.conf-ban is.

A módok nélkül viszont nem tudtom hogyan tudtam eddig meglenni. Egy mód egy begin név és end név közti begin-end bejegyzéseket takar a ~/.lircrc fájlban. Ha belépünk egy módba, akkor csak az itt beállított funkciók működnek (na meg a globálisak, amelyek nem tartoznak semmilyen módba). Ez azért jó, mert ugyanazokkal a gombokkal lehet az mplayert és a totemet vezérelni, csupán módot kell váltani, ami egyszerűen megtehető globális funkciókkal, vagy akár kilépéskor is. Az én távirányítóm felső részén erre pont vannak is gombok TV, DVD, stb. felirattal.

A módváltó globális funkciók nálam a következőek:

begin
        flags = startup_mode
        mode = amarok
end

begin
        button  = tv
        mode    = mplayer
end

begin
        button  = dvd
        mode    = totem
end

begin
        button = media_library
        mode = amarok
end

A fentiekhez akár programindítást is lehetne rendelni, én most eltekintettem ettől, általában úgyis kézzel indítok mindent az Amarok kivételével, ami rendszerindításnál automatikusan betöltődik, és emiatt az amarok az alapértelmezett mód.

Egy jó példa a módváltáskor történő programindításra, és programból való kilépéskor történő automatikus módváltásra a G-Loaded! weblapján található.

A lircmd.conf-ban található egy TOGGLE_ACTIVATE opció, amely hatására egy általunk beállított gombbal kapcsolhatjuk ki-be az emulált egeret, ami gyakorlatilag újabb módként viselkedik.

Ajánlott olvasnivaló:

Hogyan működik az fcron Debian alatt?

Egy ideje piszkál a gondolat, hogy a kikapcsolt gép miatt elmaradó, cronnal időzített folyamatokat mégiscsak le kellene futtatni. Néhány saját szkript és a logrotate hiányzik a legjobban. A HUP Wikije szerint az anacront nem fejlesztik tovább. Az fcront ajánlották, hát felraktam. Kicsit meglepődtem, hogy nem cseréli le a Vixie-féle cront, csak mellételepül.

A következő meglepetés a reggeli bootolás után ért, ugyanis e-mailt kaptam az fcrontól: lefuttatta a hajnalra időzített feladatokat. Kicsit utánajárva a dolognak, a következőkre jutottam. Az fcron csomag feltelepítésével létrejön a következő fájl is:

# dpkg -L fcron | tail -1
/usr/sbin/anacron

A fájl valójában egy symlink a /bin/true fájlra. Ezen symlink létrehozásával kiiktatja az alábbi cron jobokat, amelyek a /etc/crontab fájlban vannak megadva:

# m h dom mon dow user  command
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

A test -x /usr/sbin/anacron parancs sikeresen lefut (igaz, 0 értékkel tér vissza), mert az anacron fájl létezik és futtatható, így a || utáni parancsok nem lesznek végrehajtva, tehát a cron nem indítja el a napi-heti-havi feladatokat a run-parts paranccsal.

Beletúrva a csomag forrásába (dpkg -x fcron_3.0.1-1_i386.deb) megtalálhatjuk a /var/spool/fcron/systab.orig fájlt:

# cat systab.orig
!bootrun(true),nice(15),serial(true)
& 03 03  * * *   run-parts --report /etc/cron.daily
& 17 03  * * 7   run-parts --report /etc/cron.weekly
& 02 04  1 * *   run-parts --report /etc/cron.monthly

Amint látszik, ezek ugyanazok a bejegyzések, amelyeket az /usr/sbin/anacron symlink létrehozásával hatástalanított az fcron. Innentől kezdve az fcron démon fogja végrehajtani ezeket a feladatokat.

Kb. ugyanez van leírva az fcron README.Debian fájljában is (/usr/share/doc/fcron/), de a fenti részletek nélkül - így talán szemléletesebb.

Winchesterek listája

Hogyan lehet legegyszerűbben kiszedni a Linuxból, hogy milyen merevlemezek vannak a gépben? Shell szkriptben akarom továbbadni másik program felé, sokat nem szánok rá időből. Csak a merevlemezek listája kell, CD és DVD meghajtók nem, flashdrive-ok szintén nem.

Ami felvetődött:

fdsik -l
Benne vannak a flashdrive-ok is.
cat /proc/partitions
Benne vannak a flashdrive-ok is.
dmesg | grep ...
Túl bonyolult.
ls /dev/{sd?,hd?}/dt>

Ebben szintén benne vannak a flashdrive-ok, és még a CD/DVD meghajtók is.

Ami eddig a legjobbnak tűnik, az a következő:

grep 0 /sys/block/{sd*,hd*}/removable 

Ha tudsz jobbat, biztosabbat, ellenpéldát kérlek írj egy hozzászólást.

Hálózatfigyelő szkript

Még az egyik laborfeladat készítése közben írtam az alábbi szkriptet. A feladat leadása előtti hétvégéken sosem aludtam túl sokat. Netkapcsolatra mindenképp szükség volt a megoldáshoz, de mondanom sem kell, a hálózat karbantartása is pont az egyik ilyen hétvégére esett. A karbantartás idejénél többet aludni meg nem nagyon volt ajánlott a szűkös határidő miatt.

Így helyettem a szkript figyelte, mikor lesz újra elérhető az internet, s ha igen, akkor elindította az XMMS lejátszását. Persze csak két percig, arra az esetre, ha mégsem lenne erőm felkelni. Az alkotó pihen, a gép pingel.

#!/bin/bash

# netwatcher script by palacsint
# http://palacsint.hu/
# 2006. 08. 19.

RESLEEP=120
CYCLE=10

while (true)
do
    date
    ping -c 1 freemail.hu
#    ping -c 1 localhost
    PRET=$?
    if [ $PRET -eq 0 ]
    then
    	xmms --pause
    	sleep $RESLEEP
    	xmms --pause
    	exit 1
    fi
    sleep $CYCLE
done
Tartalom átvétel