Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am searching for an encrypted filesystem for Linux that can be mounted in a write-only mode, by that I mean you should be able to mount it without supplying a password, yet still be able to write/append files, but neither should you be able to read the files you have written nor read the files already on the filesystem. Access to the files should only be given when the filesystem is mounted via the password. The purpose of this is to write log files or similar data that is only written, but never modified, without having the files themselves be exposed. File permissions don't help here as I want the data to be inaccessible even when the system is fully compromised.

Does such a thing exist on Linux? Or if not, what would be the best alternative to create encrypted log files?

My current workaround consists of simply piping the data through gpg --encrypt, which works, but is very cumbersome, as you can't easily get access to the filesystem as a whole, you have to pipe each file through gpg --decrypt manually.

share|improve this question
3  
I believe you can do what you want via syslog. That separates the generation of the log messages from the system that stores them, so the apps that generate the message have no access to the where they're stored. The logs can even be (and frequently are) on a separate server. –  mpez0 Apr 21 '10 at 13:10
    
I want to go a step further and have the data not be accessible at all, not just to the process that created it, but not even to root. This is what public key encryption with gpg does, but I am searching for a way to do it at the file system level. –  Grumbel Apr 21 '10 at 15:47

3 Answers 3

It sounds to me like you're going in the wrong direction. If you want a file which you can write to, but not read, then file permissions is what you're looking for.


$ touch log
$ chmod 222 log
$ echo test > log
$ cat log
cat: log: Permission denied

Of course, this file can be on an encrypted filesystem.

share|improve this answer
    
This still allows overwriting existing data. –  mpez0 Apr 21 '10 at 13:12
    
That won't help, as I am searching for a way that makes it impossible to access the data without the passphrase, permissions can simply be changed back with another chmod. –  Grumbel Apr 21 '10 at 15:42
    
You can mount the filesystem with a given umask, not allowing users to change the permissions. –  nos Apr 22 '10 at 10:49
    
And only the owner of the file (or superuser) can change the permission. –  gorilla Apr 22 '10 at 23:45
umask 0477 && touch file && echo test > file && cat file

can be useful too. Any file created within current process will have 0200 mode.

share|improve this answer

...I want the data to be inaccessible even when the system is fully compromised.

This is not possible. If the system is fully compromised then "by definition" anything on it is accessible - including encryption keys.

Encryption is useless in protecting against system compromise, while the system is running, IF the keys to encrypt/decrypt data are on the same system with the encrypted data. For example, if you have a LUKS filesystem mounted, and someone gains root access to your system, it's possible to pull the keys from RAM - because they have to live in RAM to decrypt the filesystem. In your situation, if you are typing your passphrase every time you encrypt a file, you are protected (assuming a keylogger is not present on your system), if not, you are in the same situation and someone who compromises your system can find that key and undo all your encryption.

You need to ship the data you want to protect outside of the system + NOT write it to an intermediary medium on that system if you absolutely do not want root to get to it. rsyslog explicitly supports this with regard to logging, and you can encrypt the connection between source and sink with OpenVPN, stunnel, or similar. I'm sure there's other "one-way" transfer options out there.

share|improve this answer
2  
with respect to encryption keys, if he only keeps the public key on the system, then the concept of 'writable but not readable' is at least in theory achievable. The problem is that in the event of a full compromise, the attacker could change the operations! So shipping the data off system is definitely the right approach. –  Michael Kohne Mar 28 '12 at 11:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.