From: guido@trentalancia.com (Guido Trentalancia)
Date: Mon, 07 Mar 2011 22:39:55 +0100
Subject: [refpolicy] [PATCH 13/34]: patch to allow networkmanager dbus
 chat
In-Reply-To: <4D7533E5.9050806@tresys.com>
References: <1297836836.3205.56.camel@tesla.lan>
	<4D651B7A.4010100@tresys.com> <1298487030.29671.20.camel@tesla.lan>
	<4D74E408.2050501@tresys.com> <1299517796.2978.41.camel@tesla.lan>
	<4D7533E5.9050806@tresys.com>
Message-ID: <1299533995.2967.23.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

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

By the way, Tresys' SMTP server is blocking some mail from dynamically
allocated mobile Internet connections (using barracudanetworks.com). I
can't do much if somebody before me was using a dynamic IP address for
spamming... I hope you are still getting them through the list.

Regards,

Guido