0

I’m trying to model & implement a transparent file-based per-process encryption solution for linux. I want each process have its own files encrypted. I want to block firefox from reading my gpg private key for example (let’s say my priv key is not encrypted by default)

Currently is as follows:

  1. Hook the syscall wrappers (through a library injected with LD_PRELOAD globally) for file access (open, openat, read, write, creat, close) and check if the path to be access is covered by the encryption (for example ~/.mozilla). if the path is not called, regular function is called.
  2. Ask the key manager (a privileged daemon) for keys through a unix socket
  3. Encrypt (on write/append/create) or decrypt (on read) the data

My questions are:

  1. I’m using recvmsg/sendmsg to find the pid that asked for a key. Can an adversary tamper with it?
  2. I’m using /proc/*something*/exe to find the path of the pid’s executable. is that safe (can a process fake it?)
  3. The key manager gives the same key to processes with the same exec path and uid. is there a better way to model it?
  • 1
    Not saying you haven't considered it, but wouldn't running Firefox as a separate user without read privs on the sensitive dir trees do the trick? – korrigan Mar 3 '18 at 16:39
  • Rather than messing with LD_PRELOAD library, why not use FUSE API? – Lie Ryan Mar 4 '18 at 9:14
  • How can i handle it per process? – dzervas Mar 4 '18 at 9:16
  • @dzervas: you can get the uid, gid, and pid of the process doing a FUSE operation using fuse_get_context(). – Lie Ryan Mar 4 '18 at 9:32
  • so every folder (e.g. .mozilla) will be a fuse mount? – dzervas Mar 4 '18 at 9:33
1
  1. I think what your looking for is isolation, such as Docker for sandboxing.
  2. LD_PRELOAD may work for the crt, but it won't work with direct syscalls, so it may not work for many applications and defeats the whole purpose of your preload.
  3. Keep in mind that modern browsers implement pretty tough sandboxes.
  4. You may want to look into SELinux, which is designed to solve these kinds of problems by giving every file/process/packet a context
  • You probably shouldn't be recommending firejail. It is a cure worse than the disease, being quite insecure and handling its privileged setuid status badly. There were so many vulnerabilities that the researcher gave up looking for them as they just kept coming. These security researchers are raising serious concerns regarding firejail's general design. This is bad. – forest Mar 4 '18 at 3:11
  • @forest wasn't aware of the above vulnerabilities, thanks for your feedback – user169249 Mar 4 '18 at 7:47
  • @forest what do you suggest then? creating my own kernel module (boy oh boy...) – dzervas Mar 7 '18 at 19:26
  • @dzervas Looking over the vulnerabilities of firejail, they all seem to be privilege escalations and non-exploitable from within the container. – user169249 Mar 7 '18 at 19:41
  • @Naim Privesc is among the most severe of vulnerabilities. Protecting one thing (and not very well) while allowing everything else to elevate to root is... not good. – forest Mar 8 '18 at 5:21

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.