When you confine user in selinux, when you launch firefox, it runs under context staff_u:staff_r:staff_t. Is that normal? Shouldn’t that transition to .. : .. :mozilla_t? Isn’t staff_t completely unrestrictive for running firefox? It feels like it should drop context to a more restrictive mozilla_t domain.
It looks like this sort of question has come up before on the old selinux mail list:
Does the solution described in the above link solve the problem?
Mostly no because I am getting no denials. Which means there’s no policy to transition out of a confined user domain when launching Firefox.
Right. I think you have to write those policy rules if you want them or find someone else who is willing to help.
I see the following comment in an old bug report about Firefox and SELinux issues:
Mozilla does not do any system integration and SELinux fixes.
I’m not sure how authoritative that statement is, but it makes sense. Apparently Fedora has an SELinux team that works on these sort of things.
If you are nice to them 
, maybe you can get someone to help implement such a policy and then it might even get added as a patch to the Fedora rpm build of firefox so others who enable confined users will be able to benefit from the policy.
Edit: FWIW, this appears to be an example where someone was experiencing a problem with running Firefox confined and managed to get the problem patched:
Yes, we’ll be nice. Because when you ship a product feature that gives internets the sysadm selinux role, and no one noticed till now…
I wonder if Red Hat also has SELinux confined users set up the same way, with Firefox launching from any SELinux role account and keeping those privileges without dropping to its targeted domain?
People have been complaining about browsers having the ability to automatically download and run code for a very long time. It hasn’t gone unnoticed. These are all those people who are constantly complaining about web sites that require JavaScript to function. It definitely has major security implications. There are some security measures built into the web browsers themselves. SELinux is another, newer, idea about how such processes can be locked down, but SELinux is very complex and still under development. Any help you could provide towards those efforts would be great.
2 Likes
Yes to all above.
No. Both staff_u and sysadm_u do decrease the privileges to processes, not increase it. It does NOT mean that anything gets any admin privileges or so: the opposite is the case, the access gets more limited because even sysadm_u means that an additional confinement is imposed, even in areas that usually do not contain this additional security layer (as it in many areas is too restrictive for most users, even sysadm_u, making it a denial of service). You experienced this earlier when you tried to log into a GUI with sysadm_u: by default, sysadm_u does not even allow GUI.
There is an old example of Firefox in earlier topics, it actually was one of the reasons to found the confined users SIG: sysadm_u is sufficient to forbid Firefox access to text of another process/file of the same account (in the presented case it was text from a terminal, running with the same sysadm_u as Firefox). The elegant thing is that the SELinux confinement was able to identify when a user triggered the transfer of data into Firefox (copy text from a terminal into firefox), which was allowed, and when Firefox tried to access itself the very same data afterwards again (and the latter was blocked: SELinux made Firefox crash).
You underestimate the complexity of SELinux (which indeed is one of SELinux’s major disadvantages). When it comes to what sysadm_u, staff_u etc means: this decreases what is possible for a process. And the “sysadm_u” itself is only one of many variables concerning what SELinux allows and what it forbids. Actually, when it comes to what a process like Firefox does, the major difference about allow/restrict-outcomes in practice is imho: is it unconfined (which does not imply disabled: this also protects critical components against Firefox, even if SECCOMP or other means would fail for whatever reason) or has it any confinement (staff,user,sysadm_u). The confinements add an additional security layer, that add security that is comparable to containerization, additional to existing security means (major security means of firefox in Linux is SECCOMP imho - itself extremely powerful). But unlike containerization means, SELinux confinement does not need to “massively open up and weaken its own security means” in order to make the process work in GUIs (at least with current containerization alternatives, that is an issue with containerization). I don’t think that the precise separation between Firefox that accesses data outside its own realm on its own initiative (forbid by any confinement) and a user who wants to copy text from another window into Firefox (allowed by confinements) could be done by any containerization.
That said, I am not sure if SELinux confinement has a future: its capability to work so precise goes along with a high complexity, and I don’t think that we get all maintainers of all packages to the point in which they can prepare the system for all possible user configurations and expectations (e.g., even sysadm_u still breaks video conferences in Firefox as it does not allow Firefox to use the camera, at least in my environment). This is not as critical as it sounds as we already found out that SELinux confinement in accounts is just an additional layer of security, but SELinux confinement can be very preventative (creating strong security margins), and it can (even with sysadm_u) mitigate risks even from malicious software that has been installed: especially if users use third party software that is not trusted, this can be very useful. But so far, there is no good solution for this problem, and users have to either ensure that all software they install can be trusted to use appropriate security means* (and that it comes from trustworthy maintainers and has sufficient review) to the level of data access of its own account, or live with the restrictive experience of confinement. My personal hope on the long term would be a combination of, e.g., containerization means like Flatpak in conjunction with SELinux (or AppArmor?), in a way that mitigates the disadvantages of both and still achieves the advantages of this preventative security even against malicious/untrusted software that cannot be avoided, or that gets captured by an attacker (many people don’t think much about what they install, and even if developers have no bad intentions, much code people install with copy/paste from websites is developed with very bad practices and often not contained in default repos for good reasons). Just some outreach to the challenges of the environment you seem to reach out to 
*On Fedora, maintainers of the major editions (+ KDE Spin) are very careful with what packages they add by default, and afaik everything that comes by default is considered and maintained by a network of known people who know also where the packages are coming from. Once you add additional packages, our repo still ensures a strong testing pipeline and fulfillment of many criteria of each package, but then you start to rely on individual package maintainers to care personally about packages regularly (updates etc) - or you become active and check it out yourself and help maintainers to respond on time for packages you use. But once you add third party software or even third party repos, a lot can happen that is not intended… bad testing, bad development practices, much potential for hidden quick and dirty that would never pass our testing pipeline, etc. 
Yeah, and it allows all sorts of other sysadmin things.
You still don’t state why firefox cannot run in its mozilla_t context. And then add whatever that domain can do into the policy (some of what mozilla_t is allowed to do it already in fedora’s targeted selinux policy).
It’s, like, so easy to add transition to every app that drops its process selinux context to whatever its specific policy is. The user context domain (staff_t) is only needed to be able to do many things in different domains, but the executibles themselves need to be restricted to their own domain. That’s the whole point of selinux targeted policies. You don’t see other system processes with selinux policies run as staff_(u/r/t) or whatever. You see them run in their own domains, which is the correct approach. All confined user’s launched processes must type transition into their respective selinux domains.
No confinement, including sysadm_u, can add any privileges: it adds an additional security layer, it does not remove any. So there are things that work with and without sysadm_u, and there are things that work only without sysadm_u. If sysadm_u allows some things that you consider “admin tasks” and which you do not want to be allowed in a given account, then you have to go one step further and use staff_u or even user_u. In both cases, a lot of restrictions will be added that make work for many users impossible (even usb sticks with files created by others might be no longer accessible in some circumstances), but of course it would add a lot of security. The compromise is one you have to make for yourself.
The firefox folder gets mozilla_home_t. But I do not know about the very decision for the context of the Firefox process and what Zdenek had in mind. That might be on purpose when risks are mitigated by other means beyond this very policy, and I am not sure if mozilla_t is appropriate within a confinement, but you can create a ticket in the bugzilla against the component selinux-policy and suggest to update the Firefox process context to mozilla_t: then the maintainer will review it and if this would make an improvement to existing confinements, it might be implemented.