Wut? Encryptie helemaal niet common in Linux

[Sando]

Niet lachen, maar ik herinner me nog de simpele privacymaatregelen die we thuis namen in DOS: Iedereen had zijn eigen diskette(s). Dat ging nog even door bij de komst van Windows, werd later USB-stick, totdat alles gewoon relaxed op de HD kon.

Documenten kon je beveiligen met een wachtwoord. Sommige FTP clients beveiligden account wachtwoorden met een master password of een eigen key (zoals CuteFTP). Heel slecht dat laatste, maar goed.

Vanaf Windows 2000 was het vrij standaard om al je settings te encrypten met EFS, en al snel gewoon je hele user profile.

Ik gebruikte al langer Linux, maar niet voor privacygevoelige dingen. Eerst om wat te spelen, later thuisservers en mediacomputer, tegenwoordig bijna alles. Ubuntu heeft home encryptie ingebouwd via ecryptfs, dat leek me niet meer dan normaal en ik was tevreden.

Maar nu ik mijn Media Center, NAS en Desktop wil samenvoegen in één lightweight computertje zonder Ubuntu, kom ik er achter dat encryptie helemaal niet common is?

[list]
• Ubuntu: EcryptFS bestaat pas sinds 9.04! Niet dat ik er last van heb, maar het verbaast me dat het zo nieuw is.
• CentOS/SL/RHEL: Geen EcryptFS!
• Fedora: EcryptFS wordt AS WE SPEAK pas geimplementeerd met PAM en login-mount.


Ja, je hebt TrueCrypt, maar dat is over de top paranoide je complete harde schijf zwaar beveiligen. En Alles beveiligen ipv alleen je settings en documenten is not done op een lightweight computer die daardoor waarschijnlijk twee keer zo traag wordt.

Je hebt ook LUKS, komt op het zelfde neer maar dan ingebouwd en een stuk makkelijker, maar nog steeds een performance hog op een lichte computer en telkens een wachtwoord intiepen om alleen maar te booten is zo 20e eeuws.

En bovendien zijn beide oplossingen single-user oplossingen. Als je thuis je HD LUKSt of TrueCrypt, dan moeten alle medegebruikers die sleutels ook hebben. Diskbased encryptie is waarschijnlijk niet bedoeld voor de gezinsdesktopgebruiker.

Daarvoor moet je filesystem-based encryptie hebben als EFS en EcryptFS, maar dergelijke oplossingen zijn dus helemaal niet zo logisch als ik altijd aannam binnen Linux.

Tot overmaat van ramp zijn master-password achtige oplossingen zoals je ziet in bijvoorbeeld de Opera browser - om privacygevoelige informatie toch privé te houden op een niet-privé hardeschijf - blijkbaar out of the question. Kijk maar naar Filezilla of Pidgin. Plaintext wachtwoorden, en developers die al jaren weigeren dit te implementeren.

Waarom is dit?
Worden er echt zo weinig desktops uitgerust met Linux?
Gebruiken alle vaders met een gezin alleen maar Ubuntu als distro?
Is privacy raar?
Hoe wordt in de linux community omgegaan met gevoelige informatie in /home?

Ik weet niet hoe het tegenwoordig gaat, maar als ik als kind het wachtwoord van mijn vader of broers wist te bemachtigen, echt wel dat ik daar niet van af kon blijven. En de veiligheid naar buiten het gezin toe is zo sterk als de zwakste schakel.

Ik ben gewoon een beetje verbaast is all.

[McKaamos]

Waarom is dit?
Worden er echt zo weinig desktops uitgerust met Linux?
Gebruiken alle vaders met een gezin alleen maar Ubuntu als distro?
Is privacy raar?
Hoe wordt in de linux community omgegaan met gevoelige informatie in /home?

Ik denk dat het om de hele simpele reden is dat Linux/Unix van zichzelf al veel betere beveiliging op de files heeft dan Windows.
By default kan je als Linux user account niet bij de files van een ander komen tenzij die ander jou expliciet leesrechten geeft.
Daar is verder geen enkele weg omheen, anders dan het weten van het Root password (en dan inloggen of dmv sudo oid jezelf tijdelijk rootrechten te geven).

Alles van de betreffende user staat in z'n home dir, dus daar kom je echt niet bij.
En wat betreft dat laatste comment over een wachtwoord: dat is onder windows, zelfs met EFS, ook een issue. Heb je het wachtwoord, dan kom je in iemand z'n profiel, encryptie of niet.

[DiedX]

Dus je wil een systeem wat toch statisch staat te wezen crypten. Wat was er dan exact mil met LuKS?

[DumbAss]

Dat de developers van FileZilla al jaren weigeren wachtwoorden te encrypten vind ik ook erg raar. Volgens die knakker is dat de taak van het os

[Osiris]

McKaamos schreef op vrijdag 26 augustus 2011 @ 07:49:
[...]


Ik denk dat het om de hele simpele reden is dat Linux/Unix van zichzelf al veel betere beveiliging op de files heeft dan Windows.
By default kan je als Linux user account niet bij de files van een ander komen tenzij die ander jou expliciet leesrechten geeft.
Daar is verder geen enkele weg omheen, anders dan het weten van het Root password (en dan inloggen of dmv sudo oid jezelf tijdelijk rootrechten te geven).

Alles van de betreffende user staat in z'n home dir, dus daar kom je echt niet bij.
En wat betreft dat laatste comment over een wachtwoord: dat is onder windows, zelfs met EFS, ook een issue. Heb je het wachtwoord, dan kom je in iemand z'n profiel, encryptie of niet.

Start de PC op via een Live-CD of prik de hdd in een andere bak et voila, je kunt overal bij? Hoezo "dus daar kom je echt niet bij"?

[McKaamos]

Osiris schreef op vrijdag 26 augustus 2011 @ 07:55:
[...]

Start de PC op via een Live-CD of prik de hdd in een andere bak et voila, je kunt overal bij? Hoezo "dus daar kom je echt niet bij"?

Daar had ik idd niet aan gedacht... beetje blunder idd.
Buiten dat, klopt het verder wel. Of heb ik nog meer over het hoofd gezien?

[Verwijderd]

De beveiliging van een *nix bak is afgestemd op zijn normale leefomgeving, nl. ergens in een serverroom waar alleen de beheerder er fysiek toegang tot heeft, waarbij de gebruikers er via andere machines/terminals gebruik van maken.

Het is pas 'recent' (jaren 90 ofzo) dat het ook op desktops gebruikt wordt met meerdere gebruikers. Dat geneuzel met lokale files encrypten voor verschillende users is iets wat je ook alleen maar in een thuissituatie gaat doen imo. (voor kritieke bedrijfsinfo zoek je b.v. een hardware oplossing die de hele schijf beveiligd).

[Osiris]

McKaamos schreef op vrijdag 26 augustus 2011 @ 08:02:
[...]

Daar had ik idd niet aan gedacht... beetje blunder idd.
Buiten dat, klopt het verder wel. Of heb ik nog meer over het hoofd gezien?

Afhankelijk hoe veilig de beheerder de boot-manager ingesteld heeft. Indien die niet beveiligd is heb je sowieso zonder problemen root-rechten

Verwijderd schreef op vrijdag 26 augustus 2011 @ 08:03:
Het is pas 'recent' (jaren 90 ofzo) dat het ook op desktops gebruikt wordt met meerdere gebruikers. Dat geneuzel met lokale files encrypten voor verschillende users is iets wat je ook alleen maar in een thuissituatie gaat doen imo. (voor kritieke bedrijfsinfo zoek je b.v. een hardware oplossing die de hele schijf beveiligd).

Ik zie zelfs niet echt in waarom je zoiets juist in een thuissituatie zou willen gebruiken. Zolang je de boot-manager beveiligd hebt en je verder je huisgenoten er op vertrouwt dat ze geen live-CD gaan gebruiken (BIOS beveiligen en de HDD als 1e of enige boot-keus instellen kan altijd nog natuurlijk) of de PC open gaan schroeven om bij jouw porno (of wat dan ook) te komen, dan is er toch ook niets aan de hand?

[ Voor 51% gewijzigd door Osiris op 26-08-2011 08:12 ]

[Sissors]

Ik weet niet hoe het tegenwoordig gaat, maar als ik als kind het wachtwoord van mijn vader of broers wist te bemachtigen, echt wel dat ik daar niet van af kon blijven. En de veiligheid naar buiten het gezin toe is zo sterk als de zwakste schakel.

