Assuming the file-manager is a typical program that firefox spawn's by calling some form of exec on the relevent executable, it is quite resonable within SELinu

Assuming the file-manager is a typical program that firefox spawn's by calling some form of exec on the relevent executable, it is quite resonable within SELinux for that file-manager to run in a different domain [0]. At this point, that file manager becomes part of the user-space security model I was talking about, where it acts as the gate-keeper of access. Using MCS is interesting here. It still the problem that it involves relabeling files as a matter of course, which is generally frowned upon. From a practical perspective, this type of relabeling would turn into effectivly a lock [0.5] on the file, where no other "confined" domain can access it. The plus side of using catagories is that you can run all of the applications in the same (or one of a pre-determined set) of application domains while keeping them isolated [1]. This has the side benifit of avoid the issue of applications loading new policy as they are being installed. [2] My instinct for the problem is to, as your edit suggests, leverage file descriptors. From a non-SELinux perspective, I have never passed file descriptors other than parent -> child, but it appears you can do so with unix sockets [3]. From a policy perspective, there are three sets of permissions that are relevent: 1) Permission to read/write to arbitrary user files. Both firefox and the file manager would need these 2) Permission to open arbitrary user files. Only the file manager would need this; firefox should not have it. 3) Permission to use file descriptors opened by the file manager. Firefox would need this. When I do a policy analysis, I generally assume that having (1) grants full access to the file; however if your security model dependent on it, there is no reason you could not restrict file access by leveraging (2) and (3). The userspace implementation would be more complicated than the policy. For example, in the case of a local webpage, firefox does not want to open just a single file, but also any resource file that that file requires (and files that it links to and those resource files). So, what would need to happen is: 1) Firefox spawns file-manager 2) User selected *.html file from local file system 3) Firefox reads selected file and creates a list of resource files it needs to read 4) Firefox spawns file manager and requests read access to resource files. 5) ??? 6) File manager either grants or denies access to the resource files. The hard part is step 5, which is implemented entirely in userspace. [0] I wouldn't go so far as to say it should run in an unconfined domain, since it should be restricted from, for example, network access. [0.5] Not a very good lock either; SELinux does not handle access revocation very well. [1] This is the approach Android takes. [2] SELinux does have a module system; however there is no mechanism to limit what permissions a module can add. [3] http://man7.org/linux/man-pages/man7/unix.7.html http://man7.org/linux/man-pages/man7/unix.7.html See SCM_RIGHTS