Deniable file storage

[torne]

I am currently designing the next implementation of my server's security system (based on grsec). I intend to use encrypted homedirs for my users already, but alone they do not provide sufficient security for my purposes: my goal is to make my system immune to legal attacks as well as technical ones. Ultimately, I want it to be 'impossible' for me, as root and the GRSec administrator, to access the files of my users. (for the highest value of impossible I can find).

I have several problems, some unlikely to be solved by grsec but I'm asking anyway in case somebody knows, and some that I think grsec should be able to cope with, either in its current incarnation or the forthcoming 2.0 version.

First: the 'normal' way of setting up encrypted homedirs seems to be to use either the user's login password or a hash of it as as a key (or prompt for an alternative password at login through pam converse) - the filesystem is then mounted for the duration of the user's sesssion. This is good as it means that I do not know the user's key while the user is not logged on. Will GRSec prevent me (as root or in grsec admin mode) from examining kernel data structures to extract the key from the encryption driver/filesystem driver? If not, how can this be achieved? =)

Second: while the user is logged on, the contents of the encrypted FS can be read by root. I can globally remove CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH but this seems like it'll be a pretty big inconvenience to system administration =). Is it possible to use ACLs (as implemented in 1.9.9 or as they will be in 2.0) to deny anyone but the user in question access to the mounted homedir?

Third: (not grsec related) does anyone know of a way to deliver mail to a user without ever writing it to disk unencrypted on the local machine? The only solution I can think of is to public-key encrypt mail (the entire file, not just the message body as done by PGP) before writing it to disk, as then only the recipient can decrypt their mail spool (and other mail folders will be inside their encrypted homedir). However, this leaves the queue unencrypted - I can use ACLs to avoid the queue being readable but avoiding it being written to disk en clair will require either encrypting the queue FS, or keeping it in a ramfs. The latter will prevent crash recovery (all undelivered messages will be lost) and the former will only allow crash recovery if the key is stored somewhere on disk too (or is always the same), which defeats the point.

All of the above combined would pretty much prevent me from being able to obtain any information about user's data passively, which should be sufficient to avoid a subpoena for keys or data (though IANAL). It doesn't prevent me from being served a 'wiretap' warrant, but that's another issue entirely and would need there to be some reasonably tamper proof way to notify users that the security system has been modified such as invalidating the SSH host key, and I have no idea how that could be achieved - I'm going to leave it as a 'future goal' for now. =)

I realise this is pretty odd and pretty complicated, and that normally you wouldn't want to make yourself unable to monitor your users, but it's the system I'm after. =)

Thanks in advance for any hints whatsoever,

Torne
Resident of the UK and subject to the horrible RIP act. =(

[spender]

I am currently designing the next implementation of my server's security system (based on grsec). I intend to use encrypted homedirs for my users already, but alone they do not provide sufficient security for my purposes: my goal is to make my system immune to legal attacks as well as technical ones. Ultimately, I want it to be 'impossible' for me, as root and the GRSec administrator, to access the files of my users. (for the highest value of impossible I can find).

To do this, you'd have to modify gradm so that the admin password is different than the disable password. You'd then have to throw away the disable password, and modify the admin acl so that it does not have CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH.

logged on. Will GRSec prevent me (as root or in grsec admin mode) from examining kernel data structures to extract the key from the encryption driver/filesystem driver? If not, how can this be achieved? =)

It will prevent you as root from doing that, but not in admin mode (You'd have to modify the admin ACL)

Second: while the user is logged on, the contents of the encrypted FS can be read by root. I can globally remove CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH but this seems like it'll be a pretty big inconvenience to system administration =). Is it possible to use ACLs (as implemented in 1.9.9 or as they will be in 2.0) to deny anyone but the user in question access to the mounted homedir?

Removing CAP_DAC_OVERRIDE actually isn't as big of a deal as you would think. In the debian_secure_acls distributed with gradm, all capabilities are dropped. Only a few programs need this privilege. You would be doing administration in admin mode anyway, and not as root.

-Brad

[torne]

Thanks a lot for the tips. Once I have time to start implementing this, I'm sure I'll come ask further silly questions and maybe even report some progress. =)

One question: when you say I'd have to modify the admin ACL in order to be unable to read the kernel data structures.. in what way would I need to modify it? =)

T.

[spender]

You'd have to remove CAP_SYS_RAWIO, CAP_SYS_MODULE, and hide /dev/mem, /dev/kmem, /dev/port....the same stuff that is enforced in the default ACL.

-Brad

[torne]

*thwap*
stupid me. of course =)

Not a problem since I don't use any of them (I use monolithic kernels, no X..etc) =)

T.