All posts by Miroslav

Šifrovaný filesystém v Linuxu

Většina z nás se již někdy ocitla v situaci, kdybychom byli rádi, aby naše data byla opravdu jenom naše. Existují různé druhy ochran pro zabránění přístupu útočníka přes síť do našeho počítače, ovšem problém může nastat, když tento útočník získá fyzický přístup k našemu datovému médiu. Pak je již rychle schopen data odcizit a přečíst. Jak se však dá takovéto situaci zabránit? V tomto případě by nás mohlo zachránit šifrování našich dat.

Šifrování dat

Šifrování je proces, při kterém naše data změníme takovým způsobem, že budou pro jinou osobu (útočníka), bez znalosti informace jakým způsobem data vrátit zpět, naprosto k ničemu. Opačný proces se nazývá dešifrování. Konkrétních možností jak mít naše data v bezpečí je několik. Můžeme zašifrovat celý disk nebo diskový svazek. Také můžeme zašifrovat celý nebo část (soubory/složky) filesystému. Poslední možností je využít kryptografický filesystém. My si teď tyto způsoby rozebereme, vysvětlíme a ukážeme si jejich klady a zápory. Také si ukážeme práci s šifrovacím nástrojem cryptsetup.

Šifrování celého disku

Šifrování disku je, jak už název napovídá, metoda šifrování dat, při které zašifrujeme celý pevný disk nebo diskový svazek. Existují tři způsoby, kterými je možno disk zašifrovat. Buďto pomocí speciálního software nebo můžeme využít samošifrovacího disku.
V případě softwarového řešení nám v paměti počítače běží program, který interpretuje data mezi úložištěm a zbytkem počítače. Tento program dešifruje data z disku za pomocí klíče (většinou zpřístupněného pomocí hesla, které uživatel zadá jednou při startu PC nebo přístupu k úložišti). Naopak při zápisu data zase šifruje. Bez tohoto interpretování se data na disku tváří jako náhodná.
Samošifrovací disky využívají tzv. kryptoprocesor. Ten je napevno vystavěn do disku. Tento procesor podobně jako u softwarového šifrování interpretuje data, ale tentokrát je tato operace prováděna mezi fyzickým diskem a SATA rozhraním. Opět je nutné aby se uživatel autentizoval, což provádí před startem operačního systému.
Jak se tedy výše zmíněné možnosti liší? Šifrovací software je dostupnější, existují jak komerční tak open source programy. Za samošifrovací disk si sice připlatíme, na druhou stranu ovšem nabízí neporovnatelně lepší výkon, jelikož šifrovací a dešifrovací operace provádí kryptoprocesor, narozdíl od software, který musí využívat procesor počítače.

Šifrování na úrovni filesystému

Šifrování na úrovni filesystému nám umožňuje zabezpečit pouze část dat uložených na disku. Touto částí můžeme rozumět celý souborový systém, ale i několik složek nebo souborů. Na rozdíl od šifrování celého disku se nešifrují metadata, jako jsou informace o adresářové struktuře nebo jménech a počtu souborů ve složce, což může být nežádoucí. Tento problém řeší například filesystém ZFS, který metadata zvlášť šifruje na disk. Jedna z výhod šifrování na úrovni filesystému je taková, že můžeme různé soubory/složky šifrovat různými klíči. To je vhodné jak z hlediska bezpečnosti, tak toho můžeme využít jako autorizačního systému (různí uživatelé budou mít přístup k různým souborům). Dále je výhodné, že šifrujeme opravdu jen ta data, která chceme zašifrovat, nedochází tak ke zvýšené režii při přístupu k veřejným souborům jako v případě šifrování na úrovni disku, kde musíme dešifrovat každý soubor.

Kryptografický filesystém

Kryptografický filesystém je speciální typ filesystému, kde se již předem počítá s tím, že data v něm obsažena budou šifrována. Používá se ho většinou jako nástavba na běžný filesystém. Existují různé kryptografické filesystémy, které používají různé způsoby šifrování. Jako příklad si můžeme uvést EFS (Encrypted FileSystem) společnosti Microsoft.

Problémy

Při šifrování dat výše zmíněnými způsoby existuje několik problémů, které je nutné řešit. Prvním takovýmto problémem je bootování systému. V případě šifrování na úrovni filesystému nám tento problém pravděpodobně nevznikne, stačí nešifrovat soubory nutné k bootování. Šifrování celého disku však musí vytvořit nezabezpečenou partici, kam se vloží tyto soubory. Dalším problémem je správa klíčů. Při filesystémové úrovni šifrování má každý uživatel jeden nebo více klíčů, které jsou sdruženy v tzv. klíčence. Ta je zašifrována na disku pomocí master klíče. Ten je chráněn pomocí hesla, které je známé uživateli.

Cryptsetup

