[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hello again Dominick !

On Thu, 13/01/2011 at 13.34 +0100, Dominick Grift wrote:
> -----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?

Yes confirmed and it can be easily reproduced.

When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
would happen with an unmodified refpolicy-2.20101213, sestatus reports:

Process contexts:
Current context:                system_u:system_r:kernel_t:s0
Init context:                   system_u:system_r:kernel_t:s0
/sbin/mingetty                  system_u:system_r:kernel_t:s0

But the system appears to run even "better" than when init correctly
transitions into its proper context !

I believe in other cases, for some reason that is not evident now, the
context was system_u:system_r:insmod_t with a completely similar effect.

So, for example, with the wrong init context, not only it is possible to
login into gdm, but also things that were broken with the right init
context works perfectly fine. A few examples: gedit, evince,
gnome-terminal and openoffice refusing to start up without leaving any
trace of denied AVCs in the audit logs and finally no more denied
send_msg with dbus !

The output of ps auxZ in this case ? Everything runs in
system_u:system_r:kernel_t:s0 context apart from udev.

What do you say ?

Is this not a sort of security-flaw ? Someone manages to
relabel /sbin/init and then nobody checks that in enforcing mode init
has effectively re-executed itself in the proper context ?

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

These are some examples of the USER_AVC denials (when init is running in
the proper context and the system has a few problems):

type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
dest=org.freedesktop.Hal spid=2928 tpid=2314
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
dest=org.freedesktop.Hal spid=2868 tpid=2314
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
dest=org.freedesktop.Hal spid=2868 tpid=2314
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
interface=org.freedesktop.PolicyKit1.Authority member=Changed
dest=org.freedesktop.DBus spid=2613 tpid=2546
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
interface=org.freedesktop.DBus.Properties member=GetAll
dest=org.freedesktop.UDisks spid=3567 tpid=3569
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
terminal=?'

At this point is probably pointless that I bother looking
into /etc/dbus-1/system.d configuration files because it seems something
which depends only on the SELinux policy.

> 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

Thanks again for offering your advice.

Regards,

Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/13/2011 04:21 PM, Guido Trentalancia wrote:
> Hello again Dominick !

You should, if possible, use policy that is distributed by your distro.

refpolicy is a general purpose base policy. Ir is not tailored to any
specific distro. It serves as a base for distribution to base their
policy off.

Unless you are familiar with policy design/implementation, it is
probably best to not use plain reference policy.

> On Thu, 13/01/2011 at 13.34 +0100, Dominick Grift wrote:
>> -----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?
> 
> Yes confirmed and it can be easily reproduced.
> 
> When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
> would happen with an unmodified refpolicy-2.20101213, sestatus reports:
> 
> Process contexts:
> Current context:                system_u:system_r:kernel_t:s0
> Init context:                   system_u:system_r:kernel_t:s0
> /sbin/mingetty                  system_u:system_r:kernel_t:s0
> 
> But the system appears to run even "better" than when init correctly
> transitions into its proper context !
> 
> I believe in other cases, for some reason that is not evident now, the
> context was system_u:system_r:insmod_t with a completely similar effect.
> 
> So, for example, with the wrong init context, not only it is possible to
> login into gdm, but also things that were broken with the right init
> context works perfectly fine. A few examples: gedit, evince,
> gnome-terminal and openoffice refusing to start up without leaving any
> trace of denied AVCs in the audit logs and finally no more denied
> send_msg with dbus !
> 
> The output of ps auxZ in this case ? Everything runs in
> system_u:system_r:kernel_t:s0 context apart from udev.
> 
> What do you say ?
> 
> Is this not a sort of security-flaw ? Someone manages to
> relabel /sbin/init and then nobody checks that in enforcing mode init
> has effectively re-executed itself in the proper context ?
> 
>>> 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.
> 
> These are some examples of the USER_AVC denials (when init is running in
> the proper context and the system has a few problems):
> 
> type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> dest=org.freedesktop.Hal spid=2928 tpid=2314
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> dest=org.freedesktop.Hal spid=2868 tpid=2314
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> dest=org.freedesktop.Hal spid=2868 tpid=2314
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
> interface=org.freedesktop.PolicyKit1.Authority member=Changed
> dest=org.freedesktop.DBus spid=2613 tpid=2546
> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
> interface=org.freedesktop.DBus.Properties member=GetAll
> dest=org.freedesktop.UDisks spid=3567 tpid=3569
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> terminal=?'
> 
> At this point is probably pointless that I bother looking
> into /etc/dbus-1/system.d configuration files because it seems something
> which depends only on the SELinux policy.
> 
>> 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
> 
> Thanks again for offering your advice.
> 
> 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/

iEYEARECAAYFAk0vHhgACgkQMlxVo39jgT+YwQCgmtq/W3hWHOdsJbmQQYng/6BG
qNkAoLkPFCf2kHI+aLZp3fBbxk7twoZ0
=nsDh
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/13/2011 08:49 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> On Thu, 13/01/2011 at 16.45 +0100, Dominick Grift wrote:
> On 01/13/2011 04:21 PM, Guido Trentalancia wrote:
>>>> Hello again Dominick !
> 
> You should, if possible, use policy that is distributed by your distro.
> 
>> I am not using any of the publicly available distribution. I have
>> created my own installation. Therefore I would need to start from
>> scratch and use refpolicy.
> 
> refpolicy is a general purpose base policy. Ir is not tailored to any
> specific distro. It serves as a base for distribution to base their
> policy off.
> 
>> Yes, I can start developing a customised policy if time allows but I
>> need to start with refpolicy first.
> 
> Unless you are familiar with policy design/implementation, it is
> probably best to not use plain reference policy.
> 
>> Again, see above.
> 
>> But then, what is your comment on the USER_AVC logs that I posted ?

my comment is that this functionality is currently not supported by
reference policy and that i would probably extend/modify reference
policy to allow this access.

>> Regards,
> 
>> Guido
> 
>>>> On Thu, 13/01/2011 at 13.34 +0100, Dominick Grift wrote:
>>>>> -----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?
>>>>
>>>> Yes confirmed and it can be easily reproduced.
>>>>
>>>> When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
>>>> would happen with an unmodified refpolicy-2.20101213, sestatus reports:
>>>>
>>>> Process contexts:
>>>> Current context:                system_u:system_r:kernel_t:s0
>>>> Init context:                   system_u:system_r:kernel_t:s0
>>>> /sbin/mingetty                  system_u:system_r:kernel_t:s0
>>>>
>>>> But the system appears to run even "better" than when init correctly
>>>> transitions into its proper context !
>>>>
>>>> I believe in other cases, for some reason that is not evident now, the
>>>> context was system_u:system_r:insmod_t with a completely similar effect.
>>>>
>>>> So, for example, with the wrong init context, not only it is possible to
>>>> login into gdm, but also things that were broken with the right init
>>>> context works perfectly fine. A few examples: gedit, evince,
>>>> gnome-terminal and openoffice refusing to start up without leaving any
>>>> trace of denied AVCs in the audit logs and finally no more denied
>>>> send_msg with dbus !
>>>>
>>>> The output of ps auxZ in this case ? Everything runs in
>>>> system_u:system_r:kernel_t:s0 context apart from udev.
>>>>
>>>> What do you say ?
>>>>
>>>> Is this not a sort of security-flaw ? Someone manages to
>>>> relabel /sbin/init and then nobody checks that in enforcing mode init
>>>> has effectively re-executed itself in the proper context ?
>>>>
>>>>>> 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.
>>>>
>>>> These are some examples of the USER_AVC denials (when init is running in
>>>> the proper context and the system has a few problems):
>>>>
>>>> type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>> dest=org.freedesktop.Hal spid=2928 tpid=2314
>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>> dest=org.freedesktop.Hal spid=2868 tpid=2314
>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>> dest=org.freedesktop.Hal spid=2868 tpid=2314
>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
>>>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
>>>> dest=org.freedesktop.DBus spid=2613 tpid=2546
>>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
>>>> interface=org.freedesktop.DBus.Properties member=GetAll
>>>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
>>>> terminal=?'
>>>>
>>>> At this point is probably pointless that I bother looking
>>>> into /etc/dbus-1/system.d configuration files because it seems something
>>>> which depends only on the SELinux policy.
>>>>
>>>>> 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
>>>>
>>>> Thanks again for offering your advice.
>>>>
>>>> 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/

iEYEARECAAYFAk0vSb8ACgkQMlxVo39jgT97RwCfWxg2AFr4V5Jud4OoIgBHSn/P
hHMAoKxzUDYE2JhuFD9K87dgg+2BkjHh
=DonV
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hello Dominick !

On Thu, 13/01/2011 at 16.45 +0100, Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/13/2011 04:21 PM, Guido Trentalancia wrote:
> > Hello again Dominick !
> 
> You should, if possible, use policy that is distributed by your distro.

I am not using any of the publicly available distribution. I have
created my own installation. Therefore I would need to start from
scratch and use refpolicy.

> refpolicy is a general purpose base policy. Ir is not tailored to any
> specific distro. It serves as a base for distribution to base their
> policy off.

Yes, I can start developing a customised policy if time allows but I
need to start with refpolicy first.

> Unless you are familiar with policy design/implementation, it is
> probably best to not use plain reference policy.

Again, see above.

But then, what is your comment on the USER_AVC logs that I posted ?

Regards,

Guido

> > On Thu, 13/01/2011 at 13.34 +0100, Dominick Grift wrote:
> >> -----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?
> > 
> > Yes confirmed and it can be easily reproduced.
> > 
> > When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
> > would happen with an unmodified refpolicy-2.20101213, sestatus reports:
> > 
> > Process contexts:
> > Current context:                system_u:system_r:kernel_t:s0
> > Init context:                   system_u:system_r:kernel_t:s0
> > /sbin/mingetty                  system_u:system_r:kernel_t:s0
> > 
> > But the system appears to run even "better" than when init correctly
> > transitions into its proper context !
> > 
> > I believe in other cases, for some reason that is not evident now, the
> > context was system_u:system_r:insmod_t with a completely similar effect.
> > 
> > So, for example, with the wrong init context, not only it is possible to
> > login into gdm, but also things that were broken with the right init
> > context works perfectly fine. A few examples: gedit, evince,
> > gnome-terminal and openoffice refusing to start up without leaving any
> > trace of denied AVCs in the audit logs and finally no more denied
> > send_msg with dbus !
> > 
> > The output of ps auxZ in this case ? Everything runs in
> > system_u:system_r:kernel_t:s0 context apart from udev.
> > 
> > What do you say ?
> > 
> > Is this not a sort of security-flaw ? Someone manages to
> > relabel /sbin/init and then nobody checks that in enforcing mode init
> > has effectively re-executed itself in the proper context ?
> > 
> >>> 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.
> > 
> > These are some examples of the USER_AVC denials (when init is running in
> > the proper context and the system has a few problems):
> > 
> > type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2928 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> > 
> > type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2868 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> > 
> > type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2868 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> > 
> > type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
> > interface=org.freedesktop.PolicyKit1.Authority member=Changed
> > dest=org.freedesktop.DBus spid=2613 tpid=2546
> > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> > 
> > type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
> > interface=org.freedesktop.DBus.Properties member=GetAll
> > dest=org.freedesktop.UDisks spid=3567 tpid=3569
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> > terminal=?'
> > 
> > At this point is probably pointless that I bother looking
> > into /etc/dbus-1/system.d configuration files because it seems something
> > which depends only on the SELinux policy.
> > 
> >> 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
> > 
> > Thanks again for offering your advice.
> > 
> > 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/
> 
> iEYEARECAAYFAk0vHhgACgkQMlxVo39jgT+YwQCgmtq/W3hWHOdsJbmQQYng/6BG
> qNkAoLkPFCf2kHI+aLZp3fBbxk7twoZ0
> =nsDh
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
> 

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hello Dominick,

just a quick note, to correct myself.

On Fri, 14/01/2011 at 10.34 +0100, Dominick Grift wrote:
> > On Thu, 13/01/2011 at 22.43 +0100, Dominick Grift wrote:
> >>> But in general for USER_AVCs there is nothing like audit2allow that can
> >>> be used to ease the job ?
> >>
> >> audit2allow can also be used for these dbus AVC' s sure. But if you want
> >> this stuff upstreamed then you will have to play by upstreams rules
> >> (style rules)
> > 
> > No, apparently audit2allow doesn't do the job for USER_AVCs.
> 
> Strange, in that case i guess you will have to translate it manually.

Of course, audit2allow also works on USER_AVC audit messages !

So the other day, either the formatting went lost, because I was doing
copy&paste from the full audit logs to newly created partial logs, or
otherwise I had used illegal characters such as underscore in partial
log file names thus breaking up the script that I am using and which
generates module names from file names...

Sorry about that.

Regards,

Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

On Fri, 14/01/2011 at 15.36 +0100, Dominick Grift wrote:
> >> Strange, in that case i guess you will have to translate it manually.
> >>
> >> 1.
> >>
> >> AVC denial:
> >>
> >>>> denied  { send_msg } for msgtype=method_call
> >>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> >>>> dest=org.freedesktop.Hal spid=2928 tpid=2314
> >>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> >>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>
> >> Raw policy:
> >>
> >> allow xdm_t hald_t:dbus send_msg;
> >>
> >> Possible macro/interface:
> >>
> >> hal_dbus_chat(xdm_t)
> >>
> >> 2.
> >>
> >>>> denied  { send_msg } for msgtype=signal
> >>>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
> >>>> dest=org.freedesktop.DBus spid=2613 tpid=2546
> >>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> >>>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> >>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>>>
> >>
> >> Raw policy:
> >>
> >> allow system_dbusd_t consolekit_t:dbus send_msg;
> >>
> >> Possible macro/interface:
> >>
> >> consolekit_dbus_chat(system_dbusd_t)
> >>
> >> 3.
> >>
> >>>> denied  { send_msg } for msgtype=method_call
> >>>> interface=org.freedesktop.DBus.Properties member=GetAll
> >>>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
> >>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> >>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> >>>> terminal=?'
> >>
> >> Raw policy:
> >>
> >> allow xdm_t devicekit_disk_t:dbus send_msg;
> >>
> >> Possible macro/interface:
> >>
> >> devicekit_dbus_chat_disk(xdm_t)

Yes, the new modules work perfectly ! We absolutely need to get this
stuff upstreamed into the next refpolicy (see also last point of this
message).

> > By the way, I have also noticed that for some reason user_dmesg is not
> > being effectively enforced. The user_dmesg boolean is set to false, the
> > dmesg module is loaded, the system is in enforcing mode, still a normal
> > user is able to use dmesg...
> 
> "Normal" users are not constraint by user_dmesg i believe. Its only for
> restricted users

Fair play then. I think the latest kernel 2.6.37 might have something
new from that point of view (CONFIG_SECURITY_DMESG_RESTRICT) but I had
no time to check it through-fully.

> > And last but not least, I have already mentioned about a few graphical
> > applications that refuse to start without leaving any trace in the logs.
> > Namely these are: gnome-terminal, gedit, evince and openoffice (not the
> > execstack issue in this last case). What can be done if nothing appears
> > in the logs ? How do I get to know what has been denied ?
> 
> semodule -DB to unload hidden denial rules
> semodule -B to re-insert hidden denial rules

Everything has been sorted out now. So everything was just depending on
dbus messages not being sent.

I shall really produce a patch in terms of policy as soon as possible.

All the best,

Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/14/2011 03:27 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> On Fri, 14/01/2011 at 10.34 +0100, Dominick Grift wrote:
>>> Hi Dominick !
>>>
>>> On Thu, 13/01/2011 at 22.43 +0100, Dominick Grift wrote:
>>>>> But in general for USER_AVCs there is nothing like audit2allow that can
>>>>> be used to ease the job ?
>>>>
>>>> audit2allow can also be used for these dbus AVC' s sure. But if you want
>>>> this stuff upstreamed then you will have to play by upstreams rules
>>>> (style rules)
>>>
>>> No, apparently audit2allow doesn't do the job for USER_AVCs.
>>
>> Strange, in that case i guess you will have to translate it manually.
>>
>> 1.
>>
>> AVC denial:
>>
>>>> denied  { send_msg } for msgtype=method_call
>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>> dest=org.freedesktop.Hal spid=2928 tpid=2314
>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>
>> Raw policy:
>>
>> allow xdm_t hald_t:dbus send_msg;
>>
>> Possible macro/interface:
>>
>> hal_dbus_chat(xdm_t)
>>
>> 2.
>>
>>>> denied  { send_msg } for msgtype=signal
>>>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
>>>> dest=org.freedesktop.DBus spid=2613 tpid=2546
>>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>
>> Raw policy:
>>
>> allow system_dbusd_t consolekit_t:dbus send_msg;
>>
>> Possible macro/interface:
>>
>> consolekit_dbus_chat(system_dbusd_t)
>>
>> 3.
>>
>>>> denied  { send_msg } for msgtype=method_call
>>>> interface=org.freedesktop.DBus.Properties member=GetAll
>>>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
>>>> terminal=?'
>>
>> Raw policy:
>>
>> allow xdm_t devicekit_disk_t:dbus send_msg;
>>
>> Possible macro/interface:
>>
>> devicekit_dbus_chat_disk(xdm_t)
>>
>>
>> But this is only the start, You will probably encounter many more policy
>> issues. You will need to be able to analyse them and resolve issues
>> accordingly.
> 
> Wonderful ! I was not trying to get the job done, but a starting point
> is indeed very useful, since I have never done anything apart from a few
> trivial modules with the help of audit2allow.
> 
> Rushing to check if the new modules work. Then starting from there, I
> could create and submit a patch which allows those and any other
> permission that would be needed.
> 
> By the way, I have also noticed that for some reason user_dmesg is not
> being effectively enforced. The user_dmesg boolean is set to false, the
> dmesg module is loaded, the system is in enforcing mode, still a normal
> user is able to use dmesg...

"Normal" users are not constraint by user_dmesg i believe. Its only for
restricted users


> And last but not least, I have already mentioned about a few graphical
> applications that refuse to start without leaving any trace in the logs.
> Namely these are: gnome-terminal, gedit, evince and openoffice (not the
> execstack issue in this last case). What can be done if nothing appears
> in the logs ? How do I get to know what has been denied ?

semodule -DB to unload hidden denial rules
semodule -B to re-insert hidden denial rules

> 
> Thanks very much for your time. Much appreciated !
> 
> Kind regards,
> 
> Guido
> 

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

iEYEARECAAYFAk0wX4gACgkQMlxVo39jgT+PcACfT7ohHpirGqsXeFQUdyrgThMQ
1mYAn38spGu2TaHpxSxxgAaD4KQCFg+S
=Z3rQ
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hello Dominick !

On Fri, 14/01/2011 at 10.34 +0100, Dominick Grift wrote:
> > Hi Dominick !
> > 
> > On Thu, 13/01/2011 at 22.43 +0100, Dominick Grift wrote:
> >>> But in general for USER_AVCs there is nothing like audit2allow that can
> >>> be used to ease the job ?
> >>
> >> audit2allow can also be used for these dbus AVC' s sure. But if you want
> >> this stuff upstreamed then you will have to play by upstreams rules
> >> (style rules)
> > 
> > No, apparently audit2allow doesn't do the job for USER_AVCs.
> 
> Strange, in that case i guess you will have to translate it manually.
> 
> 1.
> 
> AVC denial:
> 
> > > denied  { send_msg } for msgtype=method_call
> > > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > > dest=org.freedesktop.Hal spid=2928 tpid=2314
> > > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> Raw policy:
> 
> allow xdm_t hald_t:dbus send_msg;
> 
> Possible macro/interface:
> 
> hal_dbus_chat(xdm_t)
> 
> 2.
> 
> > > denied  { send_msg } for msgtype=signal
> > > interface=org.freedesktop.PolicyKit1.Authority member=Changed
> > > dest=org.freedesktop.DBus spid=2613 tpid=2546
> > > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > > tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> > > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> > >
> 
> Raw policy:
> 
> allow system_dbusd_t consolekit_t:dbus send_msg;
> 
> Possible macro/interface:
> 
> consolekit_dbus_chat(system_dbusd_t)
> 
> 3.
> 
> > > denied  { send_msg } for msgtype=method_call
> > > interface=org.freedesktop.DBus.Properties member=GetAll
> > > dest=org.freedesktop.UDisks spid=3567 tpid=3569
> > > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > > tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> > > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> > > terminal=?'
> 
> Raw policy:
> 
> allow xdm_t devicekit_disk_t:dbus send_msg;
> 
> Possible macro/interface:
> 
> devicekit_dbus_chat_disk(xdm_t)
> 
> 
> But this is only the start, You will probably encounter many more policy
> issues. You will need to be able to analyse them and resolve issues
> accordingly.

Wonderful ! I was not trying to get the job done, but a starting point
is indeed very useful, since I have never done anything apart from a few
trivial modules with the help of audit2allow.

Rushing to check if the new modules work. Then starting from there, I
could create and submit a patch which allows those and any other
permission that would be needed.

By the way, I have also noticed that for some reason user_dmesg is not
being effectively enforced. The user_dmesg boolean is set to false, the
dmesg module is loaded, the system is in enforcing mode, still a normal
user is able to use dmesg...

And last but not least, I have already mentioned about a few graphical
applications that refuse to start without leaving any trace in the logs.
Namely these are: gnome-terminal, gedit, evince and openoffice (not the
execstack issue in this last case). What can be done if nothing appears
in the logs ? How do I get to know what has been denied ?

Thanks very much for your time. Much appreciated !

Kind regards,

Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/14/2011 12:15 AM, Guido Trentalancia wrote:
> Hi Dominick !
> 
> On Thu, 13/01/2011 at 22.43 +0100, Dominick Grift wrote:
>>> But in general for USER_AVCs there is nothing like audit2allow that can
>>> be used to ease the job ?
>>
>> audit2allow can also be used for these dbus AVC' s sure. But if you want
>> this stuff upstreamed then you will have to play by upstreams rules
>> (style rules)
> 
> No, apparently audit2allow doesn't do the job for USER_AVCs.

Strange, in that case i guess you will have to translate it manually.

1.

AVC denial:

> > denied  { send_msg } for msgtype=method_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2928 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

Raw policy:

allow xdm_t hald_t:dbus send_msg;

Possible macro/interface:

hal_dbus_chat(xdm_t)

2.

> > denied  { send_msg } for msgtype=signal
> > interface=org.freedesktop.PolicyKit1.Authority member=Changed
> > dest=org.freedesktop.DBus spid=2613 tpid=2546
> > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >

Raw policy:

allow system_dbusd_t consolekit_t:dbus send_msg;

Possible macro/interface:

consolekit_dbus_chat(system_dbusd_t)

3.

> > denied  { send_msg } for msgtype=method_call
> > interface=org.freedesktop.DBus.Properties member=GetAll
> > dest=org.freedesktop.UDisks spid=3567 tpid=3569
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> > terminal=?'

Raw policy:

allow xdm_t devicekit_disk_t:dbus send_msg;

Possible macro/interface:

devicekit_dbus_chat_disk(xdm_t)


But this is only the start, You will probably encounter many more policy
issues. You will need to be able to analyse them and resolve issues
accordingly.

> Regards,
> 
> Guido
> 

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

iEYEARECAAYFAk0wGJUACgkQMlxVo39jgT/JeQCeOOJaD6xfHAC8okGnjE+qvNf+
Qi4An0KoDfyODqivlo/dFVkZ3pqLyQXw
=cmPo
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hi Dominick !

On Thu, 13/01/2011 at 22.43 +0100, Dominick Grift wrote:
> > But in general for USER_AVCs there is nothing like audit2allow that can
> > be used to ease the job ?
> 
> audit2allow can also be used for these dbus AVC' s sure. But if you want
> this stuff upstreamed then you will have to play by upstreams rules
> (style rules)

No, apparently audit2allow doesn't do the job for USER_AVCs.

Regards,

Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/13/2011 10:37 PM, Guido Trentalancia wrote:
> Hello again !
> 
> On Thu, 13/01/2011 at 20.57 +0100, Dominick Grift wrote:
>>>>> These are some examples of the USER_AVC denials (when init is running in
>>>>> the proper context and the system has a few problems):
>>>>>
>>>>> type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
>>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>>> dest=org.freedesktop.Hal spid=2928 tpid=2314
>>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> Not sure where you got the idea from that xdm_t is allowed to dbus chat
>>>> to hald_t in refpolicy, but from my quick inspection it turns out that
>>>> this access seem to not be allowed (yet)
>>>>
>>>>> type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
>>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>>> dest=org.freedesktop.Hal spid=2868 tpid=2314
>>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> same as above
>>>>
>>>>> type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
>>>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>>>> dest=org.freedesktop.Hal spid=2868 tpid=2314
>>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> same as above
>>>>
>>>>>
>>>>> type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
>>>>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
>>>>> dest=org.freedesktop.DBus spid=2613 tpid=2546
>>>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
>>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>>>
>>>> looks like a bug in policy (seem to currently not be allowed in refpolicy)
>>>>
>>>>> type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
>>>>> interface=org.freedesktop.DBus.Properties member=GetAll
>>>>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
>>>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
>>>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
>>>>> terminal=?'
>>>>
>>>> currently not allowed in refpolicy
>>>
>>> Currently not allowed and looks like a bug in policy. Should we do
>>> something about it ?
>>>
>>>> You are dealing with refpolicy and you should expect this policy to not
>>>> be completely tailored to your requirements.
>>>
>>> Yes, I know that. But because my requirements are just those of a quite
>>> standard modern Linux system, we should probably elaborate further on
>>> what is missing. I would probably be able to spare some of my time for
>>> example.
>>
>> Its not that easy. Reference policy needs to stay a general purpose
>> policy. Each submitted line of policy needs to be judged in that light.
> 
> Yes. But again, the system on which it is being tested is a general
> purpose, plain, standard Linux system built from plain upstream
> components. So, I can't see how the above is not relevant to refpolicy.

Alright, well you can work with refpolicy to get your changes upstreamed.

>>> Nobody else interested in this thread and the opportunity given to
>>> improve refpolicy ?
>>
>> These rules are probably already in Fedora and Fedora works pretty
>> closely with refpolicy to get its stuff upstreamed (redhat values
>> working to get their stuff upstreamed) Refpolicy probably hasnt adopted
>> it yet becuase a) it wasnt approved. b) the context of why it is
>> required was missing. b) the patch submitted wasnt complete. c) some
>> other reason (like time contraints).
>>
>> But sure, i encourage you to try and get some of your modifications
>> upstreamed.
> 
> I have never done that before. Left completely alone, I am not sure what
> will eventually come out. But I shall probably give it a try...
> 

