Bug 585186 - dbus replies blocked but not initial message
dbus replies blocked but not initial message
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE Security Team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-23 07:41 EDT by Pierre Ossman
Modified: 2010-08-24 12:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-24 09:24:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pierre Ossman 2010-04-23 07:41:58 EDT
Description of problem:
The policy for dbus causes the replies to certain messages to be blocked, but not the initial request. The result is that the blocked application never gets any error so it either hangs permanently or until it times out.

Version-Release number of selected component (if applicable):
selinux-policy-3.7.17-5.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Start a desktop session using ThinLinc
2. Start something using policy kit
  
Actual results:
Application hangs


Expected results:
Application gets some variation of "Access denied".


Additional info:
ThinLinc is a terminal server software that isn't SELinux aware. As such, the applications will have context unconfined_u:system_r:initrc_t:s0. This is the root of the problem, but the system should still be more well behaved in that it rejects stuff and not just drops things (from the view of the offending application).

audit.log from starting system-config-firewall:

type=USER_AVC msg=audit(1272022559.562:524): user pid=1281 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.348 spid=32335 tpid=6112 scontext=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1272022597.661:525): user pid=1281 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=error error_name=org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.firewall.auth dest=:1.348 spid=32335 tpid=6112 scontext=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'


This problem is also present on Fedora 13, which I guess shares most/all of the policy.
Comment 1 Pierre Ossman 2010-04-23 07:43:02 EDT
For Fedora 13 this is much worse as lots of desktop critical dbus replies are dropped resulting in temporary stalls all over the place.
Comment 3 Daniel Walsh 2010-04-23 09:05:47 EDT
What process is running as initrc_t?  Can we add a policy for this?  Does every dbus application need to be able to exchange messages with the terminal server?
Comment 4 RHEL Product and Program Management 2010-04-23 10:07:30 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 5 Pierre Ossman 2010-04-23 10:43:28 EDT
The process running as initrc_t is the one that spawns off new sessions:

unconfined_u:system_r:initrc_t:s0 4811 ?       Ss     0:13 python-thinlinc /opt/thinlinc/sbin/vsmagent

It's currently not more advanced than setting up the uid and gid, so no PAM and no SELinux magic that other login systems get.

(the authentication is handled elsewhere, hence the lack of PAM integration)

Anyway, I don't expect SELinux to really like these processes. The problem here is that the _reply_ rather than the _request_ get blocked. That means that it is dbus-daemon getting the error rather than the application that the user is running (which is really the one with the wrong selinux context). From the program's point of view, it's like the other end is ignoring the request.
Comment 6 Pierre Ossman 2010-04-23 10:48:09 EDT
(In reply to comment #3)
> Does every dbus application need to be able to exchange messages with the terminal server?    

Just to clarify this bit here. The terminal server is not involved with dbus at all. It's only reason for mention is that it is the reason we have the initrc_t context on every process. The interacting processes are the normal desktop applications and system services that are shipped with RHEL (in my example system-config-firewall, dbus-daemon and whatever backend actually modifies the iptables rules).
Comment 7 Daniel Walsh 2010-04-23 11:19:09 EDT
Pierre, initrc_t is an unconfined domain, (by default)  This means it can send dbus messages to any process.   Problem is a confined process is not allowed to send dbus messages back.  You can add a custom policy module that would allow this if you package is installed and that would fix the problem.  But I think the problem is users are logged in as initrc_t?

Because a user domain is trying to communicate with firewallgui_t.  And since the user is logged in with the wrong context you are getting problems.  Ping me on irc, so we can discuss this more easily.
Comment 8 Pierre Ossman 2010-04-23 13:23:34 EDT
Ah, I figured initrc_t was the low privilege domain. This does complicate things a bit...

You seem to have stepped out right now, but just grab me when you're back (nick: ossman).
Comment 9 Daniel Walsh 2010-06-02 14:53:45 EDT
This bug seems to have gotten lost in the weeds.

Pierre are you still having this problem.
Comment 10 Pierre Ossman 2010-06-03 08:21:13 EDT
I'm not seeing any updates for the RHEL 6 beta, so yes the problem is still there.

I'm on freenode most of the time, so just ping me if you want a more detailed description of the system.
Comment 11 Daniel Walsh 2010-06-16 11:15:11 EDT
You should see an updated policy now.
Comment 12 Pierre Ossman 2010-06-17 04:57:10 EDT
I'm afraid I'm not seeing it:

[root@rhel6beta ~]# yum list updates
Loaded plugins: refresh-packagekit, rhnplugin
This system is not registered with RHN.
RHN support will be disabled.
rhel-beta                                                | 3.7 kB     00:00     
rhel-beta-optional                                       | 3.0 kB     00:00     
[root@rhel6beta ~]# 

Can't see any way of successfully registering with RHN, if that's where the updates are hidden. Pointers appreciated.
Comment 13 Daniel Walsh 2010-06-18 10:44:48 EDT
Miroslav, do you know how the RHEL6 guys get updates?
Comment 14 Pierre Ossman 2010-06-28 05:56:39 EDT
Ping! Any update on how to get fixed packages?
Comment 15 Daniel Walsh 2010-06-28 10:03:26 EDT
Pierre can you grab the latest RHEL6 policy off of 

http://people.redhat.com/dwalsh/SELinux/RHEL6

And see if this problem is fixed.
Comment 17 Pierre Ossman 2010-07-02 08:12:09 EDT
No improvement I'm afraid.

First off, I had to upgrade checkpolicy to use the new policy files. Fortunately beta 2 was out so I could grab checkpolicy from there.

Upon installation I got these errors:

SELinux:  Could not load policy file /etc/selinux/targeted/policy/policy.24:  Invalid argument
/sbin/load_policy:  Can't load policy:  Invalid argument
libsemanage.semanage_reload_policy: load_policy returned error code 2.
SELinux:  Could not load policy file /etc/selinux/targeted/policy/policy.24:  Invalid argument
/sbin/load_policy:  Can't load policy:  Invalid argument
libsemanage.semanage_reload_policy: load_policy returned error code 2.
semodule:  Failed!

It was possible to run load_policy successfully after that though. For good measure I still rebooted the machine before testing though.

Still, the firewall gui locks up and I can find things like this in the audit log:

type=USER_AVC msg=audit(1278072595.629:29708): user pid=1255 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.54 spid=2601 tpid=2586 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1278072609.240:29721): user pid=1255 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.57 spid=2631 tpid=2629 scontext=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
Comment 18 Miroslav Grepl 2010-07-07 09:01:09 EDT
Pierre,
could you try to reinstall selinux-policy-targeted and make sure you don't see the same problem as above?
Comment 19 Daniel Walsh 2010-07-13 16:57:56 EDT
There is a kernel issue that is preventing you from loading policy.  I believe this is fixed in the latest RHEL6 kernels.

And I think the policy is fixed also.
Comment 20 Pierre Ossman 2010-08-19 07:47:23 EDT
Bug still here in beta 2 as far as I can tell. :/

$ rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.7.19-29.el6.noarch
selinux-policy-targeted-3.7.19-29.el6.noarch

Examples from audit.log:

type=USER_AVC msg=audit(1282217751.723:31): user pid=4356 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.52 spid=5351 tpid=5293 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

type=USER_AVC msg=audit(1282218269.458:54): user pid=4356 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.71 spid=5910 tpid=5908 scontext=system_u:system_r:firewallgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
Comment 21 Miroslav Grepl 2010-08-19 10:17:40 EDT
(In reply to comment #20)
> Bug still here in beta 2 as far as I can tell. :/

Does it mean you still get

SELinux:  Could not load policy file /etc/selinux/targeted/policy/policy.24: 
Invalid argument
..
...
....

errors.

> $ rpm -q selinux-policy selinux-policy-targeted
> selinux-policy-3.7.19-29.el6.noarch
> selinux-policy-targeted-3.7.19-29.el6.noarch
> 
> Examples from audit.log:
> 


Also what says 

# id -Z
Comment 22 Pierre Ossman 2010-08-19 11:38:31 EDT
I haven't tried an upgrade of the package since beta 2 has a newer policy than the one previously referenced. What I meant with the bug still being there is that replies from the dbus daemon are still blocked.
Comment 23 Eric Paris 2010-08-19 14:26:31 EDT
The kernel bug about EINVAL should be fixed in the latest kernels.  As to the SELinux denials I'm betting on a labeling problem.

What does ls -lZ /bin/dbus-daemon show?  If it is anything other than dbus_exec_t you can either run restorecon -R -v /bin and reboot or just touch /.autorelabel and reboot.

-Eric
Comment 24 Miroslav Grepl 2010-08-19 17:48:52 EDT
Also please attach your output of the following command

# id -Z

Thanks.
Comment 25 Pierre Ossman 2010-08-20 04:26:20 EDT
(In reply to comment #23)
> The kernel bug about EINVAL should be fixed in the latest kernels.  As to the
> SELinux denials I'm betting on a labeling problem.
> 
> What does ls -lZ /bin/dbus-daemon show?

$ ls -lZ /bin/dbus-daemon 
-rwxr-xr-x. root root system_u:object_r:dbusd_exec_t:s0 /bin/dbus-daemon

In case you skimmed the rest of the bug, I'd like to point out that this isn't a "normal" login but via a third-party software that isn't SELinux aware. It's that non-SELinux backwards compatibility that's a bit lacking.
Comment 26 Pierre Ossman 2010-08-20 04:27:49 EDT
(In reply to comment #24)
> Also please attach your output of the following command
> 
> # id -Z

$ id -Z
system_u:system_r:initrc_t:s0
Comment 27 Daniel Walsh 2010-08-23 13:52:55 EDT
This means you are currently logged in as initrc_t?  Which means something is going wrong in your login process?  Or are you booting single user mode?  How did you login to this box?
Comment 28 Miroslav Grepl 2010-08-23 15:40:55 EDT
It looks like a problem with login how Pierre wrote above.

> I'd like to point out that this isn't a "normal" login but via a third-party software that isn't SELinux aware.
Comment 29 Daniel Walsh 2010-08-23 15:51:23 EDT
Then that software needs to use pam_selinux.so to set the proper selinux context.
Comment 30 Daniel Walsh 2010-08-23 15:52:43 EDT
One other option would be to setup the account to use sushell, which should transition initrc_t to unconfined_t.
Comment 32 Pierre Ossman 2010-08-24 04:38:37 EDT
If system_dbusd_t isn't allowed to send to initrc_t, then we can't you just forbid initrc_t to send to system_dbus_t? That would avoid the hangs and timeouts as the applications would get an error back immediately.

And even though it would be nice if everybody hopped on the SELinux bandwagon, that just isn't reality yet. Saying that it is a hard requirement for third party applications just adds fodder to the "SELinux is that thing that breaks your system" crowd.

Is there no tunable that could resolve this? Or labling the software with something label for "third-party program that spawns user sessions"?
Comment 33 Daniel Walsh 2010-08-24 09:24:22 EDT
The problem here is that you are logging in as initrc_t.  This is going to cause all sorts of problems.  You will see things like the session bus running as system_dbus_t, which is what I think you are seeing.  Other apps are going to transition where they would not if you logged in as a normal user unconfined_t, staff_t, user_t etc.  

Since you are running as initrc_t lots of services that are allowed to send messages to unconfined_t and other user domains are going to be sending them to initrc_t.  Fix your log in program and then report other problems.

Note You need to log in before you can comment on or make changes to this bug.