Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jan 2009 00:30:17 +0100
From:      Roland Smith <>
To:        Marco <>
Subject:   Re: Runtime de/encryption
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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) t=
o use
> > passwords.
> Changing the syscall's is also an interesting idea.=20

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.=20

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.

[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v2.0.10 (FreeBSD)



Want to link to this message? Use this URL: <>