From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 14 Mar 2011 08:42:13 -0400
Subject: [refpolicy] [PATCH 13/34]: patch to allow networkmanager dbus
 chat
In-Reply-To: <1299533995.2967.23.camel@tesla.lan>
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>
	<1299533995.2967.23.camel@tesla.lan>
Message-ID: <4D7E0D25.5080304@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

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

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com