You have to start somewhere.

>> I also run a custom policy that is based off of refpolicy. you can find
>> it here:
>>
>> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=summary
> 
> I'll have a look at it and see if anything can be adapted to sort out
> the problem with dbus messages.

Might be better to look at fedora's policy.

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=summary

> But in general for USER_AVCs there is nothing like audit2allow that can
> be used to ease the job ?

audit2allow can also be used for these dbus AVC' s sure. But if you want
this stuff upstreamed then you will have to play by upstreams rules
(style rules)

> 
>> However this policy is unfortunately also not suitable to get upstreamed
>> because it has distinct properties and security goals (thus not
>> applicable to the general purpose reference policy)
>>
>>> Regards,
>>>
>>> Guido
> 
> Thanks. Guido
> 
> 

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

iEYEARECAAYFAk0vcecACgkQMlxVo39jgT/KBwCfTSaGQiSG844hIE8SAcBP3F+C
cPUAoNLkzq+ZgL4Y2tigWyYRdcGjluCF
=KvBJ
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hello again !

On Thu, 13/01/2011 at 20.57 +0100, Dominick Grift wrote:
> >>> These are some examples of the USER_AVC denials (when init is running in
> >>> the proper context and the system has a few problems):
> >>>
> >>> type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
> >>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> >>> dest=org.freedesktop.Hal spid=2928 tpid=2314
> >>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> >>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>
> >> Not sure where you got the idea from that xdm_t is allowed to dbus chat
> >> to hald_t in refpolicy, but from my quick inspection it turns out that
> >> this access seem to not be allowed (yet)
> >>
> >>> type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
> >>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> >>> dest=org.freedesktop.Hal spid=2868 tpid=2314
> >>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> >>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>
> >> same as above
> >>
> >>> type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
> >>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> >>> dest=org.freedesktop.Hal spid=2868 tpid=2314
> >>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> >>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>
> >> same as above
> >>
> >>>
> >>> type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
> >>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
> >>> dest=org.freedesktop.DBus spid=2613 tpid=2546
> >>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> >>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> >>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>
> >> looks like a bug in policy (seem to currently not be allowed in refpolicy)
> >>
> >>> type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
> >>> interface=org.freedesktop.DBus.Properties member=GetAll
> >>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
> >>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> >>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> >>> terminal=?'
> >>
> >> currently not allowed in refpolicy
> > 
> > Currently not allowed and looks like a bug in policy. Should we do
> > something about it ?
> > 
> >> You are dealing with refpolicy and you should expect this policy to not
> >> be completely tailored to your requirements.
> > 
> > Yes, I know that. But because my requirements are just those of a quite
> > standard modern Linux system, we should probably elaborate further on
> > what is missing. I would probably be able to spare some of my time for
> > example.
> 
> Its not that easy. Reference policy needs to stay a general purpose
> policy. Each submitted line of policy needs to be judged in that light.