Misschien kwam dat dan ook juist omdat het beveiligd was, oftewel het mocht eigenlijk niet dus wilde je wel kijken wat er dan opstond.

Zoveel bijzonders staat er toch niet op een computer van mij dat ik het verborgen wil houden voor familie, en als je zoiets hebt is het redelijk triviaal om te doen zonder jouw gedeelte te encrypten. Sowieso de vraag is wat er gebeurd ALS je het wachtwoord bemachtigd maar WANNEER. In zon thuis situatie komen kinderen er toch wel achter.

Zoals je waarschijnlijk hieruit wel begrijpt, is bij mijn m'n computer niet echt beveiligd. Sowieso niet geencrypt, en er is een hele zooi mensen die mijn wachtwoord van mijn laptop kent (is wel zo makkelijk bij projecten).

Zelf vind ik encrypten van bestanden nogal paranoide, als je familie zover gaan om met een liveCD op te starten om bestanden van iemand anders te kopieren lukt het ze ook wel om je wachtwoord af te kijken.

[ Voor 9% gewijzigd door Sissors op 26-08-2011 08:21 ]

[Verwijderd]

Osiris schreef op vrijdag 26 augustus 2011 @ 08:10:
en je verder je huisgenoten er op vertrouwt

Daar zit net het probleem denk ik. In een bedrijfssituatie hoor je de beheerder te kunnen vertrouwen, maar is dat in een thuissituatie ook zo? Vertrouwen de kinderen de ouders dat ze niet in hun MSN logs gaan snuffelen? Vertrouwt de vader de moeder dat ze niet in zijn browsehistory gaat zoeken naar pr0n sites? Geen geheimen voor elkaar klinkt leuk, maar dat is niet hoe de gemiddelde familie in elkaar zit, vermoed ik. Sowieso zal er op een thuis-PC meer privacy gevoelige info staan dan op een bedrijfs-PC.

[Sissors]

inprivate browsing voor je pr0n (of het equivalent bij je favoriete browser), msn logs uitschakelen of specifieke achteraf verwijderen.

Sowieso bij MSN logs, papa zal toch administrator zijn, hoe weten die kinderen dat hij niet simpelweg een logger op de achtergrond heeft draaien die alsnog al hun msn gesprekken opslaat?

[Verwijderd]

Tsja, hoe weten de kinderen dat papa niet stiekem een gat in de muur gemaakt heeft om ze te bespieden tijdens het omkleden? Ik bedoel maar...

Ik gok dat als in een gemiddeld gezin een vader/moeder binnenstormt in de kamer van puberdochter/zoon wel een GODVERDEGODVER BUITEN EN KUN JE NIET KLOPPEN naar het hoofd geslingerd krijgt. Zorgen voor een beetje privacy is normaal in de meeste gezinnen dus er is gewoon een vraag naar producten dit dat uitbreiden naar wat je doet op de familie-PC. In de Windows wereld wordt daar wat sneller op ingespeeld, in de *nix wereld gaan ze er wat meer nuchter mee om ("leuk, maar is omzeilbaar dus maar liever niet").

[Osiris]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 08:20:
[...]

Geen geheimen voor elkaar klinkt leuk, maar dat is niet hoe de gemiddelde familie in elkaar zit, vermoed ik.

Dan werkt 't encrypten van 't een en ander vast niet mee aan een gezonde relatie

Kijk, dat je kids eventueel een beveiligd gedeelte wensen snap ik. Pubers. "Spannende zaken waar ouders niets mee te maken hebben hihihihi." Dat soort dingen. Maar als mijn vrouw per se een beveiligd gedeelte wil hebben, dan ga ik toch wel vraagtekens bij d'r stellen ben ik bang.

[ Voor 31% gewijzigd door Osiris op 26-08-2011 08:33 ]

[Sissors]

Verwijderd schreef op vrijdag 26 augustus 2011 @ 08:30:
Tsja, hoe weten de kinderen dat papa niet stiekem een gat in de muur gemaakt heeft om ze te bespieden tijdens het omkleden? Ik bedoel maar...

Ik gok dat als in een gemiddeld gezin een vader/moeder binnenstormt in de kamer van puberdochter/zoon wel een GODVERDEGODVER BUITEN EN KUN JE NIET KLOPPEN naar het hoofd geslingerd krijgt. Zorgen voor een beetje privacy is normaal in de meeste gezinnen dus er is gewoon een vraag naar producten dit dat uitbreiden naar wat je doet op de familie-PC. In de Windows wereld wordt daar wat sneller op ingespeeld, in de *nix wereld gaan ze er wat meer nuchter mee om ("leuk, maar is omzeilbaar dus maar liever niet").

Er is een verschil tussen een beetje privacy (aparte accounts) en alles encrypten zodat niet iemand een live-CD erin kan steken om te kijken wat er in jouw documenten staat. Het ene is een deur met slot op je kamer zetten (wat trouwens bij mij vroeger meestal niet gewaardeerd werd als ik mijn deur op slot deed), het andere is je complete kamer in een kluis stoppen zodat niet iemand een gat in de muren kan boren.

[Verwijderd]

Dat soort encryptie is net populair geworden omdat Windows jarenlang niet met aparte accounts werkte (en in het geval van Windows 9x had je accounts, maar die waren niet bepaald apart). Als iedereen in dezelfde kamer leeft ga je vanzelf een kluisje naast je hoofdkussen bewaren.

[Joseph]

De beveiliging van een *nix bak is afgestemd op zijn normale leefomgeving, nl. ergens in een serverroom waar alleen de beheerder er fysiek toegang tot heeft, waarbij de gebruikers er via andere machines/terminals gebruik van maken.

Dit. Kan iemand op Tweakers.net ook even naar het servergebouw lopen, en daar een liveCD in rack 19 van rij 24 stoppen? Nee.

Zoveel bijzonders staat er toch niet op een computer van mij dat ik het verborgen wil houden voor familie, en als je zoiets hebt is het redelijk triviaal om te doen zonder jouw gedeelte te encrypten. Sowieso de vraag is wat er gebeurd ALS je het wachtwoord bemachtigd maar WANNEER. In zon thuis situatie komen kinderen er toch wel achter.

Onder Windows wel, ja. Keyloggers met noob-proof instructions all over the web. Onder Linux heb je eerst het root password nodig, mocht je er een Daemon van willen maken. Anders werkt het alleen onder jouw account.

> Met een Live-CD het root password aanpassen, en klaar

BIOS Wachtwoord

We gaan in dit topic richting paranoia heen, maar ik vind dat eigenlijk best kloppen. Op het internet moet je paranoia zijn. Er was op de Universiteit een professor die vloekend over de gangen liep. Hij had het perfect beveiligde systeem gemaakt! Maar hij kwam er zelf niet meer in. 100% Veilig bestaat niet. 99,9% hoogstens, maar niet eens 99,99999>% procent.

En als je echt veilig wilt zijn, dan zet je je bestanden offline neer? Een externe HDD, of een andere computer zonder internetverbinding. En dan uiteraard wel in een ruimte waar de kinderen niet bijkunnen, anders krijg je de LiveCD issue weer.

[Gomez12]

Osiris schreef op vrijdag 26 augustus 2011 @ 08:32:
[...]
Maar als mijn vrouw per se een beveiligd gedeelte wil hebben, dan ga ik toch wel vraagtekens bij d'r stellen ben ik bang.

Tja, daarom ben ik over het algemeen ook zo blij dat ik installaties standaard al met user-scheidingen doe en ik standaard niet onder root werk.

Dan heb je gewoon al standaard je privacy en hoef je niet meer achterdochtig te worden als iemand om wat privacy vraagt...

[Sissors]

Onder Windows wel, ja. Keyloggers met noob-proof instructions all over the web. Onder Linux heb je eerst het root password nodig, mocht je er een Daemon van willen maken. Anders werkt het alleen onder jouw account.

En wat heeft papa? Inderdaad root toegang, er moet toch iemand zijn met root toegang.

Trouwens moet zeggen dat ik mijn ernstige twijfels heb over het aantal keyloggers dat je onder windows 7 zonder admin rights kan draaien en die bij andere users werken.

[Jouke74]

Ik heb een tijdje getwijfeld over het gebruiken van encryptie op mijn laptop. Het punt is dat ik bijna overal een vaag antwoord krijg wanneer ik vraag wat er gaat gebeuren met de data recovery als mijn harde schijf het een keer begeeft. Als dan je truecrypt volume het begeeft met een paar gigabyte aan data er in, dan ben je toch meer de klos, dan als de data recovery tools een x aantal files niet uit kunnen lezen. Dus heb ik er maar de gewoonte op nagehouden om de privacy gevoelige data met een lang wachtwoord te zippen / rarren. Dat geeft net dat beetje bescherming.

