Good morning,
I've been fiddling a bit with cryptoapi and cryptoloop.
I had thought cryptoapi would work straight on a regular filesystem,
but apparently you have to use cryptoloop and therefore a large
cryptofile (*Note: see below)
Never mind that -- it doesn't look unelegant either. And _very_ easy
to get operational.
What I was wondering though.
I can change attributes of files on the crypto filesystem (i.e. 'within'
cryptofile) with 'chattr'. However, when the filesystem is unmounted
and detached, I can just with a few keypresses remove or truncate the
cryptofile, attributes or no attributes.
Ok, removal can be prevented by chattr +i on its parent directory, but
that still doesn't prevent me or anybody else from doing >cryptofile.
The point is that removal or truncation in this case would disregard
settings of individual files within the cryptofile.
Wouldn't it be a nice extra dimension to the security we want, if
removal
or truncation of cryptofile would also fall under the password
restriction.
This is probably too far off for cryptoloop. However, cryptofile is a
'special file', treated specially by losetup and mount. In fact, these
programs are patched to enable us to treat this file specially.
So how about taking that just a little step further.
How about having either losetup or mount making an effort to respect any
possible attributes within the cryptofile. Such that when unmounting or
detaching the cryptofile, umount or losetup will automatically set an
attribute on the cryptofile if one or more files or directories within
cryptofile were found to have that attribute.
Any thoughts?
BJ
(*Note:
I tested losetup on a device, and it accepted the command, but
apparently that corrupts the pt:
$ losetup --encryption aes /dev/crypto /dev/hdc2
$ fdisk -l /dev/hdc2
Disk /dev/hdc2: 255 heads, 63 sectors, 141 cylinders
Units = cylinders of 16065 * 512 bytes
Disk /dev/hdc2 doesn't contain a valid partition table
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