Nyní si ukážeme vytvoření šifrovaného svazku pomocí nástroje cryptsetup. Ten nám umožňuje využívat šifrovacího subsystému dm-crypt k vytváření, používání a správě šifrovaných svazků. Cryptsetup využívá dm-crypt spolu s jeho nástavbou LUKS, která přidává k funkcím dm-cryptu správu klíčů nebo třeba dvouúrovňové šifrování.

Při vytváření nového diskového svazku, je vhodné ho zaplnit náhodnými daty. Tak znemožníme nebo alespoň ztížíme identifikaci našich šifrovaných dat na daném svazku. Tohoto můžeme docílit použitím vhodného nástroje, jako je třeba dd. Použijeme generátor náhodných čísel /dev/urandom. Tato operace však může trvat delší dobu. Parametr bs (blocksize) nám operaci urychlí.

fallocate -l 512M /root/svazek
dd bs=1M count=512 if=/dev/urandom of=/root/svazek

Nyní se můžeme pustit do vytvoření šifrovaného oddílu. K šifrování našeho svazku zvolíme šifru AES v šifrovacím módu xts. AES (Rijndael) volíme proto, že patří k těm nejrychlejším ze současně standartně používaných šifer (Serpent, Twofish, RC6, MARS). Mod XTS je zase populární díky úrovni bezpečnosti a podpoře náhodného přístupu k datům. Velikost klíče bude 512 bitů a přepínačem -y si zajistíme kontrolu hesla, které budeme v tomto kroku zadávat.

cryptsetup -c aes-xts-plain -s 512 -y luksFormat /root/svazek

Teď když máme vytvořen nový šifrovaný svazek ho musíme zpřístupnit, vytvořit na něm vhodný souborový systém a připojit.

cryptsetup luksOpen /root/svazek encrypted
mkfs.ext4 /dev/mapper/encrypted
mkdir /mnt/encrypted
mount /dev/mapper/encrypted /mnt/encrypted

Nyní máme vlastní zašifrovaný svazek. Můžeme k němu přistupovat přimo přes /mnt/encrypted. Po ukončení práce se zařizením ho zase odpojíme a zrušíme mapování.

umount /dev/mapper/encrypted
cryptsetup luksClose encrypted

Pokud budeme chtít, aby náš zašifrovaný svazek byl automaticky připojený při bootu OS, musíme upravit soubory /etc/crypttab a /etc/fstab.

echo "encrypted /root/svazek none luks" >> /etc/crypttab
echo "/dev/mapper/encrypted /mnt/encrypted ext4    defaults 0  0" >> /etc/fstab

Nyní budeme při startu systému vyzváni k zadání hesla k zašifrovanému svazku.

Protože po připojení našeho zašifrovaného svazku jsou naše data ve swapu nešifrovaná, je vhodné jej šifrovat. Toho můžeme dosáhnout následujím způsobem (předpokládáme swap file na /dev/sda5).

swapoff /dev/sda5
cryptsetup -d /dev/urandom create cswap /dev/sda5
mkswap /dev/mapper/cswap
swapon /dev/mapper/cswap

Pro připojení swapu při bootu OS, musíme opět doplnit záznamy do souborů crypttab a fstab. To uděláme následovně.

echo "cswap /dev/sda5 /dev/urandom swap" >> /etc/crypttab

Jelikož ale již máme pravděpodobně nastavený swap v /etc/fstab, musíme záznam o něm vyměnit za:

/dev/mapper/cswap none            swap    sw              0       0

Závěr

V tomto příspěvku jsme si ukázali typy šifrování souborů v našem systému. Shrnuli jsme si jejich klady a zápory a nastínili jsme některé problémy, které nás mohou potkat. Nakonec jsme si předvedli, jakým způsobem můžeme pomocí nástroje cryptsetup vytvořit a používat šifrovaný svazek. V případě dotazů mě neváhejte kontaktovat na info@bcvsolutions.eu.

OSGi neboli Open Service Gateway

OSGi neboli Open Service Gateway initiative je specifikace dynamického modulárního systému pro programovací jazyk Java. V tomto článku si povíme něco o historii OSGi, ukážeme si jednoduchou aplikaci napsanou pomocí OSGi a podíváme se na přidávání a odebírání modulů z aplikace.

Historie

Práce na OSGi specifikaci začala v roce 1999. Původně byla cílena na síťová zařízení a vestavěné systémy a zde se také prosadila a začala využívat. V roce 2003 se vývojářský tým platformy Eclipse rozhodl vyměnit proprietární modulární systém za vlastní implementaci OSGi s názvem Equinox. Dnes už většina aplikačních serverů podporuje nebo plánuje podporu OSGi. OSGi se tak na poli enterprise aplikací stává alternativou k zatím rozšířenější Javě EE. K dalším populárním implementacím OSGi kromě Equinoxu patří také Apache Felix nebo Knopflerfish.

Využití

