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