Yes. But again, the system on which it is being tested is a general
purpose, plain, standard Linux system built from plain upstream
components. So, I can't see how the above is not relevant to refpolicy.

> > Nobody else interested in this thread and the opportunity given to
> > improve refpolicy ?
> 
> These rules are probably already in Fedora and Fedora works pretty
> closely with refpolicy to get its stuff upstreamed (redhat values
> working to get their stuff upstreamed) Refpolicy probably hasnt adopted
> it yet becuase a) it wasnt approved. b) the context of why it is
> required was missing. b) the patch submitted wasnt complete. c) some
> other reason (like time contraints).
> 
> But sure, i encourage you to try and get some of your modifications
> upstreamed.

I have never done that before. Left completely alone, I am not sure what
will eventually come out. But I shall probably give it a try...

> I also run a custom policy that is based off of refpolicy. you can find
> it here:
> 
> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=summary

I'll have a look at it and see if anything can be adapted to sort out
the problem with dbus messages.

But in general for USER_AVCs there is nothing like audit2allow that can
be used to ease the job ?

> However this policy is unfortunately also not suitable to get upstreamed
> because it has distinct properties and security goals (thus not
> applicable to the general purpose reference policy)
> 
> > Regards,
> > 
> > Guido

Thanks. Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/13/2011 08:24 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> Apparently the thread and your latest reply got splitted in two messages
> with the same subject.
> 
> Let's just follow up with this message which has the original Reference
> header.
> 
> On Thu, 13/01/2011 at 16.38 +0100, Dominick Grift wrote:
>>>> 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?
>>>
>>> Yes confirmed and it can be easily reproduced.
>>>
>>> When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
>>> would happen with an unmodified refpolicy-2.20101213, sestatus reports:
>>>
>>> Process contexts:
>>> Current context:                system_u:system_r:kernel_t:s0
>>> Init context:                   system_u:system_r:kernel_t:s0
>>> /sbin/mingetty                  system_u:system_r:kernel_t:s0
>>>
>>> But the system appears to run even "better" than when init correctly
>>> transitions into its proper context !
>>>
>>> I believe in other cases, for some reason that is not evident now, the
>>> context was system_u:system_r:insmod_t with a completely similar effect.
>>>
>>> So, for example, with the wrong init context, not only it is possible to
>>> login into gdm, but also things that were broken with the right init
>>> context works perfectly fine. A few examples: gedit, evince,
>>> gnome-terminal and openoffice refusing to start up without leaving any
>>> trace of denied AVCs in the audit logs and finally no more denied
>>> send_msg with dbus !
>>>
>>> The output of ps auxZ in this case ? Everything runs in
>>> system_u:system_r:kernel_t:s0 context apart from udev.
>>>
>>> What do you say ?
>>
>> kernel_t is an unconfined domain so that would make sense.
>>
>> not sure if insmod_t is an unconfined_domain as well (can be tested with
>> seinfo -x -aunconfined_domain | grep insmod)
> 
> Yes, insmod_t is also an unconfined domain in the refpolicy-2.20101213.
> 
>>> Is this not a sort of security-flaw ? Someone manages to
>>> relabel /sbin/init and then nobody checks that in enforcing mode init
>>> has effectively re-executed itself in the proper context ?
>>
>> no one, except authorized personnel, should be able to relabel it.
> 
> Yes, I know this. But to me it still appears as a weak point, which
> should be tackled in some way sooner or later. Also, consider that
> mislabelling in not uncommon and can happen for a variety of reasons
> without necessarily showing many signs.
> 
> System-security depending just on 1 correct label, 1 critical point with
> no further checks doesn't sound quite right...

