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.

  • 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

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

  • 1
    Please read en.wikipedia.org/wiki/Public-key_cryptography – rakslice May 25 '17 at 20:14
  • "because they have to live in RAM to decrypt the filesystem" this may be true with LUKS specifically, but not in general: asymmetric crypto is designed for exactly that purpose (someone holding the public key can encrypt, but not decrypt) – Clément Oct 13 '18 at 20:43

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.

  • 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
  • I think OP is trying to protect himself even against an attacker getting root. – Clément Oct 13 '18 at 20:41
umask 0477 && touch file && echo test > file && cat file

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


Completely possible. I implemented something similar but not at the filesystem level.

For anyone interested here is how.

  1. Public/Private Keypair is generated on another secure computer.
  2. Only copy the public key to the computer that may be stolen.
  3. When writing just encrypt against the public key.
  4. If stolen, the private key isn't on the device.
  5. When you are ready to read back, copy data off the device back to something secure and then use the private key to decrypt it there.

Warning: If you decrypt on the sensitive device and just delete the private key, you risk that being recovered. So better to decrypt on a different device to ensure the private keys bits are never on the device.

Bonus points if the device has thousands of public keys all randomly named and you tell it which to use upon boot. Assuming all saved data doesn't save which key went with it you can now plausibly deny the ability to decrypt by simply acknowledging the wrong public key may have been picked by you or someone else.

I use such a system for a dash cam in a sports car. I wanted it to protect me in case I get hit or robbed. But not to incriminate me if I perhaps was driving sporty and have footage of that waiting if I were to wreck.

Basically it makes the witness only my friend and not my enemy.

  1. You hit me or rob me. I decrypt the correct key and show up with evidence on video.

  2. I crash into something and the cops snag the camera, I will pretend I cannot decrypt it. Won't have the key, etc. Witness stays silent.

This way someone could take a camera into a bad environment, take photo evidence, and if captured the enemy won't be able to determine what the photos were.

Enjoy this knowledge :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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