Allow access to a directory for certain application only

Question

I would like to restrict an access to a directory. For example, on my system there is ~/.thunderbird directory that contains settings, letters, caches, etc of Thunderbird mail client. Obviously, other applications doesn't need the content of this folder. And other applications should not access the folder not because of security but just because of safety (for instance, "crazy" behavior of some other application caused by a bug or an error in my shell script should not affect the content of Thunderbird's directory).

---

I cannot use setuid bit on Thunderbird's executable (e.g. /usr/bin/thunderbird). Because after setuid bit is set I will not access usual files created by Thunderbird (for example, downloaded attachments).

There is a workaround with setgid bit on Thunderbird's executable (downloaded attachments will has thunderbird group while the owner will be me). But this way is not secure (because the owner will be me, so I can accidentally delete something from ~/.thunderbird).

Anyway, approach with setuid/setgid is unreliable and fragile (for example, after Thunderbird is removed and installed again the bits will be not present on the new instance of /usr/bin/thunderbird executable).

---

chroot is not a solution because Thunderbird requires access not only to its home directory by to shared libraries as well.

---

I've also looked into AppArmor. Yes, I can set up restrictions on Thunderbird. But it seems impossible to write rule that denies an access to ~/.thunderbird for all executables except /usr/bin/thunderbird.

---

Perhaps, the goal can be achieved via SELinux. But it's too complex to me for now. And it's superfluous: may be there is a simpler way.

---

Could you please help me and point to tool (or kernel module) that can allow an access to a directory for a certain application and deny an access for all the rest applications?

---

PS My distro is LinuxMint 17.1 32bit.

Answer 1

For this have you considered using a containerization solution like Docker to have an isolated version of Thunderbird?

There's some existing examples like this one.

Docker solves the problem of shared libraries that you identified in the chroot section of your question by bundling up all the dependencies within the container, and you could restrict permissions to directories that are mounted into the container.

One caveat to this approach is that you should ensure that the other users on the system that you don't want to read the data are not able to run docker commands (so don't add them to the docker group if you use it) as they could then get access to the data.

Answer 2

What you think obvious is not for me:

Obviously, other applications don't need the content of this folder. And other applications should not access the folder not because of security but just because of safety.

Well what about the backup application? Should not it be able to backup that folder? You explicitely do not want it to be restored after a crash? Another example, a friend of mine had his thunderbird mailbox apparently empty after a power outage. I could got the content as a plain file, and read and rebuild it with a Python script. Why should not the Python executable and the file manager access that folder?

What is obvious for me, is that an application I do not trust should never lie in the file system where I store my data, and should never be able to access it: I reverse the problem and isolate applications I want to test in a dedicated virtual machine (even if I do know that it is still far from a silver bullet, I accept the remaining risk level). And I never forget that what is the more dangerous for the computer and the data is what lies between the keyboard and the chair... So I stick to the usual security rules and have regular backups, an antivirus on my windows box, I never run ordinary tasks under an administrator account, disable all unnecessary daemons or services...

Answer 3

I'm not sure how palatable the following is, but it is a solution to what you ask, and I have been using for about 3-4 years now. Initial setup is painful but once setup it works fine. Note that using this method I figure I am immune to pretty much anything that is not a privilege escalation type of attack -- especially, the run of the mill browser based attacks, media-file based attacks, and even any ransomware (if they start targeting Linux) etc.

To start with, I have 3 users: u0, u1, and u2. (Actual names are different; using these for ease of explanation).

u2's pubkey is in u0's ~/.ssh/authorized_keys file. "ssh u0 " from u2 works without prompting for anything. I leave the keychain/ssh-agent setup as an exercise for the reader :)

u2 is where all the real stuff is -- all the files, etc., for example. Only thunderbird runs here, but does not have access to the internet (set proxy to something non-existant, like 127.0.0.22:2222 or something random like that). Browsers are similarly locked down -- mainly to prevent me from forgetting and running something in this userid. All media players are also disabled using dummy programs placed earlier in $PATH.

When thunderbird opens a file, make it go through a program which on my system is called "xo-deleg" (short for "delegate xdg-open"). This is painful to setup -- for each file type/mime type, you have to make TB choose to run this script. If you forget, you end up running it locally -- I have not found a way to automate this, but I am sure there is some setting in TB that might help.

This program "scp"s the file to /tmp/xo under the user "u0", then fires off a script called "xo-run" (i.e., runs "ssh u0 xo-run").

xo-run is a bit complicated. I'm not sure if SO takes code properly but I will try, hoping this works like markdown:

#!/bin/bash

# runs on 'u0' only

exec >>/tmp/xo.$USER.log
exec 2>&1

( (

    export DISPLAY=:0.0
    cd /tmp/xo

    file=`ls -Atc | head -1`
    xdg-open    "/tmp/xo/$file"
    sleep 1h
    /bin/rm -vf "/tmp/xo/$file"

) & )

As you can see, the file gets invoked with the appropriate desktop app, in the user u0. It also gets deleted after 1 hour. The double fork trick, with the "&" after the first fork, ensures that the parent (running under user "u2", remember, which fired off "ssh u0 xo-run"?) does not wait.

Any time I need to actually save a file that came in via email, I have to manually do so. I.e., in u2 userid, run "scp u0:/tmp/xo/FILENAME ."

There's a heck of a lot more to my setup (I haven't explained what user "u1" is doing, for instance, nor have I mentioned that I actually run two x servers (one on tty1 and one on tty2), and I haven't even touched on browser security and media security, which are all part of this complicated game), but for your purposes, this should be sufficient.

Please note even if this sounds painful, that's only a one-time pain. Actual use is pretty much indistinguishable from a vanilla setup except for saving files permanently.