it does not depend on a single label, all access decisions depend on a
combination of both source and target context, target object class and
its permissions.

I do agree that proper labelling is important though.

>>>>> 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.
>>>
>>> These are some examples of the USER_AVC denials (when init is running in
>>> the proper context and the system has a few problems):
>>>
>>> type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>> dest=org.freedesktop.Hal spid=2928 tpid=2314
>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>
>> Not sure where you got the idea from that xdm_t is allowed to dbus chat
>> to hald_t in refpolicy, but from my quick inspection it turns out that
>> this access seem to not be allowed (yet)
>>
>>> type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>> dest=org.freedesktop.Hal spid=2868 tpid=2314
>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>
>> same as above
>>
>>> type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
>>> dest=org.freedesktop.Hal spid=2868 tpid=2314
>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>
>> same as above
>>
>>>
>>> type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
>>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
>>> dest=org.freedesktop.DBus spid=2613 tpid=2546
>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
>>
>> looks like a bug in policy (seem to currently not be allowed in refpolicy)
>>
>>> type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
>>> interface=org.freedesktop.DBus.Properties member=GetAll
>>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
>>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
>>> terminal=?'
>>
>> currently not allowed in refpolicy
> 
> Currently not allowed and looks like a bug in policy. Should we do
> something about it ?
> 
>> You are dealing with refpolicy and you should expect this policy to not
>> be completely tailored to your requirements.
> 
> Yes, I know that. But because my requirements are just those of a quite
> standard modern Linux system, we should probably elaborate further on
> what is missing. I would probably be able to spare some of my time for
> example.

