Did you make sure to disable the donaudit rules in the policy before testing? The shutdown buttons are DBus/loginctl/systemd calls.
1 Like
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.
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.
2 Likes
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.
1 Like
Cool! Sounds good. Im fine with Confined Users SIG.
I’ve made SIGs/ConfinedUsers - Fedora Project Wiki and updated the SIG list page.
Thanks! Looks good. But we will have to make a little revision since
SELinux confined users are not generally to avoid or mitigate the use of
sudo and su. staff_u is intended for sudo and sysadm_u for both su
and sudo. It is just to enforce the SELinux policies not just “around”
accounts and their processes but also within, and enforcing within
implies to add a profile (no profile, no SELinux ; ) , which can include
restricting sudo/su but does not have to. The “idea”/goal is a little
different. I’m currently underway and cannot log into FAS (just working
by email atm), so I cannot propose something atm, but maybe we can
derive a sentence about it from Dan Walsh’s blog posts [1] [2] ?
Generally, we could create a two-folded scope:
-
on one hand, developing the capability to more radically use and
impose SELinux (and maybe other security means) and exploit its (or
their) security capabilities also in average use cases and make it
available for beginners with high security demand (especially in GUIs), -
and on the other hand, develop the capability to easily remove all
SUID bits without breaking operations for average use cases and making
this available/working also for beginners without sophisticated
knowledge (I hope I captured your scope correctly?).
Both obviously complement each other and both together maximize security
(SELinux confinement & absence of exploiting higher privileges). Also,
testing both against each other can facilitate further findings and
reveal issues we need to solve to improve security, stability and
availability. Something like that?
When I have a little time, I will check in the coming days if user_u
will disable/forbid SUID bits (my sysadm_u account does not, but
sysadm_* is intended to su/sudo anyway), that’s indeed an interesting
question, but I expect that user_u can still do passwd and such stuff
(which means I expect that confined user accounts cannot replace
removing SUID for max security).
[2] Confining the User with SELinux - Dan Walsh's Blog — LiveJournal
1 Like
I’m not sure I follow. Any user capable of becoming root via sudo isn’t confined. staff_u is mostly worthless from my point of view if you can just ask sudo to become root.
We want to be able to run the full desktop session and have a complete experience when running under user_u, fully confined.
See user_u can execute setuid binaries · Issue #325 · fedora-selinux/selinux-policy · GitHub
Thanks for letting me know about the GitHub issue, I haven’t reviewed
that one so far.
Concerning the use of staff_u and sysadm_u: getting root access is not
the sole security issue for users - and in practice, it is a minor one
on normal user-centered installations (without server-like use) given
its likelihood. In any case, su/sudo needs a password to be exploited,
and before getting to the point to try a password, an attacker needs
some type of terminal access to exploit this. Much has to go wrong
before an attacker is in a situation to exploit su/sudo when attacking
normal user-centered Fedora installations.
You might review the issues of cockpit and primarily Firefox I
elaborated above as examples. Especially when using GUIs, the most
dangerous security issues (dangerous in terms of likelihood and impact)
for normal user-centered installations take place within their user
account and have no relation to root:
People use their credentials for banking, buying and other stuff on
their GUIs in their normal user accounts. They use password managers to
store credentials on their user account. They surf on websites that are
unknown to be hostile or not - and “no single point of failure” also
implies the assumption that Firefox and any other browser can have
exploitable flaws. Also, people install a lot of software that runs in
parallel in one GUI, not all is necessarily trustworthy - and each can
have security-relevant flaws. GUIs allow a lot of processes to interact
with each other. Nothing of that is related to root access, but it can
be very dangerous, and more likely to be exploitable on an normal
user-centered installations than immediately gaining root privileges.
Especially in GUIs, unconfined_u does not restrict processes accessing
each other. staff_u and even sysadm_u do. The mentioned bug in Firefox
allowed in unconfined_u that Firefox could access the terminal and its
data, but Firefox crashed in sysadm_u because with this profile, SELinux
did not allow Firefox to access the terminal at all. With unconfined_u,
any hostile process (or process that has been taken over due to some
flaw or so) can gather a lot of dangerous data and impose dangerous
manipulations - which are not allowed if SELinux is confining the
account - even with sysadm_u or staff_u. All this takes place within the
normal user account and without relations to root access or kernel
space. Btw, staff_u and sysadm_u can thus also restrict processes from
terminal access if their profile does not intend that (which restricts
su/sudo indirectly). Much depends on the policies in our repositories.
But the Firefox case already indicates that unconfined_u could allow a
manipulated/captured Firefox to find its way to try su/sudo, but
sysadm_u indicated to make this at least much harder.
You are absolutely right that mitigating privilege escalation is a
strong security advantage, but it is not everything, and in average
user-centered use cases, the more-likely risks (that still can hurt the
user/organization a lot even without higher privileges) do not need root
access. This is also about protecting users from themselves since they
often do not think much about what they install and how they
configure/use their software as long as it seems to work - and I have
seen a lot on ask.fedora 
I am not sure if a captured/hostile process
can as easily manipulate, e.g., .bashrc on sysadm_u as on unconfined_u
(I will check if I have some time off - I’m curious now : ).
Also, Dan’s blog posts I mentioned make some good points about why to
use confined users - beyond su/sudo.
But indeed, I would appreciate a profile that gives me file access
comparable to sysadm_u (beyond ~, which means in practice to file
profiles like unconfined_u:object_r:default_t , or something
alternative) but no su/sudo without making much (potentially vulnerable)
configuration myself. I do not need su/sudo on my user account, but the
file access of user_u and staff_u causes issue to my processes and daily
activities. Let’s see how things develop in future…
1 Like
From my point of view, the intra-user security / isolation is better performed by Flatpak as it is something that the user could understand. SELinux is too complex for most users.
Freshly relevant links for dropping SUID binaries:
2 Likes
Personally, I consider flatpak a socio-technical security issue. On one
hand, it gives users the perception of containerization, which fosters
less considerate behavior. On the other hand, most flatpaks are
configured to disable isolation since they come with
filesystem=host/home configuration or so, which does not mitigate many
risks compared to normal applications running with user privileges (and
it mitigates less risks than staff_u or sysadm_u on non-server desktop
use cases). At the same time, the flatpaks come from heterogeneous
backgrounds - and the user has to fully trust any of them, including to
trust that they provide appropriate isolation configuration (whereas,
when I checked it last time, all I checked imposed
filesystem=host/home, e.g., vlc). Thus, if the package is not
trustworthy so that isolation would be important, you can expect that
isolation is disabled (may it be because developers do not care or for
hostile reasons). Vice versa, those who care for imposing “least
privileges” and “least access” concepts tend to be those who are
trustworthy anyway. I am not sure if that issue has been solved in flatpaks?
The complexity of imposing the confinement is low imho, and
theoretically, it could be easily put it into a GUI. But you are right
that at the moment, this is complex: because the policies in Fedora are
not properly aligned. At the moment, users need to know how to mitigate
or how to file the issue. Both needs knowledge. This is what I wanted to
overcome here Making Fedora “confinable” by default for every
experience-level (without the current issues - just enable it and done) 
Thanks for the links! I would love to see Fedora without the SUID mess
(and with production support for SELinux confinement : ) → sysadm_u
file system access without su/sudo would be cool - and I just recognized
that you already proposed a solution that facilitates that - I just need
to get rid of the SUID bits of su and sudo (thanks for the
incentive). It’s so obvious… but I didn’t think that way (good that we
put the two security projects together^^).
2 Likes
I just came to the conclusion that I likely do not fully understood your
points: you consider user_u without su/sudo as appropriate, but staff_u
and sysadm_u to be too complex? The latter two are closer to Fedora’s
default, ain’t they? I mean, if policies are properly configured (big
“if” atm, i know), confinement just needs to be enabled (one command on
a default installation), and if intended by the users, they can keep the
su/sudo they are used to and though have more guaranteed security
enforcement and isolation than with toolbox? (or they can get rid of
su/sudo at all if they prefer max security, but managing their stuff
without sudo/su might be more complex for users given the need to go
back to TTY, isn’t it?)
I’ll try to make blog post to clarify what I mean.
I would be interested in helping with this project. I have played with this before creating a homed policy. I have already corrected the required seuser policies for staff_t and user_t to work in fedora silverblue using a custom policy I could share.
Welcome @richiedaze
I have tried to consolidate the ideas and approaches we have so far, and sort them comprehensibly into short and long term goals, and into contributions that aim for all levels of experience and those aiming for more experienced users (or those who want to become experienced). That way, I end up with 4 pillars.
Let me know if that makes sense or if we shall change something. It’s just a suggestion so far:
This project should be a part of a bigger mindset. Most Linux distributions are heavily focused on system administrators.
For instance:
-
Software centers should be aware of user’s that aren’t admins. They should let regular users install software as users by default.
-
Systemd user services and podman user containers should also be allowed as well by default. For example, Fedora’s systemd policy is not as detailed for users as upstreams, while the containers policy is well written for both system and users.
-
Users runtime folder mostly carry default labels. These create problems in trying to implement a proper confined policy because you would have to correct other policies first.
-
The introduction of ostree OS’s like Silverblue introduced new problems. Flatpak is the default way to install apps. Flatpak uses ostree and bubblewrap which neither have fine selinux policies creating the same problem as the runtime folder.
These setbacks only scratch the surface of this issue. I’m guessing with a proper work plan these issues can get ironed out accordingly without compromising the current policy.
Fedora 38 workstation issues being a "Confineduser”
Applications that don't start
- Create a new non priveledge user called confineduser
- 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