Date: Thu, 3 Jul 1997 17:37:45 +0200 (MET DST) From: Andrzej Bialecki <abial@korin.warman.org.pl> To: "marino.ladavac@siemens.at" <lada@ws6303.gud.siemens.at> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Crypto (MD5,DES) filesystem Message-ID: <Pine.NEB.3.95.970703165602.5851B-100000@korin.warman.org.pl> In-Reply-To: <199707031212.OAA18858@ws6423.gud.siemens.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jul 1997, marino.ladavac@siemens.at wrote:
> > * take the nullfs and modify it, so that in every write it makes an XOR of
> > md5-hashed password with the actual block contents. On every read do the
> > contrary. In other words, to slide in encryption between vnode and nullfs
> > layers.
>
> Hopefully not. You really should use an encryption method that needs more
> than a couple of seconds to break it.
This was just an example. It could be DES instead.
>
> Otherwise, the layering sounds logical.
>
> >
> > * modify the mount_null (let's call it mount_crypto) to get a password
> > from user.
> >
> > Then user could issue the following command (as it is not required to be
> > superuser to do such mounts):
> >
> > mount_crypto -e md5 /home/user/plaintext/locked /home/user/unlocked
> >
>
> And then everyone who has read access to the mounted files gets to see
> them as plaintext. Anyone who happens to be root gets all of the contents
> for free.
Well.... you're right. But.. it (vfs layer???) could ask your password
every time you open the file. As it decrypts only blocks read from disk,
and stores the plaintext in disk buffers, it would require much tweaking
even of SUPERUser to get their contents right.
> This is worse than useless because it conveys a false feeling of security
> unless you consider the implications (then it becomes just plain useless:)
Well, then how you can have secure access to your files placed on
multiuser machine? I'd like to have additional level of protection, so
that even root wouldn't be able to get at my data. Normal way to do it is
to encrypt the data. But I hate the idea of having to deal with thousands
of files, and every one of them needs to be en/decrypted every time I
want to use it, and, besides, leaves the traces of its plaintext contents
on disk. Cryptofs seemed a good idea.
> > and every file in directory 'locked' would be encrypted/decrypted on the
> > fly. The most important being the contents of the disk blocks are always
> > encrypted (no need to write decrypted blocks anywhere).
>
> But just as bad, if not worse.
> >
> > Now, be kind, but what do you think of it?
>
> It does not seem very workable, wouldn't you agree :( Sorry, I don't have
Sigh... So it seems.
So here's another idea: what about the situation where only one (strongly
authenticated) user process sees the encrypted filesystem as plaintext.
E.g. I could have a filesystem image, and the user daemon would "mount"
it only for itself, so that it wouldn't be visible in other filesystem's
space. Hmmm.... and then I'd send it {NFS,SMB,whatnot} queries? :-) (as
the other person mentioned).
Anyway, these ideas came to me while I was reading mount_null(8), and I
liked the idea of stackable vfs layers. Many interesting things could be
done this way, it seems.
Sincerely yours,
---
Andrzej Bialecki FreeBSD: Turning PCs Into Workstations
<abial@warman.org.pl> http://www.freebsd.org
Research and Academic Network in Poland
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.95.970703165602.5851B-100000>