Bug 1647920

Summary: ThinLinc unusable on Fedora 29
Product: [Fedora] Fedora Reporter: Samuel <samuel>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 29CC: dwalsh, lvrabec, mgrepl, ossman, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-12-12 12:25:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Samuel 2018-11-08 14:39:24 UTC
Description of problem:

Since after I upgraded to Fedora 29 on the machine running my ThinLinc server I can no longer use the native client nor the web client. I can't use the web admin interface either. In all of the cases above it takes ~2 minutes to connect.

Seeing as I'm getting an USER_AVC in /var/log/audit/audit.log, I'm thinking its related to the selinux-policy upgrade that came with the Fedora 28->29 upgrade.

Version-Release number of selected component (if applicable): 3.14.2-41.fc29

How reproducible: 100%

Steps to Reproduce:
1. Install Fedora 29
2. Install the ThinLinc server
3. Try to connect

Actual results: Takes ~2 minutes and then eventually you connect

Expected results: Should connect immediately

Additional info:

Using strace to see what the processes are being blocked from doing, it seems like user lookup isn't working at all.

After I do 'setenforce 0' everything works fine.

The audit log says:

type=USER_AVC msg=audit(1541681954.605:398): pid=788 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.730 spid=1 tpid=5844 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:thinlinc_webaccess_t:s0 tclass=dbus permissive=0  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus"

And the above AVC appears right away as I try to connect.

Bug 1460244 might be related, but I'm not getting denies for msgtype=method_call, I'm only getting msgtype=method_return.

Comment 1 Samuel 2018-11-08 14:40:49 UTC
I have reproduced the problem on two different machines, on which both worked flawlessly on Fedora 28, and both showing the exact same problem after upgrading to Fedora 29.

Comment 2 Pierre Ossman 2018-11-08 16:08:51 UTC
This is also broken on Rawhide, so no recent fix it seems.

Oddly enough sesearch doesn't really list this as permitted on Fedora 28 either:

> $ sesearch -A -s init_t -t thinlinc_webaccess_t -c dbus -p send_msg
> $

Yet it still works.

There is very little difference between the f28 and f29 branches here:


Perhaps it isn't a policy change but rather that systemd has started doing something new in Fedora 29? Or did dbus not properly enforce the rules before?

Still, thinlinc_webaccess_t has this policy:

> unconfined_domain(thinlinc_webaccess_t)

So it shouldn't really be prevented from anything. Explicitly adding:

> auth_use_nsswitch(thinlinc_webaccess_t)

does get things up and rolling. Is there perhaps a missing call to that somewhere? Or should unconfined_domain() have a rule too allow all dbus communication?

Still doesn't explain why Fedora 28 works though, because the rules for this seem to be the same...

Help? :/

Comment 3 Pierre Ossman 2018-12-10 11:12:59 UTC

Could someone give us some guidance here? This will cause quite a bit of problems for our users. :/

Should we change the added policy? Or is this indeed a bug that we need to wait for you guys to fix?

Comment 4 Lukas Vrabec 2018-12-12 12:25:07 UTC

We don't ship policy for thinlinc. I don't know which package brings this policy but this SELinux macro will fix it:


Could somebody add this macro there? 


Comment 5 Pierre Ossman 2018-12-12 12:37:06 UTC
Sure, we can fix that.

However, is it really sane that this is needed when the unconfined_domain() macro is used? It doesn't really match the description given for that macro. Or should we file a bug with the upstream refpolicy?

Comment 6 Pierre Ossman 2019-01-08 13:59:34 UTC
I found some more commits on this theme upstream, and I've also reported the issue there:


Comment 7 Pierre Ossman 2019-01-08 16:08:14 UTC
For reference, the bug went away as I updated the system and dbus-daemon got replaced by dbus-broker.

If I'm reading the code and traces correctly, dbus-broker does not do a check on replies so this bug is avoided.