SELinux Confined users: only user_u is launching the Desktop?

Ask Fedora
, , , , ,
1

I created 3 new users, and assigned the roles user_u staff_u and sysadm_u to their login, following the wiki.

I created a password and assigned them to the wheel account. They showed up in KDE Plasmas systemsettings.

I assume the wheel is a problem? But this should be allowed for sysadm_u I thought?

syadm_u didnt login and threw me back to SDDM immediately.

staff_u did login but stayed at a black screen (displaying something from my firmware)

user_u logged in normally, but id shows that it is unconfined??

Using Fedora Kinoite 40, this may be an issue with ostree and groups?

2

I am about to do similar testing today, but I will be doing it on a Workstation install.

First for sysadm_u, did you set:

setsebool -P xdm_sysadm_login on

@py0xc3 mentioned this in another thread, and then (about 3 months ago) it worked for me. I don’t know that it will work for staff_u though; I settled on shooting for sysadm_u as a compromise position.

Also, interesting on your results of ‘id’. Can you try ‘ps auxZ’ and see what the processes are labeled as? Everything should be user_u (or sysadm_u, or staff_u, etc depending on which user confinement strategy you are using) unless labeled otherwise by administrative processes.

1 Like
3

I will try. This then needs to be updated on the wikipage.

$ sudo setsebool -P xdg_sysadm_login on
Boolean xdg_sysadm_login is not defined
4

Whaa? Do you see ‘xdm_sysadm_login’ listed when you run ‘getsebool -a’? I do on my Workstation install (and I’m pretty sure the policy/booleans/etc are the same between the KDE spin and Workstation, but could be wrong).

EDIT I missed it- you have a typo :smiley: It’s not ‘xdg’ but rather ‘xdm’.

1 Like
5

Oops… haha

6

From what I see, these work only on terminal based distros. Desktop uses are not fully functional. Allow rules are needed in the their policies to run normally on desktops.

To run them, you must make the user permissive in the policy.

1 Like
7

This is what the Confined Users SIG is meant to address: to bring at least sysadm_u to where it is usable on a daily basis. In fact at the moment it is possible to run sysadm_u and have a functional desktop environment (using both Gnome and KDE), but there are issues that pop up with certain applications, etc.

@boredsquirrel I know that the atomic variants have additional challenges due to how they are configured with respect to SELinux user confinement. I am currently testing Workstation and will soon after be testing a new KDE spin install; I then plan to try Silverblue and Kinoite. Hopefully @py0xc3 shows back up as I consider him basically point on how we should assemble the information gathered (as an aside I was supposed to be doing all this 3 months ago). Be sure to keep track of what issues you have- any data can hopefully be helpful once we coalesce around a singular place to store/track it all.

1 Like
8

Interesting.

user_u works, but I need to check if the processes are actually confined.

9

@jaymarty, currently KDE does not have a policy. It uses GNOME’s policy to function. I already have policy modifications for Workstation and Silverblue. I would be happy to help with the KDE distros. The problem I have is organizing everything like you mentioned before.

2 Likes
10

How do you start with this? Once logged in, do you monitor the SElinux access requests and denials?

11

I see. Are these policy modifications (for Workstation/Silverblue) you have already merged into Fedora’s selinux policy, or are you in some waiting pattern for this? If memory serves me correctly @py0xc3 uses KDE with confined users (I believe sysadm_u), though I don’t know if he’s made any of his own modifications (e.g. modules) that he has not yet attempted to upstream.

I would also be very willing to help with the KDE distros (the spin, and Kinoite)- I have a free SSD to test on and significant time. Like you I want a place to dump the information though.

1 Like
12

Yes. First only the desktop login. Not running and apps or commands. Monitor it’s normal functions checking for AVC’s. Then I check each included desktop app, one by one for AVC’s. Workstation and Silverblue have different default apps. So I check both distros for similar AVC’s next. Assemble a policy that adds additional allow rules, then load this policy until I have no AVC’s.

I am going to assume KDE Desktop and Kinoite would be similar process.

1 Like
13

Atm, I have not requested a pull resquests because they are to many at once to deal with.

14

What tools do you use for monitoring? And what if login doesnt work?

I am a bit confused why user_u would work but the others, granting more permissions, dont.

Would love to help!

15

I will then follow this same process, and I will do KDE Spin/Kinoite. Do you do this for sysadm_u, then staff_u, then user_u? Are you only targeting sysadm_u atm? I will mirror your choices here.

Hold on to your data- I’m sure at some point we’ll be able to dump it all in a central place.

1 Like
16

My thought was that sysadm_u is the most easy one, then if that works, go on.

But ironically user_u is the only one that works?

17

From what I have read, sysadm should be used as a role for specific task. Such as secadm, webadm, etc… When you classify a user as such with a custom policy, you would inherit it’s sysadm privileges.

1 Like
18

I have a custom toolbox that I use for the selinux diagnostics. But I can guide you if you like? What is the procedure your doing atm?

1 Like
19

That’s… a really interesting idea. I know you were asking/responding to boredsquirrel, but I test using a clean install on an SSD I currently am not using (I have 2 boot nvme SSDs).

Your idea is interesting though since mine is much more of a pain.

20

@richiedaze I didnt know didnt i know you could do this just in a toolbox!

Spawning a desktop alone sounds pretty complicated.

I dont have any procedure so feel free