2011-01-12 21:32:10

by Guido Trentalancia

[permalink] [raw]
Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

Hello,

I have just built and installed refpolicy-2.20101213 (mcs) but I get
problems with dbus, such as the following:

Jan 11 18:54:04 tesla gnome-session[2744]: WARNING: Could not connect to
ConsoleKit: An SELinux policy prevents this sender from sending this
message to this recipient (rejected message had sender "(unset)"
interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
destination "org.freedesktop.DBus")
Jan 11 07:41:59 tesla gdm-binary[2513]: WARNING: Couldn't connect to
system bus: An SELinux policy prevents this sender from sending this
message to this recipient (rejected message had sender "(unset)"
interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
destination "org.freedesktop.DBus")
Jan 12 21:58:29 tesla pulseaudio[31181]: hal-util.c: Unable to contact
DBUS system bus: org.freedesktop.DBus.Error.AccessDenied: An SELinux
policy prevents this sender from sending this message to this recipient
(rejected message had sender "(unset)" interface "org.freedesktop.DBus"
member "Hello" error name "(unset)" destination "org.freedesktop.DBus")

or in terms of audit, things like:

type=USER_AVC msg=audit(1294728121.875:414): user pid=6167 uid=81
auid=4294967295 ses=4294967295
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
{ send_msg } for msgtype=method_call interface=org.freedesktop.DBus
member=Hello dest=org.freedesktop.DBus spid=6211
scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1294728121.925:415): user pid=6167 uid=81
auid=4294967295 ses=4294967295
subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
{ send_msg } for msgtype=method_call interface=org.freedesktop.DBus
member=Hello dest=org.freedesktop.DBus spid=6222
scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

Now, the dbus module is loaded:

dbus 1.14.0

I had to relabel /sbin/upstart by modifying the default contexts. In
fact, nowadays /sbin/init is often a symlink to /sbin/upstart (see
Debian, Fedora and possibly others) but unfortunately this is not
contemplated in the default file_contexts.

Anyway, after relabelling /sbin/upstart sestatus also looks fine:

SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: permissive
Policy version: 24
Policy from config file: refpolicy-mcs

Process contexts:
Current context:
system_u:system_r:local_login_t:s0-s0:c0.c1023
Init context: system_u:system_r:init_t:s0
/sbin/mingetty system_u:system_r:getty_t:s0

So, what is missing ? Any idea on how to sort this out would be greatly
appreciated !

Regards,

Guido


2011-01-13 09:19:20

by domg472

[permalink] [raw]
Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/2011 10:32 PM, Guido Trentalancia wrote:
> Hello,
>
> I have just built and installed refpolicy-2.20101213 (mcs) but I get
> problems with dbus, such as the following:
>
> Jan 11 18:54:04 tesla gnome-session[2744]: WARNING: Could not connect to
> ConsoleKit: An SELinux policy prevents this sender from sending this
> message to this recipient (rejected message had sender "(unset)"
> interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
> destination "org.freedesktop.DBus")
> Jan 11 07:41:59 tesla gdm-binary[2513]: WARNING: Couldn't connect to
> system bus: An SELinux policy prevents this sender from sending this
> message to this recipient (rejected message had sender "(unset)"
> interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
> destination "org.freedesktop.DBus")
> Jan 12 21:58:29 tesla pulseaudio[31181]: hal-util.c: Unable to contact
> DBUS system bus: org.freedesktop.DBus.Error.AccessDenied: An SELinux
> policy prevents this sender from sending this message to this recipient
> (rejected message had sender "(unset)" interface "org.freedesktop.DBus"
> member "Hello" error name "(unset)" destination "org.freedesktop.DBus")
>
> or in terms of audit, things like:
>
> type=USER_AVC msg=audit(1294728121.875:414): user pid=6167 uid=81
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
> { send_msg } for msgtype=method_call interface=org.freedesktop.DBus
> member=Hello dest=org.freedesktop.DBus spid=6211
> scontext=system_u:system_r:initrc_t:s0
> tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> type=USER_AVC msg=audit(1294728121.925:415): user pid=6167 uid=81
> auid=4294967295 ses=4294967295
> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
> { send_msg } for msgtype=method_call interface=org.freedesktop.DBus
> member=Hello dest=org.freedesktop.DBus spid=6222
> scontext=system_u:system_r:initrc_t:s0
> tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>
> Now, the dbus module is loaded:
>
> dbus 1.14.0
>
> I had to relabel /sbin/upstart by modifying the default contexts. In
> fact, nowadays /sbin/init is often a symlink to /sbin/upstart (see
> Debian, Fedora and possibly others) but unfortunately this is not
> contemplated in the default file_contexts.
>
> Anyway, after relabelling /sbin/upstart sestatus also looks fine:
>
> SELinux status: enabled
> SELinuxfs mount: /selinux
> Current mode: enforcing
> Mode from config file: permissive
> Policy version: 24
> Policy from config file: refpolicy-mcs
>
> Process contexts:
> Current context:
> system_u:system_r:local_login_t:s0-s0:c0.c1023
> Init context: system_u:system_r:init_t:s0
> /sbin/mingetty system_u:system_r:getty_t:s0
>
> So, what is missing ? Any idea on how to sort this out would be greatly
> appreciated !

