2

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.

flaz14
  • 121
  • 4
  • Is it okay if root can still access all files? – anon May 24 '17 at 15:29
  • 1
    this question might be better suited in the Unix & Linux section. – ron May 24 '17 at 15:31
  • 1
    Yes, it's OK if *root* can access the files (e.g. *root* will access via Bash, Vim or whatever). But other users should have access to `~/.thunderbird` only via Thunderbird, but not via file manager, text editors, etc. – flaz14 May 24 '17 at 15:32
  • It might be a little too "creative", but did you consider creating different accounts for different tasks? Like creating a user that can only write mails using Thunderbird, etc. ? – anon May 24 '17 at 15:42
  • Unfortunately, that approach doesn't work. I can create `thunderbird` user, then set `thunderbird` as owner of `~/.thunderbird` folder (and its conent). Then I can set **setuid** bit on `/usr/bin/thunderbird` executable (otherwise Thunderbird will not access its settings). But after such setup I will not have an access to saved attachments - for example, when you receive a picture attached to e-mail you can save it to local folder (because downloaded attachments will be owned by `thunderbird` user). – flaz14 May 24 '17 at 15:59

3 Answers3

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.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
1

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

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • I mean that only Thunderbird should have an access to its home folder. Other applications (like a Bash, or Python script, MidnigntCommander, etc) can access the folder but only when ran with `sudo` (and execution of `sudo` is confirmed by a password). In case of emergency I always can manage content of `~/.thunderbird` via `sudo` (as for backup I never do this on running system, e.g. I boot from Live-CD and copy the whole partition(s) with aid of `dd` - my system partition is about 20GB and home partition is about 25GB). – flaz14 May 25 '17 at 06:52
  • But the advice about application isolation is really good! Seems that isolation approach is more clean and consistent. Running an application in virtual machine will help (at least there is no need to pollute the system with additional configuration - all Thunderbird stuff will located in its VM). Or as [@Rоry McCune](https://security.stackexchange.com/a/160303/107997) said Docker can help. But I afraid that desktop notifications, system tray icon will not appear on my desktop while Thunderbird is ran in a sandbox. So I will look for the appropriate sandbox. Thank you! – flaz14 May 25 '17 at 06:59
1

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.