[eamelink]

Jouke74 schreef op vrijdag 26 augustus 2011 @ 15:04:
Ik heb een tijdje getwijfeld over het gebruiken van encryptie op mijn laptop. Het punt is dat ik bijna overal een vaag antwoord krijg wanneer ik vraag wat er gaat gebeuren met de data recovery als mijn harde schijf het een keer begeeft. Als dan je truecrypt volume het begeeft met een paar gigabyte aan data er in, dan ben je toch meer de klos, dan als de data recovery tools een x aantal files niet uit kunnen lezen. Dus heb ik er maar de gewoonte op nagehouden om de privacy gevoelige data met een lang wachtwoord te zippen / rarren. Dat geeft net dat beetje bescherming.

Dus je backupstrategie is vertrouwen op datarecovery van een gecrashte schijf

[Gomez12]

Jouke74 schreef op vrijdag 26 augustus 2011 @ 15:04:
Ik heb een tijdje getwijfeld over het gebruiken van encryptie op mijn laptop. Het punt is dat ik bijna overal een vaag antwoord krijg wanneer ik vraag wat er gaat gebeuren met de data recovery als mijn harde schijf het een keer begeeft. Als dan je truecrypt volume het begeeft met een paar gigabyte aan data er in, dan ben je toch meer de klos, dan als de data recovery tools een x aantal files niet uit kunnen lezen. Dus heb ik er maar de gewoonte op nagehouden om de privacy gevoelige data met een lang wachtwoord te zippen / rarren. Dat geeft net dat beetje bescherming.

