From: guido@trentalancia.com (Guido Trentalancia)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages
Date: Thu, 13 Jan 2011 13:25:31 +0100 [thread overview]
Message-ID: <1294921531.3112.18.camel@tesla.lan> (raw)
In-Reply-To: <4D2EC398.7060304@gmail.com>
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
>
next prev parent reply other threads:[~2011-01-13 12:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-12 21:32 [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages Guido Trentalancia
2011-01-13 9:19 ` Dominick Grift
2011-01-13 12:25 ` Guido Trentalancia [this message]
2011-01-13 12:34 ` Dominick Grift
[not found] ` <1294931759.3153.25.camel@tesla.lan>
2011-01-13 15:38 ` Dominick Grift
2011-01-13 19:24 ` Guido Trentalancia
2011-01-13 19:57 ` Dominick Grift
2011-01-13 21:37 ` Guido Trentalancia
2011-01-13 21:43 ` Dominick Grift
2011-01-13 23:15 ` Guido Trentalancia
2011-01-14 9:34 ` Dominick Grift
2011-01-14 14:27 ` Guido Trentalancia
2011-01-14 14:36 ` Dominick Grift
2011-01-14 14:55 ` Guido Trentalancia
2011-01-15 15:06 ` Guido Trentalancia
-- strict thread matches above, loose matches on Subject: below --
2011-01-13 15:21 Guido Trentalancia
2011-01-13 15:45 ` Dominick Grift
2011-01-13 19:49 ` Guido Trentalancia
2011-01-13 18:51 ` Dominick Grift
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1294921531.3112.18.camel@tesla.lan \
--to=guido@trentalancia.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.