Slashdot Mirror
Simplified Disk Encryption Coming to GNOME
An anonymous reader writes "David Zeuthen of Red Hat has been working on adding encrypted volume support to HAL. The result is an infrastructure that is being developed to make working with encrypted volumes easier. David has published a screenshot documenting his work on his blog. The bottom line: attach a properly encrypted volume and the system will prompt you for a password and automatically mount it."
TrueCrypt has offered this type of integration in Linux for years.
- Just my $0.02, take with a grain of salt, your mileage may vary.
Won't everyone (ie Government entities) complain that Linux is now a haven for terrorists and pedophilles since only a criminal would want to encrypt their [disk|phone call|email|http connection]?
HAL is not part of a desktop (not really sure why Gnome is mentioned here, other that that the initial user tools for this is Gnome based). It's a Hardware Abstraction Layer around the kernel to support stuff like hotplugging, file monitoring and so on in a nice, hardware-independent manner. It sounds like just about the right level to me. Isn't HAL used in most recent distros by now, no matter what desktop (if any)?
Trust the Computer. The Computer is your friend.
I dont know what you're talking about and I'm thinking it's because you don't either.
How we know is more important than what we know.
From TFA: While LUKS is a standard on-disk format, there is also a reference implementation. LUKS for dm-crypt is implemented in an enhanced version of cryptsetup.
I guess dm-crypt is the right layer for that, done in the kernel by the device mapper. This only will ask you for you key before mounting it.
KDE does something similar, shoehorning in an ssh filesystem that only works in K-apps. There's a userspace sshfs which I'm going to try since I don't use K much, but this is all unnecessary duplication of effort.
But I can't see that GNOME is the essential ingredient here, if it's done in HAL, Gnome just needs a nice GUI to handle a password request.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Excellent! The way the summary/article was worded, it somewhat sounded like it was being added to the GnomeVFS. I'm glad I was wrong. The GnomeVFS was not a bad idea, but getting programs to properly work with it (even many GNOME programs) is impossible. If they don't use the proper APIs, it simply doesn't work.
:-)
I'd forgotten about HAL. It looks like its progress is coming along nicely. This is a step that Linux should have taken a LONG time ago. Oh well, better late than never.
Javascript + Nintendo DSi = DSiCade
These developments will bring file security to many non-technical users, but for the nerds out there there have already been practical solutions for some time.
I've been keeping the hard disk of my Linux encrypted with twofish for over three years now (see the description of this encryption method in Bruce Schneier's magisterial Applied Cryptography ). Swap is encrypted with a random key generated on each boot-up. At first I used the old cryptoloop method, but as soon as the kernel support was there I switched to the crypto device-mapper target. I never noticed any performance penalties: this is a very efficient solution.
KDE does something similar, shoehorning in an ssh filesystem that only works in K-apps. There's a userspace sshfs which I'm going to try since I don't use K much, but this is all unnecessary duplication of effort.
Yes, this disparity between the kernel VFS and the Gnome or KDE or XYZ VFS is very annoying. I was called over to figure out how to save scanned files from a Linux box across to a Windows share. They could browse over to the Windows share just fine in Konq, but when it came time to use a Gnome-based scanner app, there was no such possibility. I had to hunt down a KDE scanning app and install that, which has an exceedingly stupid interface IMO (not that the Gnome that tne was that much better), just so these end-users could save files to a network share.
Why can't these VFS layers make use of the existing VFS, and instead of magically making network shares exist in their little universe, actually mount the share in question using the existing kernel-level tools? Then it's <gasp> magically available to all apps!
GStreamer - The only way to stream!
Install lvm2 (great for managing disk space), dmsetup, cryptsetup. Read this page and follow its instructions.
You can create a block device of any size you want using lvm (so long as there is sufficient disk space of course) and then map that to another block device using the device mapper and the crypt filter. The original block device looks like random bytes and if you get the passphrase wrong the mapped block device still looks like random bytes (i.e. there's no way to confirm a correct passphrase except that the result looks sensible).
Once you have set a passphrase, make a filesystem on the mapped block device. Go ahead and use it any way you like.
It's not an SSH file system. It's an encrypted filesystem. There's a difference.
Vandemar.org
as for the duplication of effort, consider that porting each and every one of those io slave types to each and every supported kde/gnome platform is a huge undertaking. better to let them bake at the DE level and do an invert later on (e.g., kiofs).
further, when you talk about the GNOME folks duplicating effort, well, from the outside, that whole project looks like little more than duplication of effort. kioslaves have been in for how long? 3, 4 years? GNOME has a serious (maybe fatal) case of Not Invented Here, and Linus is right about GNOME's other disease.
i should stop, but i won't. i never use gnome, but for some reason i use a gnome app or two. know how much crap gnome sticks in
after reading your msg again, i realise you might not be dissing kde, but your message set me off anyway. i apologize if you take this as if it's directed against you and not your comments. but just the thought of the man-years wasted on such a lame as software system as GNOME makes me weep for the opportunities squandered in the FLOSS community.
It's just an automounter and passphrase dialog that uses the DM-Crypt (plus LUKS, which is DM-Crypt, but keeps the DM-Crypt configuration in the device's first block rather than /etc)
Because there is no existing VFS as far as desktop apps are concerned--you have to be root to mount things.
Then fix it. Creating multiple wholly-incompatible VFS layers that make it utterly impossible for applications to actually work together is really lame. Whining about lack of features in the more appropriate lower layer is a cop-out IMO. Modern SELinux-derived security methods (not to mention the time-tested standby sudo) should easily be up to the task.
GStreamer - The only way to stream!
The Gnome people and the KDE people have fixed it. They decided that it would be simpler to implement these (often very complex) filesystems in user space, rather than dealing with the complexities and limitations of working in the kernel, not to mention the difficult of persuading the kernel hackers to accept the enormouse amounts of code directly into the kernel. :)
39
Your other comments may apply equally well to KDE.
I'll close with an old classic:
Don't worry, the article title is just a bit misleading. All this really is is hooks being built into HAL (dynamic hardware framework) so that users can mount crypted filesystems with a pretty frontend.
What you're saying is like saying "My OS shouldn't ask me with a GUI bubble what to do with a memory stick. That's part of the filesystem layer. Much lower layer than the GUI."
This isn't using gnomevfs.
And when it comes to building 'secondary' VFSs, there's a good argument for keeping things out of the kernel. It's supposed to be a unix kernel, not a plan9 kernel.
Malike Bamiyi wanted my assistance.
Actually the new thing is the 'flush' mount option that don't wear out flash drives and destroys performance like 'sync' does. Someone at SUSE wrote an experimental 'flush' patch for vfat and it seems possible to do for other file systems too. It will go upstream and some point...
Doesn't look fixed to me when a Gnome app can't save a file somewhere that the users (who don't give a d*mn what Gnome or KDE are) can see just fine in their KDE file browser. In my book that's called a "bug".
GStreamer - The only way to stream!
Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?
fuse = filesystem in userspace = in Linux post 2.6.14 (afair)
Never underestimate the dark side of the Source
If you've actually got proof that there's a backdoor in PGP, then prove it. I think you're full of shit.
Hail Eris, full of mischief...
E pluribus sanguinem
Nobody else at my home uses Linux, and if they tried to do anything other than click on the shortcuts to Firefox or VLC or the random game like America's Army or Unreal Tournament, they wouldn't have any a very good idea of what to do. The same goes for when I'm at school. I know of nobody that uses Linux or knows how to use Linux (save for one persone I met once while at an engineering orientation during the summer,) so I'm pretty sure that if I want anything hidden, I'll store it in a folder labled .DON\'T\ LOOK\ HERE\ BECAUSE\ IT\ IS\ A\ SECRET! and place it in ~/Desktop/
Nothing is being done at that level, RTFA or learn how HAL actually works. The encryption is handled in the kernel by device mapper, and a userspace tool (cryptsetup) activates it. This project is just a front-end to that, so you don't have to run cryptsetup from a terminal yourself. Once it's mounted any normal app can interact with it like any otherpart of the file system, just like HAL-mounted removable disks.
Everyone is born right-handed; only the greatest overcome it
In any case, the story is definitely worth a listen.
If you don't know where you are going, you will wind up somewhere else.
I'm looking forward to use this with NetBSD's CGD.
- Hubert
It's not an SSH file system. It's an encrypted filesystem. There's a difference.
Umm, yeah - the point is doing a filesystem at the most effective layer of abstraction - the VFS or as a userspace filesystem on linux. Doing a filesystem in GNOME (which isn't what this is) would just be silly, from a linux perspective.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The GnomeVFS API may well be difficult to work with (*), but this statement of yours applies to absolutely every API out there.
(*) Actually, most programs rarely need much more than rather small subset of the API, which basically mimics the POSIX file API; hence, your use of the word `impossible' in this context is, at the very least, dubious.
$ find /etc/ | grep gnome | wc -l
573
And what the hell does that prove?
The GnomeVFS API may well be difficult to work with (*), but this statement of yours applies to absolutely every API out there.
Ummm... no. In this case there is a lowest level virtual file system that can be modified to make ALL programs compatible. With GnomeVFS, RealPlayer fails, Acrobat fails, KOffice fails, OpenOffice fails, etc. because the GnomeVFS API is a structure that duplicates officially provided functionality. Ergo, it's not that good of a design.
Javascript + Nintendo DSi = DSiCade
I'm going to try to correct you as gently as I can (So unlike Slashdot, I know). But it's done this way to make it compatible. The crypto is at the level it is so it is FS agnostic (I'm using it now on top of LVM and underneath ReiserFS).
/usr, etc) but that's something the distro maintainers will have to tackle since you will either need to be present when the system boots (to type in the key) or have it grab the key from an unencrypted location accessible to the system (Some people use remote servers, some us USB drives, whatever).
In other words, it's at the block level, not the FS level. It creates no problems for anything using the "standard" Linux APIs because unless they're working on the block level, they won't even know it's there.
The user is not locked out of the data unless the user forgets the password while mounting the device/file/partition/LV. Once it's mounted, the key is retained in the kernel and life goes on. It can present problems in using it for system-level filesystems (/home,
This is perfect for removable drives (USB, FireWire, etc).
... And so it comes to this.
I'm currently using cryptsetup-LUKS / DM Mapper with AES-256 encryption and a 16-digit random key committed to memory. I'm just using it for a data partition currently, but if some of the rumors I'm hearing are true, I should be able to go system-wide on my distro of choice soon enough.
I do see a system penalty using the crypto setup (Server is single AMD-1800+ 1GB RAM) in that copying a large file will peg the CPU and drive the load average way up for about two seconds every four to five seconds, but thus far it hasn't been more than a 10-15% speed hit over-all (Compared to an unencrypted block device) and the server is able to withstand it for days on end without a hiccup.
... And so it comes to this.
Does it support encrypted swap space?
http://outcampaign.org/
You can use cryptsetup-luks to encrypt your swap space, yes. It requires modification to your startup scripts (Specifically the section where it mounts your swap space), and generating a random key each boot (If you so choose), but it's quite doable.
... And so it comes to this.
What is the "officially provided" and commonly agreed upon way to access a sftp:// URL? One that will interact with the ssh-agent, and look into my keychain for keys, of course. What about fonts:///? What is the standard way of opening a resource located by an http URL? cp(1) seems not to grok
It may be related, I guess, to the fact that open(3) for some reason does not like SMB mounts.You're hanging out with the wrong crowd, pal! ;-)
What would be cooler is a nice GUI to create encrypted volumes
What people really need is Steganography
ext3 syncs by default every 5 seconds- if you're using ext3 this could be your problem.
:-)
You can change the settings for how often it flushes and also the criteria e.g. flush when buffers are 20% dirty.
This was in bdflush in Linux 2.4- I'm not sure where it is now in 2.6. Google will have it somewhere though
http://blog.grcm.net/
I don't really like the Gnome vs. KDE wars - both camps seem to be gaining from the existence of the other. However I was a little surprised the other day to find:
/etc/gconf/ /etc/gconf/1 /etc/gconf/2 /etc/gconf/gconf.xml.mandatory /etc/gconf/schemas /etc/gconf/gconf.xml.defaults /etc/gconf/
$ du -h
4.0K
4.0K
0
921K
9.7M
11M
Which I traced to the fact that I installed gthumb.
Why on Earth does a set of defaults need nearly 10M?
Carpe Daemon
The summary and headline are misleading. HAL is a desktop independant technology and is also used heavily KDE in 3.4, and will likely be even more so in KDE 4.0.
This is a not a GNOME-centric development.
What is the "officially provided" and commonly agreed upon way to access a sftp:// URL?
Duh. Just call a "mountsftp" mounter to access the FS. There's an SSHFS implementation here that does pretty much the same thing.
Javascript + Nintendo DSi = DSiCade
Pray tell, how exactly does this work in Solaris, BSD, OS X, Windows? What? It doesn't?
Gnome-vfs may be less than optimal in many respects but at least it's not Linux-only.
Interesting. In addition to the factors you mention, maybe people are more afraid of losing access to their data than of someone else gaining access to it. Forgetting passwords is the obvious risk, but I'd imagine that it's also significantly trickier to recover data from an encrypted filesystem if and when something breaks.
That's possible. When I was doing unencrypted testing, I was using ext3 and it was a steady stream. My encrypted block device is formatted with ReiserFS 3.6 but it may have similar settings.
... And so it comes to this.
File based crpto is the wrong place to apply, or the wrong level of the stack. In the below discussion, "I" means "black-hat crypto cracker".
Metadata leakage, including filenames. This generally tells me the files I need to attack. I don't need mymod.ko, but earnings.sxc would be interesting.
Generally, file-based approaches only encrypt the file data. BAD, because EVEN if the filenames themselves are encrypted, and allocation maps are encrypted, it is still possible to do entropy analysis on the drive. What appears random is data!
If you use a crypto system that uses the same key to encrypt blocks, with the same results, this is bad. I can again GUESS the plaintext, by guessing the file system, and the common layout information (allocation tables). This can provide a lot of information.
What we want is to encrypt at the block level, and to spew random numbers ALL OVER the drive before using it, and to use a crypto implementation that gives reasonable results (block number as part of the key).
Please keep your data safe!
Just another "Cubible(sic) Joe" 2 17 3061
I was in the front row at Phil Zimmerman's presentation at Defcon several years ago. Somebody in the audience asked whether he had ever been asked to insert a backdoor into PGP, and whether he had done so. Zimmerman immediately became irate, apparently taking the question as a personal attack. He said that thousands of people depend on the security of PGP, including dissident groups and people fighting for human rights throughout the world. People who would be, you know, executed if certain things were discovered. The idea that he might, for any amount of money or in exchange for anything else, insert a backdoor into PGP was morally repugnant to him, and he stormed off the stage at the end of the presentation in disgust.
Nevermind the fact that any back door in PGP would involve changes to the mathematics which would be noticed and questioned almost immediately by thousands of people.
Yes, the GP poster is full of shit.
The gconf configuration contains a lot of strings that applications use for help text and dialog boxes where options are displayed. Usually they are packaged with _every_ translation included. So the files can be huge if they have 100 copies of every string. Plus it's XML so it's wordy.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The GNOME in the title of the article refers to the GUI component for interacting with the HAL file system encryption component. They're just making a GUI to interact with the system-level encryption.
So, assuming we get all the necessary HAL bindings in place, how much work would it be to implement similar functionality under KDE? I must admit what I saw in that screencast was most impressive from a usability point of view.
/? Obviously /boot must be in plaintext, but would it be possible to have the kernel ask for a password (obviously at command prompt) before loading the rest?
Secondly, I'm not very familiar with LUKS/dm-crypt. Would it be possible using this setup to encrypt
Third, I'm partial to having containers because they can more easily be backed up and moved around as opposed to block devices, for example a DVD sized container. Could this be adapted to work the same when opening an encrypted file as opposed to accessing an encrypted device? Ask for pw then mount itself. I've seen solutions for this but nothing *easy*.
Fourth, regarding the keyring. I saw he disconnected the USB drive then reattached it and it remembered password. Is it possible to a) force removal from keyring (dismount good, hotkey better) b) have keyring be automatically removed on inactivity c) have keyring removed on locking screen. Naturally, most of these would not be nice to the apps with files currently open on the device, but that's secondary.
Live today, because you never know what tomorrow brings