I had this, it’s a problem with user permission, tomorrow I can brief you in how I solve it
1 Like
I understand your point, but I am not sure if a graphical tool woud be a good complement.
Driving a car with broken brakes is less dangerous if the driver knows about the issue compared to if the driver does not know about the broken brakes.
What I mean, if people disable SELinux, they at least don’t expect the related protection. But you can have SELinux enabled but still “effecitvely disable” it by “liberal policies”. SELinux is a great thing, and maybe the most powerful but still most adjustable/“tailorable” MAC for Linux, but one of its disadvantages is its complexity. When users just “test” and open up privileges until it works, it is possible that they effectively already disabled SELinux. Graphical tools can foster such negative developments (I am not worrying of users who are not yet sufficiently experienced to understand THE complexity of SELinux policies, but about the users who are not yet sufficiently experienced to understand THAT there is complexity and thus that this is not a trivial task). So the absence of graphical tools can be seen as advantageous “entry barrier”. The major difficulty is the architecture and thus the “reasoning” of SElinux imho, and graphical tools cannot mitigate that anyway.
However, this complexity is one of the reasons why I put forward this suggestion: make SELinux be appropriately configured by default, so that users do not need to adjust it themselves, but just choose if they want to remain unconfined or get some level of confinement.
Given the complexity of SELinux policies within an os, I tend to prefer in general that SELinux policies get professional elaboration and public review, and consolidating related data and solutions at our SELinux team achieves that best imho. But in the end, everything is just a compromise obviously 
I can’t really argue with that. 
And I’m fine with that approach as long as the end user has a reasonably easy way out when they just need something to work regardless of the security risks.
So, in that case, I guess my request is that this new SIG be diligent about creating well-documented SELinux booleans for the security policies you create so we “laymen” end users can switch things off reasonably easily when we must. To-date, I’ve been able to (for the most part) manage with switching booleans on and off (though I’ve seen a few that seem much too broad in terms of what they allow).
No one can argue with the broken brakes 
But I indeed did think only about making/adjusting policies or roles and such. The booleans are indeed an issue that needs better documentation. The goal should be definitely that average users don’t need to manage the booleans, but users who have more specialized needs could be able to adjust their booleans more appropriately (and with less deterrence) if there was a more comprehensive documentation. Not sure if a GUI would make a difference here since I find semanage comfortable for the boolean adjustment itself, but I guess for the boolean-purpose a GUI would be not as dangerous as for policies/roles and such. An SE-boolean GUI could offer a stronger/immediate link to documentation (if existing) compared to command line stuff.
Unfortunately, I assume this project here is unlikely to change the boolean issues. At the best, for a few booleans that are relevant for more widespread use cases (such as the mentioned *_exec_content or so). But we cannot repair all brakes 
Indeed, fostering “SEdisable” or even switch-distro-behavior should be avoided. There is no plan to make confined user accounts a default. It is something that users who want or need this security level can enable themselves.
I would say that the “highest” achievement would be, if we at some point can ensure that the policies are aligned and remain maintained throughout, this could become an opt-in possibility with a short explanation (so, keep it disabled if the user does not enable the tick) in the installer in applicable editions/spins (but even this possibility is not realistic at this time ). What we learned in the past (in general, not Fedora) is that users need to be convinced of and educated to security, not forced.
Please forgive me if I am missing something, but for this all we are doing is testing various confined users (i.e. sysadm_u, staff_u, user_u, and guest_u) and providing feedback and bugs/issues? Or are we building confined users and testing then to better build out processes?
Well, you can test confined user accounts to get some understanding of SELinux and to contribute to Fedora, and if “things” that work without confinement do not work with confinement, you get the related data and open a ticket at our SELinux team’s GitHub repo so that we achieve at some point that confined user accounts work as good as none-confined-accounts.
But you can also use confined user accounts in production (I do so) because they are already “usable” (but with restrictions) and provide much more security than unconfined accounts. Especially when you handle private/classified information, you have to be aware that in graphical desktop environments, you “more or less” trust all processes that run in the GUI. This poses a risk that can be mitigated with confined users. However, at the moment, as mentioned, there are restrictions on Fedora, and it would be cool to get rid of these restrictions (which first means to identify them) at some point to also enable average users to use confinement
In any case, if policies look good despite a denial, or if something that used to work does no longer work after an update, it might be worth to think if this is really a SELinux issue, or if the package has a problem. If the latter is true or indicated, this is a normal bug report at bugzilla or so (of course the environment in which an issue occurs needs to be described, which then includes the confinement).
Thus, this is something for that we do not need meetings or so. Everybody can do this on themselves. If we make this a SIG, the SIG itself would be only to propagate this opportunity (both to test/improve it, but also to use it), and to help those people who feel not sufficiently confident to do this on themselves. May it be that they are usure how to get confinement done securely/stably, or may it be that they are not sure how/what to file at the SELinux team’s repo. So this would be a very informal SIG without much “onboarding” or so.
As far as it concerns me, anyone who wants to be in can say “hello I’m in” in this topic, open topics in ask.fedora with the #confineduser tag (the first user will have to create it; should be possible by any TL1+ user in ask.fp; once a user created the tag, they should mention it here, so that I and everyone who wants can start monitoring the tag) when it comes to technical questions. Additionally, I can create a pagure repo that everyone with an FAS account can use to open tickets: may it be a ticket for issues they experience or are unsure about, or tickets if they are not sure what/how to file at the upstream repo from the SELinux team (this would be also to decrease a little their workload).
Theoretically, I do not think we need more than that (I am not sure if these things will be used much, but this can offer some confidence without much investment). I will monitor the ask.fp tag once created, and also the pagure repo to ensure no one gets lost. Everyone is free (but not obligated!) to do the same.
However, it is always good to give people some reward for contributing, so it is possible to also create a pagure group for the repo, where we can add people to have their contribution somehow mentioned. Let me know your thoughts if you want. I can create that.
1 Like
I created a pagure repo for now: Overview - SELinux-confined-users - Pagure.io (let me know if I shall create a group in order to add members)
We might also create a short entry in Category:SIGs - Fedora Project Wiki but I don’t think we need a page on its own: just a section on the major page. It is just to inform that the opportunity exists (both to contribute and to use it), and to link the pagure page and this discourse topic, and mention the possibility for #confineduser topics in ask.fp when it comes to technical “how to get X done in Fedora Linux” questions.
Anyone who can spare a minute is free to add the section to the wiki page, otherwise I might spare a few minutes in the subsequent days.
It would be also nice if someone can open a ticket in the pagure repo to test if I get notified.
1 Like
Category:SIGs - Fedora Project Wiki
People who use and/or test SELinux’s user confinement in Fedora in order to improve SELinux policies to increase security and user experience (including for default Fedoras without user confinement). Also, the SIG aims to make the “confined user” capability as smooth as the Fedora default without confinement so that confinement becomes usable by average users. Additionally, the SIG aims to propagate the possibility/capability about user confinement but also about the possibility to easily contribute to that. This SIG is for all kinds of security enthusiasts, from beginners to SELinux experts. It is very informal: contributors might review the discourse topic (especially the opening post and this one) and say “Hi” in the topic. For any kind of help about user confinement or related reports, feel free to open a ticket in our pagure repo, or use the #confineduser tag in ask.Fedora for technical “how to get X done in Fedora Linux” questions. The SIG has no meetings.
Feel free to adjust.
If anyone has issues with using/adding bluetooth devices in KDE: I reported the issue. You can mitigate this easily without modifying yourself the policies:
You can use and connect to devices properly with confined accounts, but only if you have added the device when the account was not confined. This means, if you have an issue with adding or connecting a bluetooth device, I assume it was added when the account was confined. Thus, remove the device, then make your user account for a moment to unconfined_u, reboot, login and then add your bluetooth device just as usual. Once you added the device and properly connected to it the first time, you can confine your user account once again with your preferred confinement (user_u, staff_u, sysadm_u, …), reboot, and then you should be able to properly connect to this device in future.
I am thinking if it makes sense to create a page, a pagure repo or something like that, in order to elaborate mitigations/workarounds for those using confined user accounts. Finally, it can take some time before a reported issue can be solved.
This looks like a bug in the SELinux policy. Could you see if there are some audit logs and file a bug?
I have already reported it to the SELinux team [1] [2] with related
details. I don’t know for sure yet but my current guess is that the
actual problem caused by the policies occurs much earlier: during the
login. There are several denials during login, and later on there are
several functions (not just bluetooth, also buttons like shutdown or
reboot) that do not work and where only user logs seemingly indicate
something in plasma/kde to be broken or wrongfully implemented. There
are no avc denials at the very moment, nor root logs at all.
Nevertheless, the issue occurs only as long as the account is confined.
So its clearly related. But the details including the kde/plasma-related
user logs of the very moment [1] are in the github tickets.
There are several such bugs in the SELinux policies (some are already
reported ).
But since the default profile used in all Fedora editions/spins
(unconfined_u) does not enforce much within user accounts, most remain
hidden until people start to work with confinement. But this is why I
founded this SIG. On one hand, to make Fedora work properly with SELinux
user confinement. On the other, to improve the policies in general, (and
sometimes also to identify bugs in packages because some denials occur
for good reasons).
For now, we agreed to keep this in the GitHub
repo of the
SELinux team. But feel free to let me know if there are some other needs
/ preferences from the side of the KDE SIG in order to remain/get
involved/informed.
Did you make sure to disable the donaudit rules in the policy before testing? The shutdown buttons are DBus/loginctl/systemd calls.
I think it would be nice to make this a proper SIG with a Wiki page, etc.
I’m also working on SUID less systems, which is a very similar topic. The goal being that you remove all SUID bits from all binaries in the system and instead you use ssh over a local unix socket for privileged operations.
Why ssh? Isn’t sudo designed for that?
I guess I see – sudo has the SUID bit set. Still though, sshd seems like overkill. It is designed for a lot more than that and some systems might not want it installed. It might be better if another always-running root daemon (e.g. systemd) could take care of it.
ssh does some things I don’t know how to do otherwise.
I have not configured confined users yet, still getting some basics working like cockpit. Not wanting to connect with firefox and finding the cockpit-client just too much I’ve started using cockpit-desktop even for the localhost:
/usr/libexec/cockpit-desktop / ansible@localhost
The ansible user’s ssh key is accessible in my regular user’s ssh-agent so this gets me in passwordless and can switch to admin mode passwordless as the ansible user has full sudo access. cockpit-ws does not have to run on any of my systems either. What is expected to happen when I configure both my regular user and ansible user as confined users?
After starting cockpit-desktop I was expecting to see the network namespace with ip netns list but did not find what I was looking for until I ran lsns then I could see the network info with
nsenter --preserve-credentials --user -t xxxxx --net /sbin/ss -nap4
I have a lot to learn. I am looking forward to building a better understanding of confined users, other aspects of SELinux, namespaces and cgroups.
My goal is to get rid of SUID binaries. Sure, openssh is doing more than would be needed, but it’s the only implementation of a remote shell with hardware 2FA support with Yubikeys for example.
I’ll try to post an article with my work in progress design.
I like the idea of making this a “full scale” proper SIG, and I would be
up for it. But I am not sure if we will have sufficient contributions
for that. The usage of confined user accounts is currently low, and
although we have many security enthusiasts in Fedora, most are average
users who focus on making and keeping their systems working without much
contributions beyond. So this is why I wanted to keep the “overhead” and
contribution entry-barrier as low as possible.
You are right that a proper SIG would be the perfect way, and I would be
in! But my own time is limited as well, so there need to be other people
as well who want to contribute beyond testing & reporting.
We might start with asking if anyone here has time to complement the
current wiki [1] entry by a dedicated page?
I would be also up to merge comparable approaches and goals into one SIG
(such as your current project) if the activities towards the goals
complement each other (we might make this a separated discussion topic?).
[1] https://fedoraproject.org/wiki/Category:SIGs#SELinux_Confined_Users
I can make a Wiki page for it. How do feel about dropping “SELInux” from the name of the SIG? i.e. just “Confined Users SIG”?
I’ll copy the template/text from SIGs/AtomicDesktops - Fedora Project Wiki and merge your existing description.
Cool! Sounds good. Im fine with Confined Users SIG.