Something runs in initrc_t where it probably should not. Could well be
the dbus system bus. I do not know. ps auxZ | grep initrc_t would
probably reveal it.

Once its determined which process runs initrc_t, you can target your
troubleshoot efforts to this process.
>
> Regards,
>
> Guido
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0uw5gACgkQMlxVo39jgT/xiQCgxKBe3e2bqSYo6QvDTH3HgQJs
iB8AnAkGefZcGAI1ULL5XgkeEGOLWhlQ
=MJL+
-----END PGP SIGNATURE-----

2011-01-13 12:25:31

by Guido Trentalancia

[permalink] [raw]
Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

Hello Dominick and thanks very much for your message !

The problem appears to be mostly sorted out now. The point is that I am
not able to reproduce it again.

As far as I remember, there were only a wrong PAM file for gdm and an
old dbus-daemon-launch-helper in /usr/libexec. But then reverting back
those changes doesn't reproduce the problem.

In any case at the moment nothing except init runs in any init* context.

But there is still something interesting to speculate. The main effect
of the problem as I had originally reported was that it was not possible
to login into gdm which I use as the graphical login manager.

What is worrying is that when the init binary was not labelled correctly
and thus init/upstart was running in a wrong context (something like
system_u:system_r:insmod_t as far as I can remember) it was possible to
login into gdm. If you remember I mentioned in my original message about
the fact that refpolicy unfortunately does not yet label /sbin/upstart
correctly because it's missing from the default file_contexts...

This is quite worrying.

So, despite init was running in a wrong context (and despite the wrong
gdm PAM file), it was still possible to login into gdm while it wasn't
possible when init was running in the proper context...