Hlavní výhoda OSGi při jeho použití k vývoji aplikace je právě modulárnost. Umožňuje nám to za běhu naší aplikace přidávat a odebírat její součásti. Zlepšuje se nám tak udržovatelnost aplikace, například můžeme aktualizovat jednu část aplikace, aniž bychom museli zbylé komponenty této aplikace odpojit z provozu. Mezi další výhody patří také možnost mít zavedeno více verzí jednoho modulu. Pokud máme dvě části aplikace, které závisí na různých verzích jedné knihovny, OSGi nám umožní běh obou verzí zároveň. Každé komponentě bude umožněn přístup pouze ke správné verzi této knihovny.

Dále se budeme věnovat ukázce základní práce s OSGi. Pro demonstraci budeme používat právě výše zmíněný Equinox, který je dodávaný v jednom balíku spolu s Eclipse IDE. Stáhnout si ho můžete třeba z oficiálních stránek. Pro vytvoření nového OSGi modulu si vytvoříme tzv. Plug-In Project.

Bundle

V OSGi se každý jednotlivý modul aplikace označuje jako tzv. bundle, což je obyčejný jar archiv s přidaným hlavičkovým souborem MANIFEST.MF. Při práci s moduly používáme právě tento soubor a nadefinujeme si zde, jaké balíčky importujeme a exportujeme.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: HelloService
Bundle-SymbolicName: com.bcvsolutions.sample.HelloService
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.bcvsolutions.sample.service.impl.HelloServiceActivator
Bundle-Vendor: BCVSOLUTIONS
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Import-Package: org.osgi.framework;version="1.3.0"
Export-Package: com.bcvsolutions.javaworld.sample.service

Tento soubor obsahuje několik důležitých hlaviček. Mezi pro nás nejdůležitější patří Bundle-Activator, Import-Package a Export-Package. Bundle-Activator označuje tzv. activator třídu. Ta definuje dvě základní metody každého OSGi bundlu start a stop. Tyto metody spouští a ukončují náš bundle. Import-Package nám definuje balíčky, které náš bundle potřebuje. Pokud není bundle obsahující daný balíček přítomný v OSGi kontejneru, není možné náš bundle spustit. Export-Package nám zase definuje balíčky, které dáváme k dispozici jiným bundlům.

Activator třída pak může vypadat například takto.

package com.bcvsolutions.sample.helloservice;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

	public void start(BundleContext context) throws Exception {
		System.out.println("Hello World!!");
	}
	
	public void stop(BundleContext context) throws Exception {
		System.out.println("Goodbye World!!");
	}

}

OSGi kontejner zavolá metodu start při spouštění bundlu. BundleContext je objekt umožnující interakci s frameworkem. Metoda stop je volaná při ukončování bundlu, je vhodné v této metodě provést čistící operace např. odpojení od databáze.

Správa bundlů

Ke správě bundlů v kontejneru nám dobře poslouží OSGi konzole. Můžeme v ní instalovat a odinstalovat bundle, spustit a zastavit bundle nebo si třeba zobrazit všechny bundly dostupné v kontejneru.

osgi> ss
"Framework is launched."


id	State       Bundle
0	ACTIVE      org.eclipse.osgi_3.10.1.v20140909-1633
	            Fragments=603
...
841	RESOLVED    com.bcvsolutions.sample.HelloWorld_1.0.0.qualifier
843	ACTIVE      com.bcvsolutions.sample.HelloService_1.0.0.qualifier

Po vypsání bundlů příkazem ss můžeme vidět dva námi připravené bundly. HelloService je bundle, který exportuje jednu ze svých služeb (viz MANIFEST.MF výše). Zároveň vidíme, že je ve stavu active, což znamená, že je spuštěný v kontejneru. Druhý bundle HelloWorld, který má importovaný balíček z bundlu HelloService, je ve stavu resolved, což značí, že je připraven na spuštění a má vyřešeny veškeré závislosti. Nyní ho můžeme spustit příkazem start.

osgi> start 841
Hello World!!
Inside HelloServiceImple.sayHello()
Say Hello
osgi> stop 841
Goodbye World!!

Vidíme, že balíček byl spuštěn a také, že využívá jedné ze služeb balíčku HelloService. Nakonec jsme bundle zase ukončili příkazem stop.

Životní cyklus bundlu

Životní cyklus OSGi bundlu

Balíček po dobu své funkce projde několika stavy. Po instalaci do frameworku se dostává do stavu installed. Jakmile jsou uspokojeny jeho závislosti přechází do stavu resolved a čeká na spuštění. Při spouštění se dostává do fáze starting, z níž po navrácení metody start přejde do stavu active. Během ukončování je ve stavu stopping a po návratu metody stop se balíček opět navrátí do stavu resolved. Po odinstalaci balíčku se dostává do stavu uninstalled.

Závěr

V tomto příspěvku jsme si ukázali základní práci s OSGi bundly, exportování a importování jednotlivých modulů a základ správy osgi bundlů pomocí konzole.
V případě dotazů mě neváhejte kontaktovat na info@bcvsolutions.eu.