Re: Runtime de/encryption
First, thanks Roland. On-disk encryption is not meant to secure access on a running machine. This is very true. And the reason for my thoughts on that topic. I don't think there is something like that can be easily done. You'd have to alter the semantics of systems calls like open(2) and read(2) to use passwords. Changing the syscall's is also an interesting idea. That however would basicly change the host system in it's inner workings. Now, it would imply some changing of kernel related code base, with decision/distinguish on type of files. And in a case of encrypted file to use the beforehand added open_enc()/close_enc() ... syscall(s). Still this would make it possible to work with normal files, but also apply the functionality of runtime encryption. In difference to an extra layer of fs this possibly would be very unportable on the first thought.Nevertheless, i like the idea. Best regards, Marco Roland Smith wrote: On Fri, Jan 16, 2009 at 02:59:34PM +0100, Marco wrote: Hello List, i'am using the geom framework for quite a time. I'am happy about gbde/geli implementations(beside the race condition in geli) however, i wonder since some time, as the data may get exposed on a running server(as the partitions decrypted) On-disk encryption is not meant to secure access on a running machine. File and directory contents are only decrypted in memory, not on disk when you read them. You should use normal file permissions and possibly ACL's to restrict access to mounted filesystems. There are of course data structures in the kernel that contain decrypted information about the volume. But if an attacker can grab that info from a running kernel you've got bigger problems... is there a way to do some kind of runtime de/encyrption, with keys? so that only special users with the right handle can encrypt or decrypt data? so talking about another filesystem layer... I don't think there is something like that can be easily done. You'd have to alter the semantics of systems calls like open(2) and read(2) to use passwords. Roland ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Runtime de/encryption
On Sun, Jan 18, 2009 at 10:57:38PM +0100, Marco wrote: First, thanks Roland. On-disk encryption is not meant to secure access on a running machine. This is very true. And the reason for my thoughts on that topic. I don't think there is something like that can be easily done. You'd have to alter the semantics of systems calls like open(2) and read(2) to use passwords. Changing the syscall's is also an interesting idea. The point is was trying to make is that it is a _stupid_ idea. One of the strengths of UNIX is that you can use read() on every file, whether it is a regular file, a device or a pipe or a socket. Imagine that you'd have to call different read functions depending on if you're reading a regular file, or a device descriptor etc. That would suck big time. Using separate calls to read from encrypted files would cause just that. That however would basicly change the host system in it's inner workings. Now, it would imply some changing of kernel related code base, with decision/distinguish on type of files. And in a case of encrypted file to use the beforehand added open_enc()/close_enc() ... syscall(s). The _big_ problem is that every application would have to learn to do that is you want them to be able to read these files. It poses the same problem as encrypting individual files with e.g. gnupg or ccrypt. You have to decrypt them before apps can use the data, because most apps don't know how to handle encrypted files. Whatever security you're trying to achieve, I think this is not the way to go about it. There are several other mechanisms in place that are better suited for applying access restrictions to files; permissions, groups, ACLs, MAC. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpL26g8nbbKB.pgp Description: PGP signature
Re: Runtime de/encryption
On Fri, Jan 16, 2009 at 02:59:34PM +0100, Marco wrote: Hello List, i'am using the geom framework for quite a time. I'am happy about gbde/geli implementations(beside the race condition in geli) however, i wonder since some time, as the data may get exposed on a running server(as the partitions decrypted) On-disk encryption is not meant to secure access on a running machine. File and directory contents are only decrypted in memory, not on disk when you read them. You should use normal file permissions and possibly ACL's to restrict access to mounted filesystems. There are of course data structures in the kernel that contain decrypted information about the volume. But if an attacker can grab that info from a running kernel you've got bigger problems... is there a way to do some kind of runtime de/encyrption, with keys? so that only special users with the right handle can encrypt or decrypt data? so talking about another filesystem layer... I don't think there is something like that can be easily done. You'd have to alter the semantics of systems calls like open(2) and read(2) to use passwords. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpQa6d2OJ0Zj.pgp Description: PGP signature
