Let's consider the following:

  1. Linux is the platform I am referencing here
  2. There exists a partition on the system that's encrypted with a strong password (via the LUKS mechanism, if it's relevant to you)
  3. This partition contains sensitive information that I wish to isolate from the rest of the system

Assuming all of the above, how can I (as the administrator of the system) enforce a rule that systematically denies read access of the contents of that encrypted partition to all the processes currently running on the system (including those that are started from me as well) except for a select few (like the file manager to access the contents of the partition). Obviously this pertains to the time periods when the partition is mounted and unlocked on the system so any process can read from it at that point.

Basically, what I'm asking for is a way to isolate a mounted device from the rest of the system by choosing only the processes that may read from it and denying access to any other program that's not part from that list.

I believe either SELinux or AppArmor should (in theory) be capable of doing that but I'm not exactly sure how to configure them.

Also, I'm still not sure if this question is appropriate to be here or on superuser.

  • How strong does this security boundary have to be? Because a malicious program could always do things like launch one of the allowed programs under a debugger, and remote-control it that way, which would let it access the restricted partition... AFAIK, there is no way at all to actually guarantee the protection you want aside from using different users for the allowed programs and the not-allowed programs (and even then, root can bypass that, of course).
    – CBHacking
    Feb 20, 2018 at 20:16
  • That's quite an interesting scenario. To be fair I didn't see this hole in my model at all. I don't even know how that could be fixed aside from what you just mentioned about different users
    – Alex
    Feb 20, 2018 at 20:25
  • Yep, Linux (like most OSes) uses a primarily user-based authorization system. Integrity-based security systems (like AppArmor) let you reduce the damage a compromised app can do to your system, by restricting what an app is allowed to do (for example, prohibit launching other apps, or at least have them inherit the parent's restrictions), but to do this you'd basically need to treat every app as "untrusted" or "low integrity", which isn't really what the system is for. It might be possible, though; I don't know AppArmor (or SELinux) that well.
    – CBHacking
    Feb 20, 2018 at 20:33
  • Actually, if using AppArmor can restrict a process from starting others then, just maybe, this could in theory work. However, this would probably require explicitly listing all the programs that I wish to be restricted, instead of specifying the ones that should be allowed. This might be problematic considering that there might be tens or even hundreds of possible programs on a linux installation to be accounted for.
    – Alex
    Feb 20, 2018 at 20:55
  • I'll wait a little longer, either way, to see if more detailed answers about AppArmor or SELinux arise that could give further insight. If there won't be more answers, I'll close this issue and do the separate user setup.
    – Alex
    Feb 20, 2018 at 20:56

1 Answer 1


For isolating access to a mountpoint so only particular programs can access it, you can use MAC or DAC. When using DAC, you must provide a way to automatically run your target program as a group.

Mandatory Access Controls

A Mandatory Access Control system, or MAC, is a framework for limiting what actions a given subject (e.g. a process or thread group) can use to operate on an object (e.g. a file, directory, or network interface). The access controls are usually enforced by the kernel, and the process being confined has no say over what objects it is allowed to access and how. For your use-case, you would need to use SELinux rather than AppArmor. AppArmor requires an explicit profile for every single program it is confining. A new program will not be confined at all. There are ways around this involving setting a profile for the init process, causing it to be inherited by all other processes on the system, but it is a hacky and untested technique. SELinux on the other hand is specifically designed for system-wide isolation policies, though per-process targeted policies are also supported.

You can specify a particular SELinux context for a given mountpoint by specifying the context= option when mounting, either using fstab(5) or by directly invoking mount(8). The context is used to determine what SELinux permissions are required to access it, without needing to label every file.

Discretionary Access Controls

Discretionary Access Controls, or DAC, are the standard UNIX permissions that govern all filesystem access on a Linux system. It is called discretionary because a user who owns a given file or directory can, at his discretion, change its permissions. In order to use DAC to protect a mountpoint so only specific programs can read and write to it, you would want the mountpoint to be mode 0770, owned by the root user and a new group which you create. Any process running under this group will be able to enter, read, write, and execute anything on the mountpoint. There are a few ways to accomplish this:

  • Mark your program setgid, which will cause it to automatically run as the group the executable possesses. Any transition to a setgid context will cause the system to discard all potentially dangerous environmental variables, and will protect the process from invasive debuggers.
  • Configure your sudoers to allow you to run your approved programs as a given group, either with or without supplying a password. This works similarly to the former option, but uses sudo.

A much safer but more invasive technique would be to create an entire different user, with its own desktop environment (if you use any), and its own home directory. When you need to access anything sensitive, ensure the sensitive files and directories are readable only by root and your new, safe user. This may break your workflow as you will have to log into a different user, but it will not be subject to the (non-negligible) caveats with application isolation which are explained below.


It is extremely important that you fully understand the implications of given a particular process access to sensitive information. Unless the program is designed specifically to remain secure under these circumstances, there could be unforeseen ways to hijack it. A graphical file manager, for example, cannot be isolated under Linux, as it will have access to your X11 cookie, and thus any other graphical program with X11 access running under the same user (even if the group is different) will be able to take screenshots, inject mouse movements and keystrokes, and more. This of course would defeat the isolation attempts. All other issues will be specific to the individual programs. Attempting process isolation without conforming to a particular formal policy such as Biba or Bell-LaPadula can be risky.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .