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?
Improve this question
5
  • 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? Commented Mar 3, 2018 at 16:39
  • Rather than messing with LD_PRELOAD library, why not use FUSE API? Commented Mar 4, 2018 at 9:14
  • How can i handle it per process? Commented Mar 4, 2018 at 9:16
  • @dzervas: you can get the uid, gid, and pid of the process doing a FUSE operation using fuse_get_context(). Commented Mar 4, 2018 at 9:32
  • so every folder (e.g. .mozilla) will be a fuse mount? Commented Mar 4, 2018 at 9:33

1 Answer 1

Reset to default
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
Improve this answer
6
  • 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. Commented Mar 4, 2018 at 3:11
  • @forest wasn't aware of the above vulnerabilities, thanks for your feedback Commented Mar 4, 2018 at 7:47
  • @forest what do you suggest then? creating my own kernel module (boy oh boy...) Commented Mar 7, 2018 at 19:26
  • @dzervas Looking over the vulnerabilities of firejail, they all seem to be privilege escalations and non-exploitable from within the container. Commented Mar 7, 2018 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. Commented Mar 8, 2018 at 5:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.