Its not that easy. Reference policy needs to stay a general purpose
policy. Each submitted line of policy needs to be judged in that light.

> Nobody else interested in this thread and the opportunity given to
> improve refpolicy ?

These rules are probably already in Fedora and Fedora works pretty
closely with refpolicy to get its stuff upstreamed (redhat values
working to get their stuff upstreamed) Refpolicy probably hasnt adopted
it yet becuase a) it wasnt approved. b) the context of why it is
required was missing. b) the patch submitted wasnt complete. c) some
other reason (like time contraints).

But sure, i encourage you to try and get some of your modifications
upstreamed.

I also run a custom policy that is based off of refpolicy. you can find
it here:

http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=summary

However this policy is unfortunately also not suitable to get upstreamed
because it has distinct properties and security goals (thus not
applicable to the general purpose reference policy)

> Regards,
> 
> Guido
> 

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

iEYEARECAAYFAk0vWQwACgkQMlxVo39jgT9MHQCfXUkLtYzEjFJtcscKiF9ar+iN
HVwAoKLbYp3a693wR3VUd4X3qxVJflJe
=RiB8
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

Hello Dominick !

Apparently the thread and your latest reply got splitted in two messages
with the same subject.

Let's just follow up with this message which has the original Reference
header.

On Thu, 13/01/2011 at 16.38 +0100, Dominick Grift wrote:
> >> 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?
> > 
> > Yes confirmed and it can be easily reproduced.
> > 
> > When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
> > would happen with an unmodified refpolicy-2.20101213, sestatus reports:
> > 
> > Process contexts:
> > Current context:                system_u:system_r:kernel_t:s0
> > Init context:                   system_u:system_r:kernel_t:s0
> > /sbin/mingetty                  system_u:system_r:kernel_t:s0
> > 
> > But the system appears to run even "better" than when init correctly
> > transitions into its proper context !
> > 
> > I believe in other cases, for some reason that is not evident now, the
> > context was system_u:system_r:insmod_t with a completely similar effect.
> > 
> > So, for example, with the wrong init context, not only it is possible to
> > login into gdm, but also things that were broken with the right init
> > context works perfectly fine. A few examples: gedit, evince,
> > gnome-terminal and openoffice refusing to start up without leaving any
> > trace of denied AVCs in the audit logs and finally no more denied
> > send_msg with dbus !
> > 
> > The output of ps auxZ in this case ? Everything runs in
> > system_u:system_r:kernel_t:s0 context apart from udev.
> > 
> > What do you say ?
> 
> kernel_t is an unconfined domain so that would make sense.
> 
> not sure if insmod_t is an unconfined_domain as well (can be tested with
> seinfo -x -aunconfined_domain | grep insmod)