Oftewel als je schijf crashed heb je niet 1 truecrypt volume wat onleesbaar, maar 1 zip/rar bestand wat onleesbaar is (of hanteer je 100'en zip/rar bestandjes met verschillende wachtwoorden, zip-wachtwoorden zijn namelijk niet echt moeilijk te kraken)

[TMDC]

Alle Debian-derivatieven die ik tot nu toe heb gebruikt bieden me heel vriendelijk aan om de homedir te encrypten tijdens de installatie... Iig al sinds *buntu 5.04.

[Tp21]

het is al sinds een aantal versies van Fedora mogelijk om full disk encryption aan te zetten. Alleen de home directory encrypten kan nog niet, en heeft ook zo zijn nadelen

[Remco]

McKaamos schreef op vrijdag 26 augustus 2011 @ 07:49:
[...]
Ik denk dat het om de hele simpele reden is dat Linux/Unix van zichzelf al veel betere beveiliging op de files heeft dan Windows.
By default kan je als Linux user account niet bij de files van een ander komen tenzij die ander jou expliciet leesrechten geeft.
Daar is verder geen enkele weg omheen, anders dan het weten van het Root password (en dan inloggen of dmv sudo oid jezelf tijdelijk rootrechten te geven).

Dus jij beweert dat een standaard user in Windows gewoon bij de documenten kan in de documentenfolder van een andere Windows user ?
De beveiliging in Windows is op bestandsniveau (uiteraard wel NTFS) volgens mij op hetzelfde niveau als in Linux.

[Gomez12]

Remco schreef op vrijdag 26 augustus 2011 @ 18:54:
[...]

Dus jij beweert dat een standaard user in Windows gewoon bij de documenten kan in de documentenfolder van een andere Windows user ?
De beveiliging in Windows is op bestandsniveau (uiteraard wel NTFS) volgens mij op hetzelfde niveau als in Linux.

Tegenwoordig wel, maar windows heeft nog wat draken als win98 / winxp op fat etc in de bedrijvensectoren draaien. Bedrijven zijn berucht vanwege het principe if it works don't fix it. Al betekent dit dat er ergens in een hoekje al 13 jaar een pc'tje staat te draaien wat de hele infrastructuur ophoud (want je moet toch bw compatible blijven, dat pc'tje moet blijven draaien)

En een heleboel fanboys hebben vaak ook een heel beperkt geheugen, dat is gevuld met win 3.1 kennis en meer past er blijkbaar niet bij en die verouderde kennis moet er blijkbaar echt uitgeslagen worden voordat ze het kwijt zijn

[hostname]

Sando schreef op vrijdag 26 augustus 2011 @ 07:23:
Je hebt ook LUKS, komt op het zelfde neer maar dan ingebouwd en een stuk makkelijker, maar nog steeds een performance hog op een lichte computer en telkens een wachtwoord intiepen om alleen maar te booten is zo 20e eeuws.

Uh, hoe wil je anders encryptie doen? Je moet ergens een keer een key ingeven om de bestanden te unlocken.
Overigens kan je LUKS ook prima op een partitie doen, dan is het alleen na het inloggen nodig en kan je per-user keys gebruiken.

[Remco]

hostname schreef op vrijdag 26 augustus 2011 @ 20:14:
[...]
Uh, hoe wil je anders encryptie doen? Je moet ergens een keer een key ingeven om de bestanden te unlocken.

Je zou gebruik kunnen maken van een TPM module: Wikipedia: Trusted Platform Module

[Sando]

Interessante discussie. Ik heb er weinig aan toe te voegen. Goeie vraag dus.

TMDC schreef op vrijdag 26 augustus 2011 @ 15:30:
Alle Debian-derivatieven die ik tot nu toe heb gebruikt bieden me heel vriendelijk aan om de homedir te encrypten tijdens de installatie... Iig al sinds *buntu 5.04.

Ik gebruik Ubuntu vanaf 6.10, en die homedir encryption heb ik pas vanaf 9.04 gezien. Debian/*buntu is dan ook de enige.

Tp21 schreef op vrijdag 26 augustus 2011 @ 17:05:
het is al sinds een aantal versies van Fedora mogelijk om full disk encryption aan te zetten. Alleen de home directory encrypten kan nog niet, en heeft ook zo zijn nadelen

Dat is inderdaad LUX, maar dat is wel nogal een enterprise oplossing wat voor een desktop-os nadelig kan zijn.

hostname schreef op vrijdag 26 augustus 2011 @ 20:14:
[...]
Uh, hoe wil je anders encryptie doen? Je moet ergens een keer een key ingeven om de bestanden te unlocken.

Ecryptfs (*Buntu/Debian) doet file-based encryptie. Je key is versleuteld met je user account login wachtwoord en de files worden automatisch decrypted aangeboden via userspace mount (fuse) in jouw account alleen als je inlogt.

[Mr_gadget]

En hoe zit het met de performance van die encryptie? Wilde eerst mijn nas van encryptie voorzien maar dan zou dat ding onwerkbaar traag worden..

[Sando]

Mr_gadget schreef op zaterdag 27 augustus 2011 @ 21:31:
En hoe zit het met de performance van die encryptie? Wilde eerst mijn nas van encryptie voorzien maar dan zou dat ding onwerkbaar traag worden..

Same here, dat is exact éen van de redenen van dit topic. Quote van OP:

Sando schreef op vrijdag 26 augustus 2011 @ 07:23:
(..)
Ja, je hebt TrueCrypt, maar (..) Alles beveiligen ipv alleen je settings en documenten is not done op een lightweight computer die daardoor waarschijnlijk twee keer zo traag wordt.

Je hebt ook LUKS, komt op het zelfde neer maar dan ingebouwd en een stuk makkelijker, maar nog steeds een performance hog op een lichte computer (..)

Daarom is er voor mij geen keus meer: Debian gaat erop (ecryptfs). (Ubuntu kan ook, maar da's imo te unstable voor een servertje) Het liefste had ik CentOS er op, jammer dat die anno 2011 nog niet aan file-based encryption doet.

[ Voor 11% gewijzigd door Sando op 28-08-2011 04:52 ]

[Sando]

Ik hoop dat RedHat snel de nieuwe truukjes van Fedora overneemt. Ik ben nu met Fedora 15 aan het spelen. Sinds 16 is dan eiheiheiheindelijk ecryptfs functioneel.

quote: http://fedoraproject.org/wiki/Releases/15/FeatureList

100% ecryptfs in authconfig Support for ecryptfs in authconfig

Er staat dat het in februari al done was in 15, maar dat is bs, in augustus waren ze nog aan het debuggen.

Zoveel linux, en nog steeds zo weinig keus wegens 1 kleine feature eis.

Desktop/Laptop:
• (U)buntu
• Fedora

Thuisserver:
• Debian

Hopelijk dus snel RHEL/CentOS/SL erbij.

[Oid]

Remco schreef op zaterdag 27 augustus 2011 @ 01:25:
[...]
Je zou gebruik kunnen maken van een TPM module: Wikipedia: Trusted Platform Module

Of als je lui bent, een http://yubico.com/yubikey

[Verwijderd]

Oid schreef op woensdag 28 september 2011 @ 22:10:
[...]


Of als je lui bent, een http://yubico.com/yubikey

Ik gebruik al jaren LUKS. En dan met name full drive encryption. En waarom ook eigenlijk niet? Full drive encryption is kinderlijk eenvoudig om te configureren. Sterker nog bij de meeste GUI installers is het een kwestie van een vinkje zetten. Daarna merk je er niets meer van en het zit ook niet in de weg. De performance is ook nog eens bijna verwaarloosbaar. Ik heb zelf mijn bootloader en kernels op een USB stick staan met keyfiles zodat je ook geen passphrase meer in hoeft te voeren. LUKS is al jaren de standaard binnen Linux distributies en ik zie dit dus ook niet zo gauw veranderen. Met alle respect maar je weet niet waar je het over hebt. Geen enkel OS heeft zoveel encryptie mogelijkheden als Linux (+GNU).

[ Voor 7% gewijzigd door Verwijderd op 29-09-2011 00:07 ]

[Sando]

Verwijderd schreef op donderdag 29 september 2011 @ 00:03:
full drive encryption. En waarom ook eigenlijk niet?

Trage zuinige minicomputers zoals nettops en oude laptops? 10 watt max? De performance is helemaal niet verwaarloosbaar. Misschien op jouw bij idle 150 watt trekkende Intel stoommachine, maar als ik multimedia naar een encrypted schijf op mijn minicomputer kopiëer gaat dat drie koppen thee trager dan naar een niet-encrypted schijf.

De meeste mensen wensen enkele tientallen MB's te encrypten en de rest van de muziek/film/series/roms/games/apps zal ze worst wezen. Waarom deze terabyte onnodig encrypten? Je nettop bloaten?

Ik heb zelf mijn bootloader en kernels op een USB stick staan met keyfiles zodat je ook geen passphrase meer in hoeft te voeren.

Oeh dat is voor desktopgebruikers omslachtig zeg. Vandaar dat Mark Shuttleworth een goede PAM integratie zo heeft lopen pushen, want als het aan 'de rest' ligt blijft Linux een onpenetreerbaar desktoponvriendelijk product.

LUKS is disk-based en telt niet wegens redenen die jij wenst niet te lezen.
File-based encryptie is al 10 jaar de norm, maar niet op linux. OSX heeft al een decennium FileVault ingebakken. Windows heeft al langer dan dat EFS in hun bestandssysteem. En de eerste in de kernel geintegreerde filebased encryptie is pas in 2009 voor het eerst toegepast in Ubuntu, en nu pas in Rawhide Fedora.

Met alle respect maar je weet niet waar je het over hebt.

Jíj weet niet waar je het over hebt.

[Tim]

Sando schreef op donderdag 29 september 2011 @ 02:57:
LUKS is disk-based en telt niet wegens redenen die jij wenst niet te lezen.

Het is ook wel makkelijk om te stellen dat encryptie niet 'common' is als je alles, behalve file-based encryptie, negeert.

Overigens bestaat EncFS ook al minstens sinds 2004, dus echt nieuw is het ook niet, alleen is het op dit moment meer werk dan alleen een vinkje zetten. File-based encryptie is echt iets voor desktops, en de prioriteit op de desktop ligt nu nog ergens anders (hoeveel mensen ken jij die encryptie gebruiken onder Windows?). Bovendien is er op dit moment een workaround door al je belangrijke bestanden in een aparte map te zetten (waarop een encrypted filesystem is gemount).

Over snelheid, tja, dat is inherent en daar gaat ecryptfs ook niet bij helpen. Via had (heeft?) een AES/SHA coprocessor (Padlocker) waardoor encryptie geen probleem meer was (iig qua cpu).

[LauPro]

Als ik bijvoorbeeld een server configureer welke dual wan routert en VPN regelt, dan kies ik daar ook heel bewust om er geen encryptie op te zetten. Het systeem is dan heel eenvoudig met de kernel parameter 'single' van wachtwoord te resetten.

Maarja, dat geldt ook voor alle switches en andere apparatuur die in dat rek hangt (aanpassen VLAN's etc, plaatsen tap-apparatuur). Het hok waar deze apparatuur in staat dient altijd op slot te zijn. Mochten er werkzaamheden moeten plaatsvinden dan graag in overleg met mij. Hier laat ik de klant ook voor tekenen anders kan ik geen garanties geven.

Ik zie er geen meerwaarde in een volledig encrypte router welke door externen aan alle kanten zou kunnen worden getapt en/of aangepast. Mocht ik een keer een calamiteit hebben en de klant heeft onverhoopt het wachwoord aangepast dan moet ik dat kunnen fixen. Men zou hooguit VPN-keys kunnen stelen. Maar deze geven nog niet direct toegang tot services, misschien wat printers.

Voor een laptop, desktop of workstation die ook gestolen zou kunnen worden zie ik een veel grotere waarde om dit te encrypten. Je wil als bedrijf immers niet dat je kostbare data wordt gestolen.

[Thralas]

Sando schreef op donderdag 29 september 2011 @ 02:57:
De meeste mensen wensen enkele tientallen MB's te encrypten en de rest van de muziek/film/series/roms/games/apps zal ze worst wezen. Waarom deze terabyte onnodig encrypten? Je nettop bloaten?

Je gehele multimediacollectie bewaar je dan ook niet op een dmcrypt-partitie, tenzij je daar gegronde redenen voor hebt. In het geval van een enkele serie die je meesleept op je full disk (dm)crypted laptop is het inderdaad vaak collateral damage.

Oeh dat is voor desktopgebruikers omslachtig zeg. Vandaar dat Mark Shuttleworth een goede PAM integratie zo heeft lopen pushen, want als het aan 'de rest' ligt blijft Linux een onpenetreerbaar desktoponvriendelijk product.

Ik vind niet dat je dmcrypt/LUKS en eCryptfs kunt vergelijken - er zijn verschillende use cases voor beide oplossingen en de sterke en zwakke punten lopen sterk uiteen. Inherent aan LUKS is het feit dat je een gehele partitie zult moeten encrypten, in geval van een multiusersysteem is dit mogelijk een probleem - bij het booten zou je bv. een passphrase moeten intikken om de homedirpartitie te unlocken.

LUKS is disk-based en telt niet wegens redenen die jij wenst niet te lezen.

Hoe bedoel je telt niet mee? Waarvoor?

File-based encryptie is al 10 jaar de norm, maar niet op linux.

Je presenteert dit als feit, maar het lijkt me meer een keuze op basis van je use case (zoals ik eerder al opperde).

Als je waarde hecht aan complete versleuteling van een systeem (bijvoorbeeld een laptop) dan is dmcrypt/LUKS toch echt de enige (logische keuze), eCryptfs kan swap en filesystem metadata niet crypten en de performance is beduidend slechter dan dmcrypt (helemaal in 't geval van sparse of vele kleine losse files). Ook in het geval van een server is het soms wenselijk om de confidentialiteit van de data te garanderen; LUKS/dmcrypt is hier eveneens een prima oplossing.

Voor de huis-tuin-en-keukengebruiker met een gedeelde computer biedt eCryptfs weer enkele belangrijke voordelen; Een dmcrypt-crypted homedir is nu eenmaal niet echt praktisch als meerdere gebruikers gebruik maken van een systeem, je moet de partitie al voor de loginmanager unlocken en vervolgens betekent dat dat de data van alle gebruikers leesbaar is. Bovendien is het vaak al voldoende voor iemand als hij z'n (persoonlijke) documenten kan veiligstellen, een eCryptfs-crypted ~/Documents is hier een prima oplossing, en eCryptFS kun je (makkelijker) per-user integreren in bv. een login.

Trouwens, de FAQ van eCryptfs heeft ook een mooie vergelijking van block-level vs. file-level encryption.

[Sando]

LauPro schreef op donderdag 29 september 2011 @ 11:22:
Als ik bijvoorbeeld een server configureer welke dual wan routert en VPN regelt, dan kies ik daar ook heel bewust om er geen encryptie op te zetten.

Nee precies, goed punt. De meeste mensen lezen dit ook vanuit een server-visie. Ik kijk vanuit een desktop-visie.

Mijn lichte HTPC bijvoorbeeld wil ik ook echt niet encrypten. Geen reden voor, vertraagt het systeem wat, schijf niet makkelijk te switchen/recoveren, etc. Maar mijn persoonlijke user's home op de htpc die afentoe dienst doet als desktop kan wel een encryptietje gebruiken. De dief die mijn computer volgende week jat hoeft mijn belastingaangiften en foto's van mijn ex niet te hebben.

Tim schreef op donderdag 29 september 2011 @ 11:07:
[...]
Het is ook wel makkelijk om te stellen dat encryptie niet 'common' is als je alles, behalve file-based encryptie, negeert.

I'm afraid we'll be deviating a bit from standard analysis procedures today.
Yes, but with good reason.
Het klopt wat je zegt, als je de topictitel leest en de rest overslaat. Maar er past niet zoveel tekst in een topictitel, daarom heb ik een en ander in verdere posts uiteengezet.

Overigens bestaat EncFS ook al minstens sinds 2004, dus echt nieuw is het ook niet, alleen is het op dit moment meer werk dan alleen een vinkje zetten.

Ik ken EncFS wel als aparte module. Zit niet in de kernel. Userspace en relatief veel overhead. Niet PAM transparant, en niet gebruikersvriendelijk om op te zetten. Maar eerlijk is eerlijk, ik wist niet dat ie 'al' 7 jaar bestond.

File-based encryptie is echt iets voor desktops, en de prioriteit op de desktop ligt nu nog ergens anders (hoeveel mensen ken jij die encryptie gebruiken onder Windows?).

Inderdaad iets voor desktops, helemaal mee eens. Ook mijn eerder gemaakte punt. Maar ik ben dan ook groot voorstander van het volwassen krijgen van Linux desktop distro's, en soms krijg ik het gevoel dat de meeste linuxgebruikers vinden dat je voor je desktop maar Windows of OSX moeten gebruiken.

En ook ken ik te weinig EFS gebruikende Windows gebruikers. Maar ze komen wel allemaal bij me huilen als hun spul verduisterd is. "En nou moet ik al mijn wachtwoorden veranderen maar ik weet ze niet eens meer want ze staan allemaal in mijn browser opgeslagen.." op een non-EFS schijf.

Bovendien is er op dit moment een workaround door al je belangrijke bestanden in een aparte map te zetten (waarop een encrypted filesystem is gemount).

Dat is exact wat ecryptfs (en encfs) doen. Maar een acceptabele integratie met het systeem bestaat pas als dit transparant ge(un)mount wordt bij het inloggen via PAM, zoals op dit moment alleen in Debian en Ubuntu gebeurt, en bij een volledige update sinds deze zomer ook in Fedora.

Het komt langzaamaan wel goed, ik had alleen niet verwacht dat het anno 2011 nog geen gemeengoed was. De basis was immers al gelegd, en begin 2000 begonnen de Desktopdistro's te komen. Da's rond de zelfde tijd dat Windows volwassen werd. Ubuntu natuurlijk de bekendste maar SUSE was eerder. Bestond al in 1994 maar toen speelde ik nog verstoppertje en Doom dus ik weet eerlijk gezegt niet of toen al de desktop tot de doelgroep hoorde. Later hadden ze wel twee versies, net als Ubuntu later een aparte serverversie kreeg.

-edit/update-

Tegelijk gepost met Thralas, even reageren.

Thralas schreef op donderdag 29 september 2011 @ 14:57:
[...]
Ik vind niet dat je dmcrypt/LUKS en eCryptfs kunt vergelijken - er zijn verschillende use cases voor beide oplossingen en de sterke en zwakke punten lopen sterk uiteen.

In mijn reactie van een minuut geleden de meeste punten al uiteengezet, maar agreed.

Hoe bedoel je telt niet mee? Waarvoor?

Telt niet mee in de discussie over goed inzetbare file-based encryptie voor lichte en langzame desktops/nettops/htpcs/minicomputers. Ik heb al verteld dat er disk-based encryptie bestaat, dat deze goed is voor zijn/haar doeleinden, en dat deze niet relevant is voor de hier besproken desktop encryptie zoals EFS in Windows of FileVault in OSX.

Voor de rest van je reactie, dat is een beetje een deja-vu van wat ik en anderen al hebben aangekaart.

[ Voor 12% gewijzigd door Sando op 29-09-2011 15:06 ]

[Tp21]

Sando schreef op donderdag 29 september 2011 @ 14:58:
[...]

Telt niet mee in de discussie over goed inzetbare file-based encryptie voor lichte en langzame desktops/nettops/htpcs/minicomputers. Ik heb al verteld dat er disk-based encryptie bestaat, dat deze goed is voor zijn/haar doeleinden, en dat deze niet relevant is voor de hier besproken desktop encryptie zoals EFS in Windows of FileVault in OSX.

Voor de rest van je reactie, dat is een beetje een deja-vu van wat ik en anderen al hebben aangekaart.

Apple is met OSX Lion ook overgestapt naar full disk encryption in plaats van file based encryption. Filevault 2 zal dan ook je volledige disk encrypten. Tevens hebben ze het disk unlockscherm erg netjes gemaakt, en bruikbaar gemaakt voor meerdere users (ipv het normale login scherm, heel netjes gedaan allemaal). Tevens gebruiken ze de AES extensies in de processor. waardoor er nauwelijks een performance verschil is met een systeem zonder encryptie.

[ Voor 56% gewijzigd door Tp21 op 29-09-2011 15:35 . Reden: minder quote ]

[Sando]

Maar Apple gebruikers zullen in tegenstelling tot zowel Linux als Windows gebruikers nooit een tool als photorec, testdisk, recuva, undelete of file recovery gebruiken, en nooit op het idee komen eens een schijf uit een kapotte computer aan te sluiten op hun andere Mac. Als dat überhaupt kan met hun special eigen merk schroefjes.

Bij Apple werkt het, of het is kapot. Daar tussenin zit alleen Apple-Care en de verzekering. Dat is de enige uitleg die ik kan bedenken waarom deze stap geen achteruitgang is, enigszins trollend uitgelegd, want waarom zou iemand terug gaan naar disk-based encryptie?

Het is toch zo dat 97% van de consumercomputer vol staat met media en software die niet private is? Waarom dan kiezen voor die extra overhead?

[Gomez12]

Sando schreef op dinsdag 04 oktober 2011 @ 21:34:
Het is toch zo dat 97% van de consumercomputer vol staat met media en software die niet private is? Waarom dan kiezen voor die extra overhead?

Omdat er praktisch geen vraag is naar file-based encryptie.

Mensen willen met bijv een laptop zekerheid hebben dat er niets benaderd kan worden, niet dat enkel map x/y niet benaderd kunnen worden en dat alles wat ernaast opgeslagen is wel te benaderen is.

Ik schat dat in win8 of hooguit in win9 file-based encryptie ook niet meer onderdeel van het OS is.

Voor userscheiding heb je rechten, encryptie is alleen voor als het echt niet meer terug te halen moet zijn (wat in een user-omgeving bijna nooit zo is, moeders vergeet haar wachtwoord en moet toch haar bestandjes / mail hebben).

En die zogenoemde "extra overhead" die is ergens in de buurt van 0% als je serieus met file-based encryptie aan de slag gaat. Dan is uiteraard je swap ook encrypted, je temp-dirs etc. Oftewel alles waar 99% van je schrijf acties plaatsvinden is encrypted. Het is dus geen extra overhead meer met de huidige geheugens en caches etc.

[CAPSLOCK2000]

RedSandro heeft toch wel een punt. Je kan wel idealen hebben over hoe mensen met hun computer om zouden moeten gaan, maar daar trekt de rest van de wereld zich niks van aan. In de zakenwereld kun je nog een beetje veiligheid afdwingen, maar zodra het de productiviteit in de weg zit gooien de meeste bazen het direct het raam uit.

Mensen willen hun computer gewoon aan kunnen zetten en beginnen. Ze willen niet eerst een wachtwoord invoeren voor hun computer boot of voor ze in kunnen loggen. Ze willen pas een wachtwoord invoeren op het moment dat ze gevoelige dat gebruiken. Dat is inderdaad minder veilig dan full-disk-encryptie maar de meeste mensen voelen helemaal geen behoefte om zo'n zware beveiliging te hebben. Hun hele huis wordt beveiligd met stukjes glas ("ramen") die nog geen steen tegenhouden.

Permissies werken niet in thuis-omgevingen waar iedereen effectief root is. Encryptie is het enige waar je dan wat aan hebt. Ook dan is full-disk-encryptie veiliger, maar het is niet practisch (tenzij je iedereen z'n eigen schijf geeft). Dat soort veiligheid is echter niet nodig voor thuisgebruikers.

[CyBeR]

Sando schreef op dinsdag 04 oktober 2011 @ 21:34:
Maar Apple gebruikers zullen in tegenstelling tot zowel Linux als Windows gebruikers nooit een tool als photorec, testdisk, recuva, undelete of file recovery gebruiken, en nooit op het idee komen eens een schijf uit een kapotte computer aan te sluiten op hun andere Mac. Als dat überhaupt kan met hun special eigen merk schroefjes.

Troll je nou of moet ik erop ingaan?

Bij Apple werkt het, of het is kapot. Daar tussenin zit alleen Apple-Care en de verzekering. Dat is de enige uitleg die ik kan bedenken waarom deze stap geen achteruitgang is, enigszins trollend uitgelegd, want waarom zou iemand terug gaan naar disk-based encryptie?

"Terug gaan" naar disk-based? Het is juist vooruitgang. Is eindelijk alles encrypted, in plaats van alleen je homedir.

Het is toch zo dat 97% van de consumercomputer vol staat met media en software die niet private is? Waarom dan kiezen voor die extra overhead?

Omdat het juist minder overhead is.

[Gomez12]

CAPSLOCK2000 schreef op woensdag 05 oktober 2011 @ 12:58:
Permissies werken niet in thuis-omgevingen waar iedereen effectief root is.

Wat MS dus al sinds win98 eruit probeert te krijgen, wat op een linux niet default is, wat op een apple niet default is.

Iedereen effectief root lijkt me nou niet iets om vanuit te gaan.

[MsG]

Ook bij bijvoorbeeld Ubuntu is de gebruiker effectief root. Het account wachtwoord is genoeg om sudo-rechten te krijgen. En aangezien thuisgebruikers niet allemaal hun privé-systeembeheerder hebben, hebben ze allemaal root-rechten na het invullen van hun wachtwoord.

[Gomez12]

MsG schreef op woensdag 05 oktober 2011 @ 14:23:
Ook bij bijvoorbeeld Ubuntu is de gebruiker effectief root. Het account wachtwoord is genoeg om sudo-rechten te krijgen. En aangezien thuisgebruikers niet allemaal hun privé-systeembeheerder hebben, hebben ze allemaal root-rechten na het invullen van hun wachtwoord.

Zal wel eens een virtual appliance van ubuntu gaan downloaden, lijkt mij namelijk extreem raar en compleet contra de linux-werkwijze.

Laatste keer dat ik linux installeerde krijg ik bij install de vraag voor een root-ww en daarna voor het aanmaken van een user. Die kon je gelijk houden waardoor het lijkt alsof je de situatie hebt die jij schetst, maar het werd afgeraden...

[CyBeR]

Gomez12 schreef op woensdag 05 oktober 2011 @ 14:39:
[...]

Zal wel eens een virtual appliance van ubuntu gaan downloaden, lijkt mij namelijk extreem raar en compleet contra de linux-werkwijze.

Ubuntu is een consumentenlinux. Dat werkt inderdaad zoals omschreven.

[Sando]

CyBeR schreef op woensdag 05 oktober 2011 @ 13:28:
[...]
Omdat het juist minder overhead is.

wat zei ik nou

Mijn debian-based smartphone kan niet meer vloeiend een video afspelen als deze encrypted is opgeslagen. Mijn zolder-hobbie-P4m ook niet. En bij zuinige computers die gewoon nieuw zijn, zoals een NAS met DLNA of nettop, zal dit ook een impact hebben. Alles wat onnodig encrypted wordt is overhead. In welke dimensie is 97% meer encryptie minder overhead? Je moet bij LUKS een wachtwoord invullen voor het aanmelden. Bij file-based encryptie (zowel Windows EFS als Linux ecryptFS) gaat dit transparant adhv je login-wachtwoord. Hoe is een extra wachtwoord moeten invullen minder overhead?

CAPSLOCK2000 schreef op woensdag 05 oktober 2011 @ 12:58:
Ze willen niet eerst een wachtwoord invoeren voor hun computer boot of voor ze in kunnen loggen. Ze willen pas een wachtwoord invoeren op het moment dat ze gevoelige dat gebruiken.

Bij efs/ecryptfs hoeft dat dus niet eens. Optioneel kan dat natuurlijk wel. Bij Linux kan je automount uitschakelen en bijvoorbeeld alleen een Private map hebben ipv je hele home (the Fedora way), en bij Windows kan je aangeven dat een certificaat bij elk gebruik om een wachtwoord moet vragen.

MsG schreef op woensdag 05 oktober 2011 @ 14:23:
Ook bij bijvoorbeeld Ubuntu is de gebruiker effectief root.

Nouja, wel iets anders, de eerste gebruiker is effectief root. De nerdpapa van het gezin die de computer installeert, die is root. De accounts van de vrouw en kinderen die hij toevoegt zijn standaard geen root maar kunnen deze rechten krijgen als papa daarop klikt.

[ Voor 0% gewijzigd door CAPSLOCK2000 op 05-10-2011 18:04 ]

[CAPSLOCK2000]

Gomez12 schreef op woensdag 05 oktober 2011 @ 14:16:
[...]

Wat MS dus al sinds win98 eruit probeert te krijgen, wat op een linux niet default is, wat op een apple niet default is.

Iedereen effectief root lijkt me nou niet iets om vanuit te gaan.

Op aandringen van ons nerds probeert MS het er uit te halen, maar consumenten zitten er niet op te wachten. Op een IPAD of mobiele telefoon kun je niet eens met verschillende accounts werken.

Sando schreef op woensdag 05 oktober 2011 @ 17:41:
Nouja, wel iets anders, de eerste gebruiker is effectief root. De nerdpapa van het gezin die de computer installeert, die is root. De accounts van de vrouw en kinderen die hij toevoegt zijn standaard geen root maar kunnen deze rechten krijgen als papa daarop klikt.

En na een paar keer zeuren om spelletjes hebben de kinderen ook root-equivalente-rechten.


Op mijn thuis PC zit geen wachtwoord. Als je hem wil gebruiken kun je het ding gewoon aanzetten en je word automatisch ingelogd. Er start automatisch een browser en je kan op internet en bij m'n media-collectie. Pas als je in mijn documenten map wil, iets in mijn homedir wil schrijven, of m'n password-manager wil openen moet je een wachtwoord invoeren.

[ Voor 45% gewijzigd door CAPSLOCK2000 op 05-10-2011 17:50 ]

[CyBeR]

Sando schreef op woensdag 05 oktober 2011 @ 17:41:
[...]

Not sure if stupid...

Mijn debian-based smartphone kan niet meer vloeiend een video afspelen als deze encrypted is opgeslagen. Mijn zolder-hobbie-P4m ook niet. En bij zuinige computers die gewoon nieuw zijn, zoals een NAS met DLNA of nettop, zal dit ook een impact hebben. Alles wat onnodig encrypted wordt is overhead. In welke dimensie is 97% meer encryptie minder overhead? Je moet bij LUKS een wachtwoord invullen voor het aanmelden. Bij file-based encryptie (zowel Windows EFS als Linux ecryptFS) gaat dit transparant adhv je login-wachtwoord. Hoe is een extra wachtwoord moeten invullen minder overhead?

Omdat je, als je alles encrypt, je dat in de kernel kunt implementeren. Er zit dan geen userspace crypto laag meer tussen je kernel en je applicatie. Dat betekent bijvoorbeeld minder context switches. Laat het overigens duidelijk zijn dat de overhead van de crypto (dwz het encrypten en decrypten) zelf altijd blijft*. Maar voor veel van de encrypted bestanden maakt dat niet uit want die zijn toch in het geheugen gecached.

En daar komt een tweede punt van waarom file-based encryption slecht is: je files zijn dan wel leuk encrypted, maar al het andere niet. Dus als je app werkt met temporary files, komen die terecht op een unencrypted deel van je disk. Waar het te grabbel ligt. Hetzelfde geldt voor virtueel geheugen (in linux bekend als swap.) Daar staat allemaal plaintext info op disk.

Als je de volledige disk encrypt is dat probeem weg.


Overigens, hier moet je juist even nodig naar Apple kijken. Die deden eerst crypto erg onhandig met de originele FileVault. Dat was in essentie gewoon een AES-encrypted sparse disk image van je homedir, beveiligd met je wachtwoord, die gemount werd op het moment dat je inlogde. Erg bleh en niemand gebruikte het eigenlijk.

Filevault 2 echter gooit het over een compleet andere boeg. Dat is full-disk encryption met een tweaked variant van AES (da's belangrijk bij FDE). Het probleem bij FDE is natuurlijk het wachtwoord bij het opstarten. Dat is op een heel simpele manier opgelost: als je FV2 aanzet, wordt ten eerste een aantal security measures aangezet. Zoals dat automatisch inloggen uit gaat en er dus altijd een loginwindow tevoorschijn komt. Met FV2 komt die login window direct na het booten van de machine tevoorschijn in plaats van na het opstarten van het OS. Daar log je in zoals je altijd doet (ziet er ook hetzelfde uit als je gewend bent) en dan start je computer op en ben je klaar. Je hoeft dus niet nog een keer in te loggen.

*) Hoewel dat met AES-NI ook tot vrijwel nul gereduceerd wordt.

[Sando]

CyBeR schreef op woensdag 05 oktober 2011 @ 18:08:
[...]
Omdat je, als je alles encrypt, je dat in de kernel kunt implementeren. (..)

Ik snap je punt. Echter zit ecryptfs zit al in de kernel sinds versie 2.6.19.

(..) als je app werkt met temporary files, komen die terecht op een unencrypted deel van je disk. Waar het te grabbel ligt. Hetzelfde geldt voor virtueel geheugen (in linux bekend als swap.) Daar staat allemaal plaintext info op disk.

Ubuntu encrypt ook standaard je swap-partitie, precies voor de reden die je aankaart. Eigenlijk geen idee hoe, misschien wel LUKS. Via CryptoMapper ofzo. Je hoeft er iig geen wachtwoord voor in te tiepen, zal wel bij iedere boot random gegenereerd worden. Het nadeel is wel dat je niet meer kunt hibernaten.

Maar ik moet ook aankaarten dat bij 8GB geheugen mijn swap ongeveer altijd leeg is. SWAP encrypten is ook zo'n Jack Bauer CTU maatregel, die voor mij persoonlijk niet nodig is. Ik hoef geen kinderpornocollectie te verbergen ofzo, ik wil gewoon dat huisgenoten en niet-CTU dieven niet kinderlijk eenvoudig mijn schijf kunnen aansluiten en kunnen browsen. Om iets waardevols uit je SWAP te halen moet je vijf niveau's van nerderigheid, moeite en Chuck Norrisheid hoger opereren.

Either way, dat laatste is een stukje discussie over voorkeur maar staat los van de kern want Ubuntu beschermt SWAP al wel. Dan nog, 10 GB van je 2 TB encrypten is 'beter voor het millieu' dan 2 TB van je 2 TB encrypten.

Overigens, hier moet je juist even nodig naar Apple kijken. (..)

Klinkt als een nette oplossing. Komt qua gebruikersgemak overeen met de oplossing van Ubuntu, alleen dan heeft de Apple oplossing meer overhead.

Maar serieus, ze hebben hun systeem flink verbeterd, maar vergeleken bij ecryptfs, een prima file-based oplossing, is FileVault 1 als ik dat zo hoor ook wel een lachertje. Wist ik niet. Da's niet echt file based dus, gewoon een container. Een soort gemountte TrueCrypt maar dan anders.

Ik blijf bij mijn punten voor zuinige computers, maar ook op mijn stoommachine van een desktop-Intel wil ik geen disk-based encryptie. Als dat ding kapot is of bezig met whatever, kan ik één van de schijven zo even overprikken naar mijn wat oudere Intel stoommachine om als een luie hond op de bank toch nog even de eerste aflevering van het nieuwe seizoen van Dexter bekijken.

Disk-based en je bent de sjaak.

[bite]

CyBeR schreef op woensdag 05 oktober 2011 @ 18:08:
[...]
Overigens, hier moet je juist even nodig naar Apple kijken. Die deden eerst crypto erg onhandig met de originele FileVault. Dat was in essentie gewoon een AES-encrypted sparse disk image van je homedir, beveiligd met je wachtwoord, die gemount werd op het moment dat je inlogde. Erg bleh en niemand gebruikte het eigenlijk.

Ik heb het wel gebruikt, het principe van een versleutelde homedir vond ik op zich wel een goed idee tot die file onherstelbaar corrupt raakte De ibook had wat hardware problemen en liep wel eens vast, hetgeen wellicht de oorzaak was. Gelukkig maakte ik toen ook al zo nu en dan een backup maar na die ervaring heb ik eigenlijk geen encryptie meer gebruikt behalve op de laptop van mijn werkgever.
Onlangs ubuntu weer eens geinstalleerd, wissel soms wel eens van distributie, en zag er ook de optie voor encryptie maar heb het toch maar weer gelaten. Ik zou het met name een voordeel vinden wanneer de laptop zou worden gestolen zodat men dan gewoon niet bij je prive data kan maar vraag me of het nu echt betrouwbaar is.
Misschien ga ik nog eens een full-backup maken en kijken of het wat is.

[Sando]

Die ubuntu ecryptfs is dus file-based. Encrypted files staan niet in een sparse-file. Er gaan dus evenveel bestanden kapot als er kapot zouden gaan wanneer er géén encryptie wordt gebruikt.

Uiteraard ben je wel alles kwijt als je computer stuk gaat en je je wachtwoord of key niet meer hebt. I know, duh, maar er zijn zoveel topics over..

[CyBeR]

Sando schreef op woensdag 05 oktober 2011 @ 20:51:
[...]

Ik snap je punt. Echter zit ecryptfs zit al in de kernel sinds versie 2.6.19.


[...]

Maar ik moet ook aankaarten dat bij 8GB geheugen mijn swap ongeveer altijd leeg is. SWAP encrypten is ook zo'n Jack Bauer CTU maatregel, die voor mij persoonlijk niet nodig is. Ik hoef geen kinderpornocollectie te verbergen ofzo, ik wil gewoon dat huisgenoten en niet-CTU dieven niet kinderlijk eenvoudig mijn schijf kunnen aansluiten en kunnen browsen. Om iets waardevols uit je SWAP te halen moet je vijf niveau's van nerderigheid, moeite en Chuck Norrisheid hoger opereren.

Tsja, maar die producten worden natuurlijk niet alleen voor jou gemaakt.

Either way, dat laatste is een stukje discussie over voorkeur maar staat los van de kern want Ubuntu beschermt SWAP al wel. Dan nog, 10 GB van je 2 TB encrypten is 'beter voor het millieu' dan 2 TB van je 2 TB encrypten.

Dat valt wel mee hoor. AES is (in tegenstelling tot DES) ontwikkeld om heel goed uitvoerbaar te zijn door general purpose CPUs. (DES was heel goed in hardware te doen, maar dan wel met dedicated hardware.) Moderne CPUs kunnen honderden megabytes per seconde AES en- of decrypten.

Het grote voordeel van álles encrypten is dat je er niet meer over na hoeft te denken. Het gebeurt gewoon, en je kunt dus ook niet vergeten om je gevoelige info te encrypten.

Overgens, mischien is door je swap kijken een Jack Bauer methode, maar door temporary files kijken is vrij simpel hoor.

[...]
Ik blijf bij mijn punten voor zuinige computers, maar ook op mijn stoommachine van een desktop-Intel wil ik geen disk-based encryptie.

Je moet 't ook wel toepassen waar het nut heeft. En dat is op je computer met privéinformatie. Je HTPC valt daar imo niet noodzakelijkerwijs onder.

Als dat ding kapot is of bezig met whatever, kan ik één van de schijven zo even overprikken naar mijn wat oudere Intel stoommachine om als een luie hond op de bank toch nog even de eerste aflevering van het nieuwe seizoen van Dexter bekijken.

Disk-based en je bent de sjaak.

Ik moet bekennen dat ik niet precies wist hoe dat in een FileVault2 omgeving zou gaan, dus ik heb 't maar even geprobeerd middels Target Disk Mode (wat echt briljant is trouwens en je nergens anders terugvindt volgens mij). De computer waarin je de disk prikt herkent gewoon dat 't een encrypted volume is, en vraagt om je wachtwoord. Dat vul je in en daarna werkt 't zoals je verwacht.

bite schreef op vrijdag 07 oktober 2011 @ 13:43:
[...]

Ik heb het wel gebruikt, het principe van een versleutelde homedir vond ik op zich wel een goed idee tot die file onherstelbaar corrupt raakte De ibook had wat hardware problemen en liep wel eens vast, hetgeen wellicht de oorzaak was. Gelukkig maakte ik toen ook al zo nu en dan een backup maar na die ervaring heb ik eigenlijk geen encryptie meer gebruikt behalve op de laptop van mijn werkgever.
Onlangs ubuntu weer eens geinstalleerd, wissel soms wel eens van distributie, en zag er ook de optie voor encryptie maar heb het toch maar weer gelaten. Ik zou het met name een voordeel vinden wanneer de laptop zou worden gestolen zodat men dan gewoon niet bij je prive data kan maar vraag me of het nu echt betrouwbaar is.
Misschien ga ik nog eens een full-backup maken en kijken of het wat is.

FileVault 1 was ook prut. Onder andere om die reden; je homedir werd een DMG gemaakt en als daar iets mis mee was had je een probleem. Een andere was dat 't niet goed werkte met Time Machine.

FileVault 2 doet full-partition encryptie (dwz, het plaatst een container om je partitie heen en díe wordt geencrypt). Dat alles is block-based, dus van corruptie heb je niet snel last. Als een block corrupt raakt, is alleen dát block corrupt. Enige verschil met niet-encrypted partities hier is dat een encrypted block bij corruptie waarschijnlijk compleet onleesbaar wordt, waar een niet-encrypted block potentieel slechts gedeetelijk onleesbaar is. Maar in de meeste gevallen maakt dat niet zo heel veel uit. Die blocks zijn nou ook weer niet zo heel groot.

FileVault 2 is ook heel makkelijk om te zetten van encrypted naar niet-encrypted en terug. Gewoon op een knop drukken en een wachtwoord invoeren. Daarna is 't transparant en kun je tussendoor zelfs rebooten als dat moet.

En als je machine kapot gaat en je moet de data hebben kun je nog steeds gewoon je disk in een andere machine stoppen en je data eraf halen. Alleen je wachtwoord is ervoor nodig.

Ik ben er eigenlijk heel tevreden over.

[ Voor 19% gewijzigd door CyBeR op 08-10-2011 15:26 ]

[Sando]

CyBeR schreef op zaterdag 08 oktober 2011 @ 15:21:
[...]
Ik moet bekennen dat ik niet precies wist hoe dat in een FileVault2 omgeving zou gaan, dus ik heb 't maar even geprobeerd middels Target Disk Mode (wat echt briljant is trouwens en je nergens anders terugvindt volgens mij). De computer waarin je de disk prikt herkent gewoon dat 't een encrypted volume is, en vraagt om je wachtwoord. Dat vul je in en daarna werkt 't zoals je verwacht.

Kijk, dat is pienter. Geef ik toe. Ik weet niet hoe Linux dat met LUKS handle't. Ik weet wel dat als je een ecryptfs-home (Ubuntu) hebt van een eerdere installatie, kan je deze gewoon hergebruiken door het zelfde login-wachtwoord te gebruiken voor de nieuwe gelijknamige user.

Maargoed, over de pienterheid, daar valt dan wel over te zeggen dat het misschien niet eerlijk is om het waardevolste bedrijf ter wereld te vergelijken met 'freeware'.

Goed, Canonical heeft ook geld, maar ecryptfs is niet door Canonical geschreven en bovendien wordt dat geld meer gebruikt om mensen met hersenschade te vragen dingen als Unity te ontwikkelen.

Hoe dan ook, ik zie de voordelen maar ik blijf erbij dat File Based encryptie net zo goed de bom is. Niet voor OSX, want dat draait alleen op sterkere computers. Een plugPC achtige computer bijvoorbeeld zal alleen Linux draaien. Privébackups in die NAS-setup of instellingen voor externe FTP-accounts zal je willen encrypten, maar bij dergelijke hardware heeft dit echt impact op de performance en wil je niet disk-encryption hebben. Extreem voorbeeld misschien, maar mijn nettop, toegegeven al veel te oud, wil ik ook niet onnodig blootstellen. Maar misschien is dat nogal een tweakermentaliteit. 'Omdat het kan', 'Omdat het x% sneller is.' 'Omdat niet-privébestanden dan overal beschikbaar zijn.' 'Omdat je dan bewust om moet gaan met je privégegevens.' Er zijn goede redenen voor.

Je geeft aan o.a. disk-encryptie te prefereren omdat je er dan niet over hoeft na te denken. Prima, das een keus. Past wel bij OSX. En dat bedoel ik niet slecht ofzo.

Maar nog steeds verbaast het me dat generieke in-kernel file-based encryptie voor Linux zo nieuw is. ecryptfs is eigenlijk de enige keus. Ook disk-based, dan is LUKS eigenlijk je enige keus. Anders moet je echt moeite gaan doen iets niet-standaards te implementeren, en dan druis je pas in tegen je eerdere uitspraak dat je er dan niet over hoeft na te denken. Om deze redenen zou ik deze discussie als hij er nog niet was, zo opnieuw 'Wut? Encryptie helemaal niet common in Linux' noemen.

[ Voor 9% gewijzigd door Sando op 07-02-2012 19:58 ]

[Sando]

Even een willekeurige quote van iemand die bekend is met LUKS:

Verwijderd schreef op donderdag 29 september 2011 @ 00:03:
Ik gebruik al jaren LUKS. En dan met name full drive encryption. En waarom ook eigenlijk niet? Full drive encryption is kinderlijk eenvoudig om te configureren. Sterker nog bij de meeste GUI installers is het een kwestie van een vinkje zetten. Daarna merk je er niets meer van en het zit ook niet in de weg. De performance is ook nog eens bijna verwaarloosbaar. Ik heb zelf mijn bootloader en kernels op een USB stick staan met keyfiles zodat je ook geen passphrase meer in hoeft te voeren. LUKS is al jaren de standaard binnen Linux distributies en ik zie dit dus ook niet zo gauw veranderen.

Ik zit nu wat te oriënteren om een partitie te encrypten voor een Windows/Linux dualbootsysteem, en LUKS wordt - in tegenstelling tot EcryptFS - wel (met een 3rd party driver) door Windows ondersteund.

Maar wanneer het om een laptop met SSD gaat is LUKS - net als het eveneens crossplatform TrueCrypt - een slecht idee in combinatie met TRIM en dus SSD's. Met google kan ik wat giswerk en verouderde patches vinden, maar ik vroeg me zo af: Is dit al anders geregeld? Zowel LUKS als SSD's en gebruikers bestaan al enkele jaren.

Ik vermoed van niet. Ik kan er zo snel niets over vinden. Reacties van een half jaar geleden zijn nog in de trand van

quote: chithanh @ forums.gentoo.org

If you want TRIM and encryption, it is probably worth looking at encfs or ecryptfs on top of a filesystem that already supports TRIM.

Hier heeft of had EcryptFS weer een voordeel. Het voordeel van LUKS is de grotere ondersteuning, en hoewel TrueCrypt die ook heeft is het nadeel daarvan dat recent de linux-implementatie nog niet altijd lekker verliep.

Aan de andere kant, NTFS en Ext4 ondersteunen zelf gewoon TRIM. Wordt dat 'tegengehouden' door de LUKS-wrapper van de container?

[ Voor 11% gewijzigd door Sando op 07-02-2012 20:07 ]

[blaataaps]

Sando schreef op dinsdag 07 februari 2012 @ 19:55:

Aan de andere kant, NTFS en Ext4 ondersteunen zelf gewoon TRIM. Wordt dat 'tegengehouden' door de LUKS-wrapper van de container?

Dat lijkt mij wel het idee van een degelijke encryptie-laag, dat je filesystem geen invloed meer heeft op het on-disk geheel.

[Mijzelf]

Wanneer je een hele schijf encrypt, wil je over het algemeen dat je niet kunt zien waar de files staan, en waar de lege ruimte. Daarom begin je ook met de schijf vullen met random data.
Als het geencrypte filesysteem TRIM zou ondersteunen, zouden de lege ruimten gewist worden, en wordt direct duidelijk waar de data zit.

[Sando]

Dus op een SSD toch maar een zo klein mogelijke partitie voor LUKS/TrueCrypt maken waarvan je vermoedt dat deze groot genoeg zal zijn.