[refpolicy] [PATCH 13/34]: patch to allow networkmanager dbus chat

[guido@trentalancia.com (Guido Trentalancia)]

On Mon, 14/03/2011 at 08.42 -0400, Christopher J. PeBenito wrote:
> On 3/7/2011 4:39 PM, Guido Trentalancia wrote:
> > On Mon, 07/03/2011 at 14.37 -0500, Christopher J. PeBenito wrote:
> >> On 03/07/11 12:09, Guido Trentalancia wrote:
> >>> On Mon, 07/03/2011 at 08.56 -0500, Christopher J. PeBenito wrote:
> >>>> On 02/23/11 13:50, Guido Trentalancia wrote:
> >>>>> Hello Christopher !
> >>>>>
> >>>>> On Wed, 23/02/2011 at 09.36 -0500, Christopher J. PeBenito wrote:
> >>>>>> On 02/16/11 01:13, Guido Trentalancia wrote:
> >>>>>>> This patch allows dbus chat between networkmanager and dbus and
> >>>>>>> between networkmanager and xdm. It also adds a missing permission
> >>>>>>> (sysnet_read_dhcpc_state) to the networkmanager module.
> >> [cut]
> >>>>>>> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te
> >>>>>>> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te	2011-02-15 23:07:24.845137330 +0100
> >>>>>>> +++ refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te	2011-02-15 23:17:05.369699539 +0100
> >>>>>>> @@ -548,6 +548,10 @@ optional_policy(`
> >>>>>>>   ')
> >>>>>>>
> >>>>>>>   optional_policy(`
> >>>>>>> +	networkmanager_dbus_chat(xdm_t)
> >>>>>>> +')
> >>>>> More or less I have reported back what was being requested (in the form
> >>>>> of a patch).
> >>>> It makes me wonder if everything is running in the right domain.
> >>> That could be. But I have not been provided with a reference. So, can
> >>> you provide a reference ps auxZ which then I will compare as soon as I
> >>> can access the test system again ?
> >>
> >> It would be simpler if you could provide the ps output.  The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong.  It should be running in the user's domain.
> >
> > I think my latest reply was not the proper answer to your question. What
> > I meant for "everything is running as xdm_t" is that as a normal user if
> > you type "id -Z" from the gnome-terminal, then you get xdm_t (which
> > still looks suspicious to me).
> >
> > All the rest is running fine. So, for example,
> >
> > NetworkManager ->  system_u:system_r:NetworkManager_t
> > wpa_supplicant ->  -:-:-
> > ntpd ->  -:-:ntpd_t
> > gdm ->  -:-:xdm_t
> > polkitd ->  -:-:policykit_t
> > hald ->  -:-:hald_t
> > dbus-daemon ->  -:-:system_dbusd_t
> > consolekit ->  -:-:consolekit_t
> > avahi ->  -:-:avahi_t
> >
> > and so on...
> 
> But what are your user sessions running as?  eg. nm-applet, bash, etc.

They were running in the "wrong" context: xdm_t. This is because
pam_selinux.so open fails for pam/gdm. Now the point is whether that
configuration should be supported or not (i.e. pam_selinux open disabled
on a SELinux system).

> >>> Also, what do you think about the idea of providing a make target (say
> >>> "make check") in refpolicy which runs some minimal checks on that for at
> >>> least the core processes ?
> >>
> >> I can't think of how that would work off the top of my head.  If you have ideas, I'd be happy to listen.  I'd prefer to not write a script that has all of the checking hard coded in it.
> >
> > It's just something very simple. A make target which runs ps axZ (as
> > sysadm) and compares a few very basic things:
> >
> > - if init has properly transitioned to its context (apparently at the
> > moment no one cares if it hasn't, which is quite worrying as everything
> > could run in kernel_t without showing any symptom or warning);
> > - for a few core modules (as long as they are compiled in the policy),
> > that they are running in the proper context: so for example if polkitd
> > is running in policykit_t context (ps axZ | grep polkitd | grep
> > policykit_t).
> >
> > Of course you can avoid hardcoding the keywords "polkitd" and
> > "policykit_d" as long as you can get that out of policykit.{te,fc} by
> > the means of some other form of regexp matching and string processing
> > (sed, awk) for example: something very simple, something very basic,
> > still quite useful to the inexperienced user.
> 
> What you're describing is a big hardcoded script, which I'm trying to avoid.

More or less this what I meant:

check:
	ps axZ | grep init | grep -q init_t || echo "FAIL: init has not
transitioned properly to its context"

and so on for the a few other basic first-line context checks.

If you don't like it, it doesn't matter. Any test needs at least to have
the reference results "hardcoded".

Regards,

Guido