Yes, insmod_t is also an unconfined domain in the refpolicy-2.20101213.

> > Is this not a sort of security-flaw ? Someone manages to
> > relabel /sbin/init and then nobody checks that in enforcing mode init
> > has effectively re-executed itself in the proper context ?
> 
> no one, except authorized personnel, should be able to relabel it.

Yes, I know this. But to me it still appears as a weak point, which
should be tackled in some way sooner or later. Also, consider that
mislabelling in not uncommon and can happen for a variety of reasons
without necessarily showing many signs.

System-security depending just on 1 correct label, 1 critical point with
no further checks doesn't sound quite right...

> >>> 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.
> > 
> > These are some examples of the USER_AVC denials (when init is running in
> > the proper context and the system has a few problems):
> > 
> > type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2928 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> Not sure where you got the idea from that xdm_t is allowed to dbus chat
> to hald_t in refpolicy, but from my quick inspection it turns out that
> this access seem to not be allowed (yet)
> 
> > type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2868 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> same as above
> 
> > type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
> > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> > dest=org.freedesktop.Hal spid=2868 tpid=2314
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> same as above
> 
> > 
> > type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
> > interface=org.freedesktop.PolicyKit1.Authority member=Changed
> > dest=org.freedesktop.DBus spid=2613 tpid=2546
> > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> 
> looks like a bug in policy (seem to currently not be allowed in refpolicy)
> 
> > type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
> > interface=org.freedesktop.DBus.Properties member=GetAll
> > dest=org.freedesktop.UDisks spid=3567 tpid=3569
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> > terminal=?'
> 
> currently not allowed in refpolicy

