Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>

2016-01-25 bef zés Kiss Gabor 

On 01/22/2016 06:20 PM, Volarics István wrote:
> A VG szabad helyén csinálsz egy LV-t azt ezt telenyomod
> dd if=/dev/random of=/dev/vg/lv
> és ha végzett letörlöd az LV-t és így amíg új PV-t nem raksz be
> nem is kell foglalkoznod a dologgal.

Na, mivel már sokadszor kerül szóba:
A /dev/random lassú. Onnan kiolvasni sok száz gigát nem hatékony.
Ehelyett választ az ember egy random  kulcsot,
azzal titkosítja a /dev/null-t a teleszemetelendő diszkterületre.

Ld. http://loop-aes.sourceforge.net/loop-AES.README

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>

2016-01-25 bef zés Zs 

Hi!


Na, mivel már sokadszor kerül szóba: A /dev/random lassú. Onnan 
kiolvasni sok száz gigát nem hatékony.

Egyetértünk, ezért is volt az eredeti hozzászólásban /dev/urandom.
Azzal mi a baj?


Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Zs 

Hi!


Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
legalabb az online meretnoveles mukodjon.

Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.

Es egy snapshot is csak a titkositott eszkozt fogja
"lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato?

A snapshot arról a tartalomról készít pillanatképet, ami a snapshot
elkövetésének pillanatában van. Mivel a volume titkosított, minden,
ami az LV-re íródna, előbb átmegy a titkosító eljáráson, ezért a
snapshot csak a titkosított állapotról tud pillanatképet készíteni.
Az egyszavas válasz tehát: igen. :-)

Ezzel együtt az egy jó kérdés, hogy jelszóval olvasható lesz-e
egyáltalán, ugyanis a titkosító modulok is szeretik bejegyezni, hogy
a kötet épp meg van nyitva. Namost a snapshot erősen read only,
kérdés tehát, hogy erre mit lép pl. egy cryptsetup?
Mindezzel együtt ha valamit muszáj, akkor muszáj: az opció lehet,
hogy a snapshotot kimásolod egy külön valós LV kötetre, ott már nem
read only, így ha máshogy nem, akkor így olvasható lesz.


Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Keller Viktor 
Zs  írta (2016. január 22. 0:41):
> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
> öntökönlövés szigorú esetét állítjuk elő!!!

Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
lehetőségének kihagyásán kívül. Azaz, miután rezie$FS $TITKOSKOTET,
csak azután futtatni a dd-t, de a mountolt, titkosított meghajtóba
írni:

dd if=/dev/zero of=$titkoskotet/oriasfile
sync
rm $titkoskotet/oriasfile


Mondjuk lehet, hogy le kell állítani ideiglenesen azokat a
szolgáltatásokat, amik a titkosított lemezt használták, ha nem tudják
kezelni azt a helyzetet, hogy pár tizedmásodpercig --amig a szkript
törli a dd által kreált fált--, nincs szabad helyük.

Ha nagyon amatőr a kérdés, akkor is örülnék válasznak.

Üdv:
Viktor
>
> Üdv
> Zsolt
>
>
> _
> linux lista  -  linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Kiss Gabor 

On 01/22/2016 12:41 AM, Zs wrote:
> Az új terület random adattal feltöltése elhagyható, de security szempontból
> nem szerencsés - elkövetése esetén viszont *nagyon* észnél kell lenni és
> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
> öntökönlövés szigorú esetét állítjuk elő!!!

Biztonságosabb, ha az LV növelése _előtt_ maszatoljuk össze az összes
szabad helyet a diszken, és csak utána engedjük rá a titkosítást.
Akkor nem festhetjük ki az elő filesystemeket.

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Kosa Attila 
On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
> On 01/21/2016 03:28 PM, Kosa Attila wrote:
> > Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> > legalabb az online meretnoveles mukodjon.
> 
> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.

Es egy snapshot is csak a titkositott eszkozt fogja
"lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato?

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Kiss Gabor 

On 01/22/2016 09:56 AM, Kosa Attila wrote:
> On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
>> On 01/21/2016 03:28 PM, Kosa Attila wrote:
>>> Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
>>> legalabb az online meretnoveles mukodjon.
>>
>> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
> 
> Es egy snapshot is csak a titkositott eszkozt fogja
> "lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato?

Blokkokat másol.
Függetlenül a tartalmuktól.
Az LVM csak azt tartja nyilván, hogy melyik blokkba írtál a snapshot
után, az nem érdekli, hogy mit.
A titkosítási réteg efelett van. Azon meg a filesystem.

Összefoglalva: igen, nyugodj meg! :-)

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org> <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Kiss Gabor 