However, in the current situation I am still getting some USER_AVC
"denied" send_msg about dbus messages (in the audit log only). At a very
quick first check, at least some of those messages should have been
allowed according to /etc/dbus-1/system.d/* policies. I now need to look
at that in more detail. In general what should be done if those messages
are allowed by dbus policies but then are (mysteriously) denied by
SELinux ?

Best regards,

Guido Trentalancia

On Thu, 13/01/2011 at 10.19 +0100, Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/12/2011 10:32 PM, Guido Trentalancia wrote:
> > Hello,
> >
> > I have just built and installed refpolicy-2.20101213 (mcs) but I get
> > problems with dbus, such as the following:
> >
> > Jan 11 18:54:04 tesla gnome-session[2744]: WARNING: Could not connect to
> > ConsoleKit: An SELinux policy prevents this sender from sending this
> > message to this recipient (rejected message had sender "(unset)"
> > interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
> > destination "org.freedesktop.DBus")
> > Jan 11 07:41:59 tesla gdm-binary[2513]: WARNING: Couldn't connect to
> > system bus: An SELinux policy prevents this sender from sending this
> > message to this recipient (rejected message had sender "(unset)"
> > interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
> > destination "org.freedesktop.DBus")
> > Jan 12 21:58:29 tesla pulseaudio[31181]: hal-util.c: Unable to contact
> > DBUS system bus: org.freedesktop.DBus.Error.AccessDenied: An SELinux
> > policy prevents this sender from sending this message to this recipient
> > (rejected message had sender "(unset)" interface "org.freedesktop.DBus"
> > member "Hello" error name "(unset)" destination "org.freedesktop.DBus")
> >
> > or in terms of audit, things like:
> >
> > type=USER_AVC msg=audit(1294728121.875:414): user pid=6167 uid=81
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
> > { send_msg } for msgtype=method_call interface=org.freedesktop.DBus
> > member=Hello dest=org.freedesktop.DBus spid=6211
> > scontext=system_u:system_r:initrc_t:s0
> > tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> > type=USER_AVC msg=audit(1294728121.925:415): user pid=6167 uid=81
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
> > { send_msg } for msgtype=method_call interface=org.freedesktop.DBus
> > member=Hello dest=org.freedesktop.DBus spid=6222
> > scontext=system_u:system_r:initrc_t:s0
> > tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >
> > Now, the dbus module is loaded:
> >
> > dbus 1.14.0
> >
> > I had to relabel /sbin/upstart by modifying the default contexts. In
> > fact, nowadays /sbin/init is often a symlink to /sbin/upstart (see
> > Debian, Fedora and possibly others) but unfortunately this is not
> > contemplated in the default file_contexts.
> >
> > Anyway, after relabelling /sbin/upstart sestatus also looks fine:
> >
> > SELinux status: enabled
> > SELinuxfs mount: /selinux
> > Current mode: enforcing
> > Mode from config file: permissive
> > Policy version: 24
> > Policy from config file: refpolicy-mcs
> >
> > Process contexts:
> > Current context:
> > system_u:system_r:local_login_t:s0-s0:c0.c1023
> > Init context: system_u:system_r:init_t:s0
> > /sbin/mingetty system_u:system_r:getty_t:s0
> >
> > So, what is missing ? Any idea on how to sort this out would be greatly
> > appreciated !
>
> Something runs in initrc_t where it probably should not. Could well be
> the dbus system bus. I do not know. ps auxZ | grep initrc_t would
> probably reveal it.
>
> Once its determined which process runs initrc_t, you can target your
> troubleshoot efforts to this process.
> >
> > Regards,
> >
> > Guido
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0uw5gACgkQMlxVo39jgT/xiQCgxKBe3e2bqSYo6QvDTH3HgQJs
> iB8AnAkGefZcGAI1ULL5XgkeEGOLWhlQ
> =MJL+
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>

2011-01-13 12:34:22

by domg472

[permalink] [raw]
Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2011 01:25 PM, Guido Trentalancia wrote:
> Hello Dominick and thanks very much for your message !
>
> The problem appears to be mostly sorted out now. The point is that I am
> not able to reproduce it again.
>
> As far as I remember, there were only a wrong PAM file for gdm and an
> old dbus-daemon-launch-helper in /usr/libexec. But then reverting back
> those changes doesn't reproduce the problem.
>
> In any case at the moment nothing except init runs in any init* context.
>
> But there is still something interesting to speculate. The main effect
> of the problem as I had originally reported was that it was not possible
> to login into gdm which I use as the graphical login manager.
>
> What is worrying is that when the init binary was not labelled correctly
> and thus init/upstart was running in a wrong context (something like
> system_u:system_r:insmod_t as far as I can remember) it was possible to
> login into gdm. If you remember I mentioned in my original message about
> the fact that refpolicy unfortunately does not yet label /sbin/upstart
> correctly because it's missing from the default file_contexts...

I sincerely doubt that, but then again i may be wrong. Can you reproduce
this?

> This is quite worrying.
>
> So, despite init was running in a wrong context (and despite the wrong
> gdm PAM file), it was still possible to login into gdm while it wasn't
> possible when init was running in the proper context...
>
> However, in the current situation I am still getting some USER_AVC
> "denied" send_msg about dbus messages (in the audit log only). At a very
> quick first check, at least some of those messages should have been
> allowed according to /etc/dbus-1/system.d/* policies. I now need to look
> at that in more detail. In general what should be done if those messages
> are allowed by dbus policies but then are (mysteriously) denied by
> SELinux ?

There should not be anything mysterious about SELinux. I will not
speculate as to your specific issue. I would need to see the AVC denials
to be able to make a decent suggestion.

I will however say that you also have to be aware of any constraints
that may influence access decisions (not only type enforcement)

> Best regards,
>
> Guido Trentalancia
>
> On Thu, 13/01/2011 at 10.19 +0100, Dominick Grift wrote:
> On 01/12/2011 10:32 PM, Guido Trentalancia wrote:
>>>> Hello,
>>>>
>>>> I have just built and installed refpolicy-2.20101213 (mcs) but I get
>>>> problems with dbus, such as the following:
>>>>
>>>> Jan 11 18:54:04 tesla gnome-session[2744]: WARNING: Could not connect to
>>>> ConsoleKit: An SELinux policy prevents this sender from sending this
>>>> message to this recipient (rejected message had sender "(unset)"
>>>> interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
>>>> destination "org.freedesktop.DBus")
>>>> Jan 11 07:41:59 tesla gdm-binary[2513]: WARNING: Couldn't connect to
>>>> system bus: An SELinux policy prevents this sender from sending this
>>>> message to this recipient (rejected message had sender "(unset)"
>>>> interface "org.freedesktop.DBus" member "Hello" error name "(unset)"
>>>> destination "org.freedesktop.DBus")
>>>> Jan 12 21:58:29 tesla pulseaudio[31181]: hal-util.c: Unable to contact
>>>> DBUS system bus: org.freedesktop.DBus.Error.AccessDenied: An SELinux
>>>> policy prevents this sender from sending this message to this recipient
>>>> (rejected message had sender "(unset)" interface "org.freedesktop.DBus"
>>>> member "Hello" error name "(unset)" destination "org.freedesktop.DBus")
>>>>
>>>> or in terms of audit, things like:
>>>>
>>>> type=USER_AVC msg=audit(1294728121.875:414): user pid=6167 uid=81
>>>> auid=4294967295 ses=4294967295
>>>> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
>>>> { send_msg } for msgtype=method_call interface=org.freedesktop.DBus
>>>> member=Hello dest=org.freedesktop.DBus spid=6211
>>>> scontext=system_u:system_r:initrc_t:s0
>>>> tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>> type=USER_AVC msg=audit(1294728121.925:415): user pid=6167 uid=81
>>>> auid=4294967295 ses=4294967295
>>>> subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied
>>>> { send_msg } for msgtype=method_call interface=org.freedesktop.DBus
>>>> member=Hello dest=org.freedesktop.DBus spid=6222
>>>> scontext=system_u:system_r:initrc_t:s0
>>>> tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> Now, the dbus module is loaded:
>>>>
>>>> dbus 1.14.0
>>>>
>>>> I had to relabel /sbin/upstart by modifying the default contexts. In
>>>> fact, nowadays /sbin/init is often a symlink to /sbin/upstart (see
>>>> Debian, Fedora and possibly others) but unfortunately this is not
>>>> contemplated in the default file_contexts.
>>>>
>>>> Anyway, after relabelling /sbin/upstart sestatus also looks fine:
>>>>
>>>> SELinux status: enabled
>>>> SELinuxfs mount: /selinux
>>>> Current mode: enforcing
>>>> Mode from config file: permissive
>>>> Policy version: 24
>>>> Policy from config file: refpolicy-mcs
>>>>
>>>> Process contexts:
>>>> Current context:
>>>> system_u:system_r:local_login_t:s0-s0:c0.c1023
>>>> Init context: system_u:system_r:init_t:s0
>>>> /sbin/mingetty system_u:system_r:getty_t:s0
>>>>
>>>> So, what is missing ? Any idea on how to sort this out would be greatly
>>>> appreciated !
>
> Something runs in initrc_t where it probably should not. Could well be
> the dbus system bus. I do not know. ps auxZ | grep initrc_t would
> probably reveal it.
>
> Once its determined which process runs initrc_t, you can target your
> troubleshoot efforts to this process.
>>>>
>>>> Regards,
>>>>
>>>> Guido
>>>>
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0u8U4ACgkQMlxVo39jgT9ovgCgiX9NIppCPWEjvCYni5/yTn9I
O30An1jLL1RF0Dv/dmC0Bdvh1ucb2zr5
=aIak
-----END PGP SIGNATURE-----