Currently not allowed and looks like a bug in policy. Should we do
something about it ?

> You are dealing with refpolicy and you should expect this policy to not
> be completely tailored to your requirements.

Yes, I know that. But because my requirements are just those of a quite
standard modern Linux system, we should probably elaborate further on
what is missing. I would probably be able to spare some of my time for
example.

Nobody else interested in this thread and the opportunity given to
improve refpolicy ?

Regards,

Guido

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

On 01/13/2011 04:15 PM, Guido Trentalancia wrote:
> Hello again Dominick !
> 
> On Thu, 13/01/2011 at 13.34 +0100, Dominick Grift wrote:
>> -----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?
> 
> Yes confirmed and it can be easily reproduced.
> 
> When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it
> would happen with an unmodified refpolicy-2.20101213, sestatus reports:
> 
> Process contexts:
> Current context:                system_u:system_r:kernel_t:s0
> Init context:                   system_u:system_r:kernel_t:s0
> /sbin/mingetty                  system_u:system_r:kernel_t:s0
> 
> But the system appears to run even "better" than when init correctly
> transitions into its proper context !
> 
> I believe in other cases, for some reason that is not evident now, the
> context was system_u:system_r:insmod_t with a completely similar effect.
> 
> So, for example, with the wrong init context, not only it is possible to
> login into gdm, but also things that were broken with the right init
> context works perfectly fine. A few examples: gedit, evince,
> gnome-terminal and openoffice refusing to start up without leaving any
> trace of denied AVCs in the audit logs and finally no more denied
> send_msg with dbus !
> 
> The output of ps auxZ in this case ? Everything runs in
> system_u:system_r:kernel_t:s0 context apart from udev.
> 
> What do you say ?

