Well, we are not talking of unconfined processes. You used the selinux-confined-users tag, so I assumed we are talking about confined user environments, don’t we?
What I had in mind indeed would only impact in a confined environment. So in user accounts that are user_u, staff_u, sysadm_u.
SELinux derives denials from the outcome of who does it, what is done and with what it is done. It differentiates between different processes/users. You might review the Firefox case I elaborated in the inital topic of the confined users → SELinux differentiated between the user to access the terminal’s content, and the firefox processes that wanted to access the terminal’s content (the latter was denied access).
The problem here is more: what processes access .bashrc in what conditions? I can currently not invest much time to do research.
Off the cuff, I see three times when something uses .bashrc:
- login → it is accessed when the user is logging in, may it be to a TTY terminal, or to GNOME or KDE or whatever desktop environment
- when a terminal emulator (or a TTY terminal) is opened (e.g., konsole or qterminal)
- when the user makes changes in the file
Off the cuff, the major issues / questions I had in mind are:
-
What access(es) on .bashrc take(s) place during the (GUI) login, e.g., GNOME or KDE? What changes are necessary here in terms of profiles other than the profile of .bashrc itself? I do not know sufficiently of what especially GNOME but also the new KDE (and their process(es)) make with .bashrc on login (I use KDE, but the new Plasma made many changes that impacted SELinux - so far the changes felt positive - but don’t know what it means here)
→ Can we create profiles that satisfy both the access needs on .bashrc of GNOMEs/KDEs processes during the login, and also their respective terminal emulators BUT no other processes in an explicit way? Explicit means, explicitly only allow the necessary accesses and nothing else - and without doing more changes of policies throughout the environment (e.g., indirectly dependent policies of indirectly dependent policies or something like that, with iterations that increase the outreach of the changes, complexity and thus potential for unexpected impacts/behaviors → can we explicitly limit what is affected and needs to be re-tested, or do we have to expect that the changes impact - in a worst case - everything of the account or so). -
Can this be implemented in a generic way? This means, one size fits all: If it works on Workstation/GNOME, does it also work for KDE, or Silverblue/Kinoite? If not, are the adjustments per edition realistic or too much work / too much potential for unintended behavior?
I would wait a little and see if Zdenek has some thoughts about it off the cuff and then decide if we put more energy in it. I think he has most experience of the current policy implications of Fedora’s defaults to make an educated guess off the cuff.