Security enthusiasts wanted: from beginners up to SELinux experts to make up the SELinux "Confined Users (SIG)" to foster Fedora's security capabilities

Fedora 38 workstation issues being a "Confineduser”

Applications that don't start
  1. Create a new non priveledge user called confineduser
  2. Create a login name record of your SELinux user and range.
sudo semanage login --add \
	--seuser user_u \
	--range s0 \
		confineduser

Broken apps that don’t start:

  • contacts
  • weather
  • clocks
  • maps
  • photos
  • videos
  • boxes
  • disk usage analyzer
  • connections
  • characters
  • logs
  • fonts
  • cheese
  • texteditor

PROBLEM:

These apps do not start because SELinux blocks user_dbusd_t “status” access to user_t

journalctl -g avc
Oct 18 13:22:57 fedora systemd[13306]: selinux: avc:  denied  { status } for auid=1001 uid=1001 gid=1001 cmdline="/usr/bin/dbus-broker-launch --scope user" function="reply_unit_path" scontext=user_u:user_r:user_dbusd_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=system permissive=0

Testing:

Allow user_dbusd_t temporary permissive status to check for normal functionalities of the applications . This allows all user_dbusd_t request to succeed.

sudo semanage permissive \
	--add user_dbusd_t

Once you are done testing, delete the permissive status

sudo semanage permissive \
	--delete user_dbusd_t

SOLUTION:

Add the following allow rule to the confined.te selinux policy to allow app to function nomally.

allow user_dbusd_t user_t:system status;

1 Like

I’m not sure if I get your point / intention richiedaze . But the scope is not limited to Workstation but shall include all desktop-focused editions/spins. My focus would be Workstation and KDE Spin, but of course Kinoite and Silverblue are also important (concerning the immutable desktop variants, the issue is that a lot of efforts would be necessary to make and maintain them compliant at once to both SELinux and the least privileges approach in the policies). The related issue about toolbox is already discussed primarily on github (SELinux repo).

If you have identified applications that are broken with confined users, then you should open a ticket on github (SELinux repo). This data does not belong here (it would be nice if you could cut your last post a little to avoid blurring the topic).

When opening a ticket on github, you might review the initial post here and also the previous topics on github about what information to provide. The actual avc denial you mentioned is already a good start! (Not sure if all these apps break with the same denial?)

Also, the discussion of which policy should be adjusted (and how) should be done on GitHub to bring all related experts together: the seemingly-easiest / seemingly-most-obvious policy adjustment is not always the best, especially when it comes to least privileges: we want to ensure to not unconfine some apps / data too much (or accidentally unconfine much more than that). That has to be clarified on github.

In either case, let us know if anything is unclear about how/what to report. You might use our Pagure repo to keep the topic here focused, or be the first to create the #confineduser tag on ask.Fedora (please let me know if you create an ask.Fedora topic so that I can start to follow the tag once it is created) :slight_smile:

1 Like

That’s nice investigation, thanks! As @py0xc3 said, could you report (copy/paste) that into an issue for the SELinux policy? Thank!

1 Like

Please do not just copy/paste that. Zdeněk gave us input about what the SELinux team needs. Just to know in general that a given application can break (so without details) and to have a time-corresponding avc denial can still leave too much room of when/how/why the denial is triggered, what the denial actually affects directly/indirectly, and how to best mitigate it without disabling too much of SELinux: we have to understand the issue before we can solve it efficiently and effectively.

The given report is a sound foundation, but it needs to be expanded to cover the circumstances of the unintended denial: they need the information to reproduce the exact issue. That’s why I suggested to at least review the GitHub topic I initially linked. At the best, also the subsequent topics could be checked because there are some more incentives about what should be provided.

I edited the above command. Btbh I didn’t want to kill github with many reports.

  • Workstation currently only has one denial for each (14) of the apps I posted.
  • Silverblue and Kinoite have 25 avc denials on confineduser.
  • Silverblue and Kinoite have 4 avc denials on staffuser.

Should I report all those on github?

When switching users in Silverblue and Kinoite to confineduser the session doesn’t even start. What would be the appropriate way to organize this without spamming fedora selinux github?

3 Likes

Generally, if you have identified an unintended denial: you are encouraged to report it.

In order to have a quick and comprehensible overview of the number and types of issues, and the related amount of work, it should be kept that one case is one ticket. However, if you come to the conclusion that two issues have the same origin (and thus are two manifests of the same issues), you should keep them together and assume that this is one issue and thus one ticket. The more manifests of an issue are known, the easier it is to identify their common origin.

Obviously, it is not always known in the beginning which seemingly-different issues are in fact only two manifests of the same origin, and which two seemingly-equal issues have in fact different origins. Thus, you have to anticipate based upon what you experience: don’t waste too much time on thinking about that, it can be changed later when the understanding of the issue(s) improve(s), but if you are unsure, open two tickets, and mention in both tickets (at the best, apparent at first glance) the respectively other ticket, so that the team has it in mind when tackling any of the two.