kernel_t is an unconfined domain so that would make sense.

not sure if insmod_t is an unconfined_domain as well (can be tested with
seinfo -x -aunconfined_domain | grep insmod)

> 
> Is this not a sort of security-flaw ? Someone manages to
> relabel /sbin/init and then nobody checks that in enforcing mode init
> has effectively re-executed itself in the proper context ?

no one, except authorized personnel, should be able to relabel it.

>>
>>> 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.
> 
> These are some examples of the USER_AVC denials (when init is running in
> the proper context and the system has a few problems):
> 
> type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 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_call
> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> dest=org.freedesktop.Hal spid=2928 tpid=2314
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

Not sure where you got the idea from that xdm_t is allowed to dbus chat
to hald_t in refpolicy, but from my quick inspection it turns out that
this access seem to not be allowed (yet)

> type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 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_call
> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> dest=org.freedesktop.Hal spid=2868 tpid=2314
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

same as above

> type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 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_call
> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> dest=org.freedesktop.Hal spid=2868 tpid=2314
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

same as above

> 
> type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 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=signal
> interface=org.freedesktop.PolicyKit1.Authority member=Changed
> dest=org.freedesktop.DBus spid=2613 tpid=2546
> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

looks like a bug in policy (seem to currently not be allowed in refpolicy)

> type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 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_call
> interface=org.freedesktop.DBus.Properties member=GetAll
> dest=org.freedesktop.UDisks spid=3567 tpid=3569
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> terminal=?'

currently not allowed in refpolicy

> At this point is probably pointless that I bother looking
> into /etc/dbus-1/system.d configuration files because it seems something
> which depends only on the SELinux policy.

yes that is unrelated.

You are dealing with refpolicy and you should expect this policy to not
be completely tailored to your requirements.

>>
>> 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
> 
> Thanks again for offering your advice.
> 
> Regards,
> 
> Guido
> 

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

iEYEARECAAYFAk0vHHsACgkQMlxVo39jgT8q1QCgrJR7ElPFeRGLhHA4SlCyNkgb
okIAoNJEDhYF8iOq9nslphAxFNfKpVH6
=fiBD
-----END PGP SIGNATURE-----

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

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

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

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
> 

[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[Dominick Grift]

-----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] refpolicy-2.20101213 (mcs) and dbus messages

[Guido Trentalancia]

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