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