When I run pw-cli ls Client I see all my clients have pipewire.sec.label as unconfined_u:unconfined_r:unconfined_t:s0. It looks like this is a major security vulnerability. What’s the point of SELinux on RH/Fedora if all audio streams are unsecured?
1 Like
Added f40, pipewire, selinux-confined-users
I assume this is because all user processes run SELinux unconfined.
This is way more than just Pipewire.
Have a look at these docs, you can experiment with creating SELinux confined users:
https://fedoraproject.org/wiki/SELinux/ConfinedUsers
Report bugs on bugzilla (see below)
The project is here
1 Like
Firefox does not run unconfined.
Please don’t. Bugs should by default be reported at the bugzilla → https://bugzilla.redhat.com → product fedora
However, I don’t see a bug here.
Keep in mind that confined users are by default disabled in Fedora, whereas Fedora uses a security architecture that does achieve security by other means. Every general operating system needs to find a compromise that makes the system usable by average users. SELinux confined users can become a denial of service for average users. This was originally intended for high security corporate environments, in which most users have no access to root or sudo at all.
Confined users are an additional layer of security that makes SELinux also active within user accounts. This adds a security layer and increases security to a level that bypasses most operating systems as processes are even within one accounts isolated from each other in many respects - it can compete in many respects to completely separate containers, but without imposing the limitations that make “full scale” containers impossible to be used on end user GUI environments for all their processes/apps. Yet, for average users, it can cause denials of services as confinement needs a lot of efforts to ensure that everything is properly aligned in every possible condition - every app needs to be prepared with perfect SELinux policies (e.g., third party software is likely to break).
This means, if something is unconfined, it is not unsecured… but differently secured. By default, SELinux is limited to critical areas of the system (above average impact of exploitation + above average likelihood/chances of exploitation).
Fedora is by default unconfined, and firefox runs by default 
4 Likes
Eh, is this a potential short-coming or something that could be not happening? As-invasive as I found SELinux on Server, I was at least expecting it to be doing something out-the-box with Firefox on Workstation 
If you have an idea of a way to create this SELinux policy in a way that isn’t gonna break things for users, then you might consider pitching it to the SELinux maintainers.
Is that the reason why? Like is it something like SELinux being too-powerful and not fine-tunable enough to have decidable defaults for desktop Firefox? Or was it not tried because it’s not a desktop requirement? Maintenance burden to not wanting to maintain the Firefox profile support? Some combination of all that?
The short of it is, you can set it up on your system if you really want to, but you should probably take a few minutes to RTM to realize what you’re getting yourself into.
SELinux can confine Linux users. A number of confined SELinux users exist in SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user to the SELinux
user_uuser, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such assudoandsu, as well as preventing them from executing files and applications in their home directory. If configured, this prevents users from executing malicious files from their home directories.
4 Likes
It does, but only if firefox touches something that is vulnerable/critical (e.g., high potential for exploitation or high impact in case of exploitation).
The confinement has nothing to do with SELinux being enabled or disabled. It is just if SELinux is also active within user accounts and in between all processes, and not just at the critical parts of the system (which can be touched by users’ applications, but users’ applications are not critical parts themselves).
It is fine tunable enough. This is why such things like confinement is possible without the issues of containers (containers are almost always strongly blurred in their isolations in order to work in users’ environments). But a fine tuning that fits the average user environment needs knowledge, and that has to be applied to all packages on the system. That works out if the packages are limited to packages that are explicitly supported and well prepared (e.g., RHEL or CentOS, we aim to achieve that on Fedora’s default repos as well - but a “practical guarantee” for every minor package of every maintainer is something that we can never provide)
It is possible to work with confinement at the moment, but I still occurs that adjustments are necessary, which forces the user to be able to identify what is going on and how to solve it. When you introduce third party packages, it gets worse, as many providers don’t know much about SELinux at all.
Keep in mind that issues already start with adding USB drives from other people: Just quickly transfer a file from A to B (this is what people do so often : ). But here we have already the first issue in which two profiles can lead to SELinux breaking the access of the USB drive if confinement is active: the way people use USB drives are everything but a good practice, but with SELinux confinement is active, SELinux will enforce good practices 
3 Likes
I think it is. There is sufficient resources and documentation about it. After the “SELinux disabling marathons” of its early days, I am happy that we found a compromise that adds the additional and often preventive security of a Mandatory Access Control (MAC) to critical parts of the system in a way that offers an acceptable experience to users without encouraging them to disable it at all (which was a problem when it was introduced initially).
It’s not, but I think you need to get deeper into the documentation and learn about the backgrounds of that technology and when and how it interacts and impacts: unconfined and disabled/inactive are different things: even if a Firefox process runs in an unconfined user account, SELinux would still protect critical parts of the system against this Firefox process, but in order to achieve an acceptable experience within a user account, its protection of user processes against other user processes is limited: here other security means are in place.
Keep in mind that SELinux is an additional layer of security, a Mandatory Access Control, and many systems do not have a MAC in place at all. Of course enforcing globally would add security and add additional means to mitigate attacks and related incidents, but if a security means ends up in a denial of service against the user, we have seen many years ago that the result is that people just disable valuable means like SELinux at all, and therefore they remove the additional MAC layer at all, including from the critical parts in which it is most important/useful/valuable: we want to avoid that, and therefore ensure that SELinux is (and remains) active in the most critical/vulnerable parts of the system rather than nowhere.
I agree that there are some open security questions in what/how some things are done in modern operating systems’ graphical user accounts, apps, and so on, but that is not an issue specific to Fedora but a wider issue that is not solved in research at all, and such issues are much more urgent in operating systems that do not offer MAC at all. In any case it does not belong to ask.fedora. If you want to talk about that, you can do so at the watercooler.
In any case, this topic is quite old, and it is not worth to open this discussion again as it is already blurred and gets repetitive: the selinux-confined-users category contains all necessary answers (and links to resources), and there is enough documentation of this available to verify the difference between “unconfined” and “disabled”. So I close this to avoid further blurs and repetition.
2 Likes