Simplified Disk Encryption Coming to GNOME 83
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 (Score:1, Informative)
Re:TrueCrypt (Score:4, Informative)
Re:TrueCrypt (Score:2)
Re:TrueCrypt (Score:1)
I can't find a way to encrypt my firewire backpack drive.
Can you put a read-write DMG on it? This way you can easily divide the partition between unclassified and confidential data.
Re:TrueCrypt (Score:2)
Re:TrueCrypt (Score:2)
Re:TrueCrypt (Score:2)
That's what Filevault sort of does with your home directory.
It operates in a way in a decoupled sort of way, you see.
Re:TrueCrypt (Score:5, Insightful)
The Linux version is also a command-line program (or at least everything I've read on it have indicated as such). Integrating the same features into a nice interface would be a welcomed addition to the Gnome desktop.
Re:TrueCrypt (Score:2)
Re:TrueCrypt (Score:2)
But why should I use it in Linux over the normal device-mapper tools?
Anyone know?
Re:TrueCrypt (Score:2, Insightful)
Re:Wrong level of the Stack (Score:4, Informative)
Re:Wrong level of the Stack (Score:2)
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.
Re:Wrong level of the Stack (Score:1)
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.
Re:Wrong level of the Stack (Score:2)
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.
Re:Wrong level of the Stack (Score:1)
What is the "officially provided" and commonly agreed upon way to access a s ftp:// [ftp] 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.
Re:Wrong level of the Stack (Score:2)
Duh. Just call a "mountsftp" mounter to access the FS. There's an SSHFS implementation here [sourceforge.net] that does pretty much the same thing.
Re:Wrong level of the Stack (Score:2)
Gnome-vfs may be less than optimal in many respects but at least it's not Linux-only.
File Based IS the Wrong Level (Score:2)
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
Re:Wrong level of the Stack (Score:3, Insightful)
Re:Wrong level of the Stack (Score:3, Informative)
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.
Re:Wrong level of the Stack (Score:2)
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.
Re:Wrong level of the Stack (Score:2)
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 Gnom
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:3, Insightful)
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:1)
Re:Wrong level of the Stack (Score:2)
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.
Re:Wrong level of the Stack (Score:2)
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 who
Feeding trolls for fun and profit (Score:2)
39
Your other comments may apply equally well to KDE.
I'll close with an old classic:
Re:Feeding trolls for fun and profit (Score:2)
Why would Mac addicts flame you for choosing KDE?
Feeding troll feeders for fun and profit (Score:1)
573
And what the hell does that prove?
Re:Feeding trolls for fun and profit (Score:2)
Also, fish uses an SSL encryption layer. Your 286 machine does?
For the record, whatever gripes people might have about the UI, KDE is the faster and more stable environment. That much is well-known. The project doesn't deal with stability issues and other bugs by saying "Ehhh... people don't NEED that feature anyway. *CHOP*".
IMHO people don't need Gnome.
Re:Wrong level of the Stack (Score:2)
$ 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?
All the languages are included. (Score:2)
Don't panic! (Score:2)
Re:Wrong level of the Stack (Score:3, Informative)
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
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:3, Informative)
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 forget
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:2)
Poor article title (Score:2)
Disk encryption? (Score:3, Funny)
Re:Disk encryption? (Score:2)
Re:Of course they will. (Score:3)
Re:Of course they will. (Score:2)
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 fightin
Re:Disk encryption? (Score:1)
Re:Disk encryption? (Score:1, Funny)
Governments are one of the largest users of encryption after all.
Re:Disk encryption? (Score:2)
Screw encryption (Score:1)
Re:Disk encryption? (Score:2)
Comment removed (Score:5, Interesting)
Re:For tech-savvy users there's already been solut (Score:2)
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
Re:For tech-savvy users there's already been solut (Score:2)
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
Re:For tech-savvy users there's already been solut (Score:2)
Already in debian (Score:3, Informative)
Install lvm2 (great for managing disk space), dmsetup, cryptsetup. Read this page [riseup.net] 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.
Re:Already in debian (Score:5, Informative)
Re:They're not writing a new file system.. (Score:2, Interesting)
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...
Too confusing for consumers ? (Score:3, Funny)
Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?
Re:Too confusing for consumers ? (Score:1)
I think my information is safe enough without it (Score:1)
Re:I think my information is safe enough without i (Score:5, Interesting)
In any case, the story is definitely worth a listen.
Re:I think my information is safe enough without i (Score:3, Insightful)
Re:I think my information is safe enough without i (Score:1)
Portability? (Score:2)
- Hubert
great news (Score:1)
HAL != Gnome (Score:2)
This is a not a GNOME-centric development.
KDE tools? (Score:2)
Secondly, I'm not very familiar with LUKS/dm-crypt. Would it be possible using this setup to encrypt
Third, I'm partial to havi
Re:KDE tools? (Score:2)