When you have the very same issue/denial, e.g., on Silverblue and Workstation, and if everything is equal, you might also put both together into one ticket and mention that this issue occurs on both Silverblue and Workstation.

Of course, in all cases, check at first if the very issue has been already reported by someone else, and then possibly add a comment to the existing ticket that you experience the same, and maybe add your data if relevant.

I hope that helps a little as starting point?

Btw, thanks for your efforts! You indeed identified already a large amount of denials that are likely to be unintended.

5 posts were split to a new topic: SELinux confined users: sysadmin privileges necessary to do sudo operations? Why? How to mitigate?

I have moved the recent posts to a separated topic in ask.fedora to keep this “central SIG topic” a bit more focused on the SIG and its goals/plans rather than its technical discussions and technical questions about the confined user accounts.

Also, the possibility to create new ask.fedora tags was disabled, so I have used the selinux tag, which is fine as well: I suggest to use this in future for questions about this → this tag is not often used, and questions about this SIG’s activities are SELInux-interrelated anyway. Maybe this even attracts more people to contribute if they already engage with SELinux stuff but not this SIG.

I will adjust the wiki pages in the next days.


However, @mattdm , it seems that this SIG is centralizing its exchange/activities on discourse and not pagure (the pagure repo remains untouched), which I understand since discourse is more suited for the audience we want to attract here (and maybe also better for related activities).

I know we need to be careful with not inflating the amount of team tags, but would it be possible to get one for this SIG? I would love to see where this is developing to, but having everything organized within one topic is hardly attractive and encouraging. So its just about a tag for project discussions, I think there is no need beyond selinux in ask.fedora. Something like ConfinedUsers-SIG or so. I think its worth a try, and if the SIG falls asleep, we might delete it in a year or so.

I agree that it would be great to have a tag for this SIG (#ConfinedUsers).


I started blogging about what I’m working on that is related to that SIG effort:

I have another one in progress about the security model, suid binaries and NoNewPrivs.

1 Like

I’m sorry: When elaborating all the SELinux-specific stuff among the topics yesterday, I had not in mind that we merged the confined user approaches: it’s already much more than just SELinux. Indeed, with that in mind, I have to correct myself and say that it would be also cool to have a #confineduser tag for ask.fedora, so then both: for ask.fedora and the project discussion. It would be cool to see if the “interrelated ask & contribute” approach we originally intended creates some synergies.

A post was split to a new topic: Do SELinux confined user accounts restrict permissions to critical files?

@mattdm , with regards to the posts since December 27, it would be good to have tags for ask.fedora and project discussion for #ConfinedUsers / #ConfinedUsers-SIG or so.

Users regularly start their questions about confined user accounts here, which blurs the topic. The topic itself also gets a little incomprehensible given that all SIG-related stuff takes place within one topic. I think the tags are worth a try, ain’t they? :smiley:

I’d like to be apart of this if not too late.

1 Like

It’s never too late :slight_smile:

1 Like

I have noticed all these issues on https://github.com/fedora-selinux/selinux-policy containing confinedusers issues. I was wondering why they were not placed in or if they can be placed in https://pagure.io/SELinux-confined-users/issues so we could keep this on topic and better organize them by role and desktop for simplicity for solutions and discussions?

These are two different teams. The github account is of the “general” SELinux team, on which we depend. From a simplified perspective: they are one of our upstreams, and we are one of their feedback loops :wink:

I am asking because I want to test different roles on different spins with different desktop. I also will test the above combinations with homed. With all this information, I would like a base to place and collaborate these discussions before committing them to github. Ideally I would like to identify each denial as an issue so we could group them accordingly to application, desktop, or role. Then start working on the pull request in github.

Right now, I find it difficult to know whats an issue, if it’s related to other issues or if the issue even exist at a single location from the github repo with outside issues included. Is it possible to better organize this purpose?

2 Likes

That is our pagure space :slight_smile: Use it as much as you want! (let me know if there is an issue). If you are unsure, you can always use it. Once we have elaborated a clear case, we put it upstream to github. On github, we have to ensure in advance that it fits to avoid confusion upstream, but in our own space, there are so far no limits.

Unfortunately, we have not yet a tag for discourse, but you are also free to open a topic here if there are questions. Hopefully, we can unify them with a tag at some time.

1 Like

A little addition @richiedaze : if you feel that some other tools or so are necessary or better eligible, feel free to introduce them. We are free to evolve as it feels best for us. (Sorry for being shortspoken at the moment, but I currently have to focus on another issue)

Added confined-users, security-sig and removed engineering, workstation-wg