2

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.

Alex
  • 67
  • 3
  • 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 '18 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 '18 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 '18 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 '18 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 '18 at 20:56
  • This seems to be a solution with SELinux: https://security.stackexchange.com/questions/30116/restrict-access-to-a-specific-directory-on-linux/30120#30120. Firejail (https://firejail.wordpress.com/) is also a useful tool, but it would be in reverse of your case (it is a tool to restrict rights of some process) – Patrick Mevzek Feb 20 '18 at 21:33
  • Can't you just rely on Unix users and default rights: if you mount the partition under a director owned by user "special" with read/write/access rights on this directory only to this user, then no application will have access to it, except if it runs as user "special". Or for something similar, using groups. Many subsystems work like this, for example to restrict access to the audio hardware, etc. (all applications need to be in some specific "audio" group). If you can reach your goal that way it will be far simpler and easier to maintain than bigger tools such as SELinux. – Patrick Mevzek Feb 20 '18 at 21:35
  • Yes, it would be easier if I just used Unix users and default rights. Still, this ultimately feels like a workaround to me. Ideally, a user should be someone who is directly mapped on a one-to-one relationship with a human operator on that computer. Dedicating a user just for this type of restricted access feels....roundabout. And also way too specific. Using a group for this feels a bit more intuitive but, again, even if I make that directory group-accessible, I still need to use a separate user from my own. This is why I'm trying to find alternatives. – Alex Feb 20 '18 at 22:02
  • And yes, I do agree that this is how the Unix systems (as well as Windows systems) are designed to enforce security. I just believe that there should be other ways of doing this outside creating separate user accounts just to have them access otherwise restricted sectors. On a different note, I am already using a similar scheme on another computer in which I use dedicated users for this type of access. I find it cumbersome since I have to do TTY switches whenever I try to shift between accessing restricted files and somg like web browsing (since I don't want the browser to read those files) – Alex Feb 20 '18 at 22:07
  • @Alex - I'm not sure I understand: Why is making the directory group-accessible not an option? Why would you still need a separate user? – Out of Band Feb 20 '18 at 23:14
  • @Pascal Using group permissions would work, but then you still have the problem of needing to switch groups (which in practice means switch users) when switching apps. It's cumbersome and likely to fail by accident (open something from an app that you shouldn't have, whoops, it's now got the relevant group) – CBHacking Feb 20 '18 at 23:51
  • But couldn't you play with SUID / SGID bits to make the applications run as the user/group in question, so that you wouldn't have to su manually? I see the "fail by accident" problem, but somehow that failure mode seems inherent in what the OP wants to achieve. If necessary, you could limit the problem by jailing the application (chroot / firejail) so it wouldn't have access to anything outside the sensitive directory. – Out of Band Feb 21 '18 at 00:05
  • FWIW, AppArmor cannot do this by default. In order to do it, a master/root profile must be set up around `init`, otherwise it operates purely on a per-subject (process with profile) basis. It is intended to support it more completely in the future, but for now it is an untested and rather experimental hack. There's no need to delete your question though. A mere day is not always enough to get an answer. I'll try to answer it soon. – forest Feb 21 '18 at 06:37
  • If would be quite challenging to accomplish something like this in Windows 10, but most useful. – Overmind Feb 21 '18 at 07:26
  • @Overmind I believe AppContainer under Windows can do something like this, but I do not know enough about Windows security to say anything more than it should be possible. – forest Feb 21 '18 at 07:27

1 Answers1

0

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.

Caveats

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.

forest
  • 64,616
  • 20
  • 206
  • 257