Selinux user_u on KDE: logout, shutdown, reboot buttons not working in start menu #1829
Comments
|
The above logs were timed to only capture the time of the button click. I expanded the timeframe to also capture more, for example the login. One event which caught my eye was: Don't know if this has anything to do with the above problem. |
|
I also experience the issue that these buttons do not work, and my journalctl does not log any denial-related entry when I click them. Maybe the buttons are simply broken because of some denial(s) that happen(s) earlier: I could imagine that the actual issue occurs at the time of #1847 |
|
There is another indication that an impactful SELinux-denial occurs earlier, before the effects within KDE take place: Within a confined user, I cannot add new bluetooth devices. I can use those that are already known, but when I try to add new bluetooth devices from within KDE, it fails. It looks like a bluetooth error, but the logs of root do not contain anything at all (no bluetooth issues, no denials), whereas the user logs log some KDE/Plasma-related issues (the following log contains both adding new bluetooth devices and then trying connecting to them; all within a confined account and all fails -> the adding of the device ends up in the device being shown in the "known devices"-list after the initial "add+connect" fail, but connecting to the then-seemingly-known device does fail as well if it was added during the account was confined): Once I remove the confinement, I can add new bluetooth devices properly, and once they had been added while the account was not confined, I can use them also when the account is confined again. The broken shutdown, reboot, logout buttons create comparable errors in the user logs (and they also create no denials): I guess it makes sense to first focus on the initial denials when logging in -> #1847 . I could imagine many of the later issues disappear when the initial Plasma-denials are solved/mitigated. They seem to break something of Plasma. Thus I don't open a new ticket for this. |
|
I have to correct my previous comment: There are bluetooth devices that always work properly with confined user accounts and bluetooth devices that do not work at all with confined user accounts. If a device does not work when added while the account was confined, it will also not work in a confined account when it was added before the account was confined. Vice versa, if a device works in a confined user account properly, this device also can be added properly while the account is confined. So adding and using bluetooth devices does not make a difference with regards to confinement. It seems to depend on the type of bluetooth devices: my bluetooth mouse can be added and used within a confined user account, but bluetooth headsets (audio) do not work in any way within a confined user account (it can be neither added nor used). I assume the issue rises in between the profiles of bluetooth-devices and audio-handling. @zpytela without a focus on the bluetooth issue: can you already predict when the reported confined-user-issues are handled/solved? Can we support you with anything else? |
|
@py0xc3 Before a solution in selinux-policy is proposed, we need to understand why the denial appears. What really helps is a reproducer, but if it requires e.g. some particular hardware, then audit denials gathered from full auditing mode or other debugging technique should be sufficient. |
|
I don't think this is linked to specific hardware: I have the same issue
with 3 audio headsets, and it is the same with my phone. Only my
bluetooth mouse works properly (unfortunately, I have only access to one
bluetooth mouse so I cannot test if that is representative).
As I elaborated, the issue clearly correlates always with confined user
logins, but there is no denial at the very moment of the fail (only some
user-level logs [1] are logged at the very moment; looks like something
of KDE is broken, see my extracts above). My assumption is thus that one
of the earlier denials broke something so that later dependencies break
as well without further denials.
So I guess the focus concerning this should be on the denials reported
by physicsisawesome here [2] and my full logs (which includes the
denials) as reported in #1847 [3], and then see if the bluetooth issues
remain after the others have been solved. Not sure if you mean something
else than [1][2][3] with a "reproducer"?
[1]
#1829 (comment)
[2]
#1829 (comment)
[3] https://gitlab.com/py0xc31/tmp71/-/raw/main/delayed-KDE-login.log of
#1847 (comment)
…On 10/17/23 21:25, Zdeněk Pytela wrote:
@py0xc3 Before a solution in selinux-policy is proposed, we need to understand why the denial appears. What really helps is a reproducer, but if it requires e.g. some particular hardware, then audit denials gathered from full auditing mode or other debugging technique should be sufficient.
|
|
Supplement: The bluetooth issue I elaborated above (which I then assumed to have the same cause as the button issue) is still occurring in F40 and thus seems to be an independent issue. When closing this issue, the Bluetooth issue/elaboration might be moved out to become an independent issue. |
|
@py0xc3 Frankly I cannot answer. I've used KDE with confined users for years, so I fix problems as I face them myself, I'd need to go one issue by another to respond properly though. I still don't use plasma 6. I can confirm fixes related to ssh-agent and systemd user instance. Timeouts can quite often be a result of wrong communication over dbus and this may require fixes in the service, in policy, or both. Regarding the outstanding bluetooth issue: the related logs should be these from https://gitlab.com/py0xc31/tmp71/-/raw/main/delayed-KDE-login.log? |
|
No, I don't think the rtkit issue is related to Bluetooth - these denials do not correlate, although I do not know if the rtkit issue causes the condition that then results in the Bluetooth issue. The rtkit issue occurs regularly (and early) but I cannot link any effects immediately to it (I put something dedicated on the rtkit in #1846 ). I still have the rtkit denials on F40, and since they occur regularly, they are contained in many of my logs without being linked to the very case for which I saved the logs. I have integrated the Bluetooth-specific log extracts with some elaborations into my above posts. See my posts in this ticket of: Sep 24, 2023 , Oct 17, 2023 , Oct 18, 2023 |
Hi,
I have a strange bug with Fedora KDE (v38) when using user_u (and staff_u). The logout, shutdown, reboot buttons in start menu do not work. It works in permissive mode, but not in enforcing. I couldn't fix it with audit2allow even in audit mode.
Ausearch:
audit2allow -Rdidn't fix it, so I did the same withsemodule -DB:Did
audit2allow -Ragain, applied policy, but it nevertheless didn't work in enforcing mode.The text was updated successfully, but these errors were encountered: