Bug 585186

For Fedora 13 this is much worse as lots of desktop critical dbus replies are dropped resulting in temporary stalls all over the place.

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?

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.

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.

(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).

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.

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).

This bug seems to have gotten lost in the weeds.

Pierre are you still having this problem.

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.

You should see an updated policy now.

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.

Miroslav, do you know how the RHEL6 guys get updates?

Ping! Any update on how to get fixed packages?

Pierre can you grab the latest RHEL6 policy off of 

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

And see if this problem is fixed.

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=?'

Pierre,
could you try to reinstall selinux-policy-targeted and make sure you don't see the same problem as above?

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.

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=?'

(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

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.

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

Also please attach your output of the following command

# id -Z

Thanks.

(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.

(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

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?

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.

Then that software needs to use pam_selinux.so to set the proper selinux context.

One other option would be to setup the account to use sushell, which should transition initrc_t to unconfined_t.

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"?

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.