On 01/22/2016 04:53 PM, Keller Viktor wrote:
>>> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
>>> dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
>>> amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
>>
>> -> Known plaintext attack
>> (Ismerem az óriásfile-t, ismerem a titkos leképzését. Minél hosszabb
>> a file, annál könnyebb kitalálni a kulcsot.)
> 
> OK, ezt értem, és jogos (mondjuk miután a listán feldobtam, olyan
> lenne, ha ilyet csinálok, mint pin kódnak az 1234). Akkor vegye a dd
> /dev/zero helyett a véletlenszám generátorról a bemenetét. Akkor is?

Akkor nincs semmi gond. Szokták is.

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Volarics István 



Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés


A VG szabad helyén csinálsz egy LV-t azt ezt telenyomod
dd if=/dev/random of=/dev/vg/lv
és ha végzett letörlöd az LV-t és így amíg új PV-t nem raksz be
nem is kell foglalkoznod a dologgal.
:Voli
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Kosa Attila 
On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
> On 01/21/2016 03:28 PM, Kosa Attila wrote:
> > Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> > legalabb az online meretnoveles mukodjon.
> 
> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
> 
> Tizensok éve a loop-aes a kedvencem, de már kivették a Debianból.
> A dm-cryptnek van kompatibilis üzemmódja, bár nem annyira kényelmes.

Az ecryptfs-t probaltam, de annal nem tudtam novelni a
fajlrendszer meretet online, csak ha "lecsatoltam" a titkositast.

Ugy sejtem, hogy ez normalis ebben az ecryptfs eseten, de azert
megkerdezem: nem jol csinaltam valamit, vagy tenyleg igy mukodik?

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Keller Viktor 
Kiss Gabor  írta (2016. január 22. 12:59):
>
> On 01/22/2016 10:42 AM, Keller Viktor wrote:
>> Zs  írta (2016. január 22. 0:41):
>>> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
>>> öntökönlövés szigorú esetét állítjuk elő!!!
>>
>> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
>> dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
>> amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
>
> -> Known plaintext attack
> (Ismerem az óriásfile-t, ismerem a titkos leképzését. Minél hosszabb
> a file, annál könnyebb kitalálni a kulcsot.)

OK, ezt értem, és jogos (mondjuk miután a listán feldobtam, olyan
lenne, ha ilyet csinálok, mint pin kódnak az 1234). Akkor vegye a dd
/dev/zero helyett a véletlenszám generátorról a bemenetét. Akkor is?
>

Üdv:
Viktor
> g
> _
> linux lista  -  linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org> <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Keller Viktor 
Kiss Gabor  írta (2016. január 22. 18:03):
> Akkor nincs semmi gond. Szokták is.

Mindenkinek köszönöm a válaszokat.

Üdv:
Viktor
>
> g
> _
> linux lista  -  linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-21 bef zés Zs 

Hi!



Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
fajlrendszerre gondoltam. Meg nem kezdtem el nyomozni, hogy
mely megoldasok a legelterjedtebbek mostanaban.

Ubuntu elég régóta felajánlja telepítéskor, hogy a $HOME
könyvtár titkosítható legyen. Utólag is könnyen telepíthető,
a file tartalmat titkosítja és tárolja, igazából a könyvtár
tartalma sem lesz emészthető - értsd: a file nevek is
titkosításra kerülnek. Kódszó: ecryptfs. Nálam Kubuntu 14.04
alatt két éve stabilan gurul, úgy tudom, Debian alá is van.

Megoldás lehet a cryptsetup is, bár amiatt, hogy ez már nem
filerendszert titkosít, hanem egy teljes kötetet, az utólagos
beüzemelése nem feltétlen, egyszerű - cserébe viszont olyan
fs tehető rá, amilyet akarunk.

Mindkét esetben az indulásnál lehet probléma, mert ha a jelszó
be van égetve a csatoló scriptbe, akkor az nagyjából a "kulcs a
lábtörlő alatt" típusú betörésvédelemnek felel meg, ha meg a
script nem tudja automatikusan elővenni, akkor nincs automatikus
reboot, be kell lépni a csatoláshoz. ... illetve lehet olyat csinálni,
hogy egy script segítségével máshonnan vevődik elő a jelszó,
de...

Nekem a lenyeg az lenne, hogy Debianon minel kevesebb
barkacsolassal mukodokepes legyen,

... de ez már barkácsolás.


Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-21 bef zés Kiss Gabor 

On 01/21/2016 03:28 PM, Kosa Attila wrote:
> Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> legalabb az online meretnoveles mukodjon.

Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.

Tizensok éve a loop-aes a kedvencem, de már kivették a Debianból.
A dm-cryptnek van kompatibilis üzemmódja, bár nem annyira kényelmes.

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-21 bef zés Szládovics Péter 

