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?
dzervas
  • 332
  • 2
  • 11

1 Answers1

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](http://seclists.org/oss-sec/2017/q1/25) 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 04 '18 at 03:11
  • @forest wasn't aware of the above vulnerabilities, thanks for your feedback –  Mar 04 '18 at 07:47
  • @forest what do you suggest then? creating my own kernel module (boy oh boy...) – dzervas Mar 07 '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. –  Mar 07 '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 08 '18 at 05:21
  • @dzervas You don't need to write kernel code to protect a process. You can use a MAC like SELinux. – forest Mar 08 '18 at 05:22