2016-01-21 14:40 keltezéssel, Kosa Attila írta:

Hello!
Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
fajlrendszerre gondoltam. Meg nem kezdtem el nyomozni, hogy
mely megoldasok a legelterjedtebbek mostanaban.

Nekem a lenyeg az lenne, hogy Debianon minel kevesebb
barkacsolassal mukodokepes legyen, a rendszerindulas folyamataban
a leheto legkevesebb fennakadast okozza, a performanciaban ne
okozzon jelentos visszaesest az alkalmazasa.

Johetnek a tippek, hogy merre erdemes elindulni :)


A rendszerindulást mindenképp meg fogja akasztani, ha nem akarod a 
bankkártyára írni a PIN kódot :)

Én encryptfs-t használok desktopon/notebookon.
Jó ötlet lehet még, ha az érzékeny adat van encryptálva a db-ben eleve 
(csak arra ugye nem lesz(jó) index).
Ilyenkor a visszafejtéshez szükséges kulcs jöhet más forrásból (pl. 
spec. alkalmazásból).

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-21 bef zés Kosa Attila 
On Thu, Jan 21, 2016 at 03:11:00PM +0100, Zs wrote:
> 
> >Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
> >adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
> >esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
> >fajlrendszerre gondoltam. Meg nem kezdtem el nyomozni, hogy
> >mely megoldasok a legelterjedtebbek mostanaban.
> Ubuntu elég régóta felajánlja telepítéskor, hogy a $HOME
> könyvtár titkosítható legyen. Utólag is könnyen telepíthető,

A Debian telepitoje is ajanl ilyet.

> Megoldás lehet a cryptsetup is, bár amiatt, hogy ez már nem
> filerendszert titkosít, hanem egy teljes kötetet, az utólagos
> beüzemelése nem feltétlen, egyszerű - cserébe viszont olyan
> fs tehető rá, amilyet akarunk.

Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
legalabb az online meretnoveles mukodjon.

> Mindkét esetben az indulásnál lehet probléma, mert ha a jelszó
> be van égetve a csatoló scriptbe, akkor az nagyjából a "kulcs a
> lábtörlő alatt" típusú betörésvédelemnek felel meg, ha meg a
> script nem tudja automatikusan elővenni, akkor nincs automatikus
> reboot, be kell lépni a csatoláshoz. ... illetve lehet olyat csinálni,
> hogy egy script segítségével máshonnan vevődik elő a jelszó,
> de...
> >Nekem a lenyeg az lenne, hogy Debianon minel kevesebb
> >barkacsolassal mukodokepes legyen,
> ... de ez már barkácsolás.

Igen, ez az egyik, amit meg nem latok, hogy a rendszer
indulasanak a folyamatat hogyan lehet ugy megcsinalni, hogy ne
kelljen kezzel beavatkozni, de megse legyen titkositas nelkul
tarolva a fajlrendszer titkositasahoz hasznalt jelszo...

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-21 bef zés Szima Gábor 


On Thu, 21 Jan 2016, Kosa Attila wrote:


Nekem a lenyeg az lenne, hogy Debianon minel kevesebb
barkacsolassal mukodokepes legyen, a rendszerindulas folyamataban
a leheto legkevesebb fennakadast okozza, a performanciaban ne
okozzon jelentos visszaesest az alkalmazasa.

Johetnek a tippek, hogy merre erdemes elindulni :)


Luks:

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system



-Sygma
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-21 bef zés Zs 

Hi!


Megoldás lehet a cryptsetup is, bár amiatt, hogy ez már nem
filerendszert titkosít, hanem egy teljes kötetet, az utólagos
beüzemelése nem feltétlen, egyszerű - cserébe viszont olyan
fs tehető rá, amilyet akarunk.

Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
legalabb az online meretnoveles mukodjon.

man cryptsetup
...
  resize 

  Resizes an active mapping .
...
Tehát első kanyarban lvresize -L megnöveli az LVM kötet méretét,
második lépésben dd if=/dev/urandom of=$LVMKOTET bs=1M seek=$MERET
feltölti random adattal az új területet, majd jöhet a cryptsetup resize 
$TITKOSKOTET

parancs. Utolsó lépésként a resize$FS $TITKOSKOTET futtatásával meg kell
növelni magát a filerendszer is és készen is vagyunk.
Az egész on-the-fly elkövethető.
Az új terület random adattal feltöltése elhagyható, de security szempontból
nem szerencsés - elkövetése esetén viszont *nagyon* észnél kell lenni és
precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
öntökönlövés szigorú esetét állítjuk elő!!!

Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux