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

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

[Guido Trentalancia]

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.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te
--- refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te	2011-02-15 23:15:42.079074132 +0100
+++ refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te	2011-02-15 23:17:05.366699083 +0100
@@ -156,6 +156,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(system_dbusd_t)
+')
+
+optional_policy(`
 	policykit_dbus_chat(system_dbusd_t)
 	policykit_domtrans_auth(system_dbusd_t)
 	policykit_search_lib(system_dbusd_t)
diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te
--- refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te	2011-01-08 19:07:21.269745618 +0100
+++ refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te	2011-02-15 23:17:58.800809233 +0100
@@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
 sysnet_domtrans_dhcpc(NetworkManager_t)
 sysnet_signal_dhcpc(NetworkManager_t)
 sysnet_read_dhcpc_pid(NetworkManager_t)
+sysnet_read_dhcpc_state(NetworkManager_t)
 sysnet_delete_dhcpc_pid(NetworkManager_t)
 sysnet_search_dhcp_state(NetworkManager_t)
 # in /etc created by NetworkManager will be labelled net_conf_t.
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)
+')
+
+optional_policy(`
 	resmgr_stream_connect(xdm_t)
 ')
 

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

[Christopher J. PeBenito]

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.
> 
> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te
> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te	2011-02-15 23:15:42.079074132 +0100
> +++ refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te	2011-02-15 23:17:05.366699083 +0100
> @@ -156,6 +156,10 @@ optional_policy(`
>  ')
>  
>  optional_policy(`
> +	networkmanager_dbus_chat(system_dbusd_t)
> +')
> +
> +optional_policy(`
>  	policykit_dbus_chat(system_dbusd_t)
>  	policykit_domtrans_auth(system_dbusd_t)
>  	policykit_search_lib(system_dbusd_t)
> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te
> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te	2011-01-08 19:07:21.269745618 +0100
> +++ refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te	2011-02-15 23:17:58.800809233 +0100
> @@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
>  sysnet_domtrans_dhcpc(NetworkManager_t)
>  sysnet_signal_dhcpc(NetworkManager_t)
>  sysnet_read_dhcpc_pid(NetworkManager_t)
> +sysnet_read_dhcpc_state(NetworkManager_t)
>  sysnet_delete_dhcpc_pid(NetworkManager_t)
>  sysnet_search_dhcp_state(NetworkManager_t)
>  # in /etc created by NetworkManager will be labelled net_conf_t.
> 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)
> +')

Is there something new with xdm?  I'm concerned that more dbus
communications are added (this patch and others) with seemingly
unrelated services.

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

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

[Guido Trentalancia]

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.
> > 
> > diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te
> > --- refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te	2011-02-15 23:15:42.079074132 +0100
> > +++ refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te	2011-02-15 23:17:05.366699083 +0100
> > @@ -156,6 +156,10 @@ optional_policy(`
> >  ')
> >  
> >  optional_policy(`
> > +	networkmanager_dbus_chat(system_dbusd_t)
> > +')
> > +
> > +optional_policy(`
> >  	policykit_dbus_chat(system_dbusd_t)
> >  	policykit_domtrans_auth(system_dbusd_t)
> >  	policykit_search_lib(system_dbusd_t)
> > diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te
> > --- refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te	2011-01-08 19:07:21.269745618 +0100
> > +++ refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te	2011-02-15 23:17:58.800809233 +0100
> > @@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
> >  sysnet_domtrans_dhcpc(NetworkManager_t)
> >  sysnet_signal_dhcpc(NetworkManager_t)
> >  sysnet_read_dhcpc_pid(NetworkManager_t)
> > +sysnet_read_dhcpc_state(NetworkManager_t)
> >  sysnet_delete_dhcpc_pid(NetworkManager_t)
> >  sysnet_search_dhcp_state(NetworkManager_t)
> >  # in /etc created by NetworkManager will be labelled net_conf_t.
> > 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)
> > +')
> 
> Is there something new with xdm?  I'm concerned that more dbus
> communications are added (this patch and others) with seemingly
> unrelated services.

What you mean exactly for "something new with xdm" ? Do you mean new
features ?

And what do you mean for unrelated services exactly ? NetworkManager not
being very much related to xdm ? Yes, it's not entirely clear to me
either. But could be that due to the applet ?

More or less I have reported back what was being requested (in the form
of a patch).

Regards,

Guido

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

[Christopher J. PeBenito]

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.
>>>
>>> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te
>>> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te	2011-02-15 23:15:42.079074132 +0100
>>> +++ refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te	2011-02-15 23:17:05.366699083 +0100
>>> @@ -156,6 +156,10 @@ optional_policy(`
>>>  ')
>>>  
>>>  optional_policy(`
>>> +	networkmanager_dbus_chat(system_dbusd_t)
>>> +')
>>> +
>>> +optional_policy(`
>>>  	policykit_dbus_chat(system_dbusd_t)
>>>  	policykit_domtrans_auth(system_dbusd_t)
>>>  	policykit_search_lib(system_dbusd_t)
>>> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te
>>> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te	2011-01-08 19:07:21.269745618 +0100
>>> +++ refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te	2011-02-15 23:17:58.800809233 +0100
>>> @@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
>>>  sysnet_domtrans_dhcpc(NetworkManager_t)
>>>  sysnet_signal_dhcpc(NetworkManager_t)
>>>  sysnet_read_dhcpc_pid(NetworkManager_t)
>>> +sysnet_read_dhcpc_state(NetworkManager_t)
>>>  sysnet_delete_dhcpc_pid(NetworkManager_t)
>>>  sysnet_search_dhcp_state(NetworkManager_t)
>>>  # in /etc created by NetworkManager will be labelled net_conf_t.
>>> 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)
>>> +')
>>
>> Is there something new with xdm?  I'm concerned that more dbus
>> communications are added (this patch and others) with seemingly
>> unrelated services.
> 
> What you mean exactly for "something new with xdm" ? Do you mean new
> features ?

Yes.

> And what do you mean for unrelated services exactly ? NetworkManager not
> being very much related to xdm ? 

Yes.

> Yes, it's not entirely clear to me
> either. But could be that due to the applet ?

I assume you mean the one that runs in the gnome panel.  If so, I
wouldn't think so, since that would be running in the user's domain.

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

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

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

[Guido Trentalancia]

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.
> >>>
> >>> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te
> >>> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te	2011-02-15 23:15:42.079074132 +0100
> >>> +++ refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te	2011-02-15 23:17:05.366699083 +0100
> >>> @@ -156,6 +156,10 @@ optional_policy(`
> >>>  ')
> >>>  
> >>>  optional_policy(`
> >>> +	networkmanager_dbus_chat(system_dbusd_t)
> >>> +')
> >>> +
> >>> +optional_policy(`
> >>>  	policykit_dbus_chat(system_dbusd_t)
> >>>  	policykit_domtrans_auth(system_dbusd_t)
> >>>  	policykit_search_lib(system_dbusd_t)
> >>> diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te
> >>> --- refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te	2011-01-08 19:07:21.269745618 +0100
> >>> +++ refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te	2011-02-15 23:17:58.800809233 +0100
> >>> @@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
> >>>  sysnet_domtrans_dhcpc(NetworkManager_t)
> >>>  sysnet_signal_dhcpc(NetworkManager_t)
> >>>  sysnet_read_dhcpc_pid(NetworkManager_t)
> >>> +sysnet_read_dhcpc_state(NetworkManager_t)
> >>>  sysnet_delete_dhcpc_pid(NetworkManager_t)
> >>>  sysnet_search_dhcp_state(NetworkManager_t)
> >>>  # in /etc created by NetworkManager will be labelled net_conf_t.
> >>> 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)
> >>> +')
> >>
> >> Is there something new with xdm?  I'm concerned that more dbus
> >> communications are added (this patch and others) with seemingly
> >> unrelated services.
> > 
> > What you mean exactly for "something new with xdm" ? Do you mean new
> > features ?
> 
> Yes.

Then new features compared to which version ? I don't know the version
you took as reference... The display manager version I used for testing
was: gdm version 2.32.0 from gnome.org.

> > And what do you mean for unrelated services exactly ? NetworkManager not
> > being very much related to xdm ? 
> 
> Yes.

Yes, that makes sense to me. But I don't know the details...

> > Yes, it's not entirely clear to me
> > either. But could be that due to the applet ?
> 
> I assume you mean the one that runs in the gnome panel.  If so, I
> wouldn't think so, since that would be running in the user's domain.

Yes that was what I meant for applet.

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

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 ?

Regards,

Guido

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

[Christopher J. PeBenito]

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.


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


-- 

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

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

[Guido Trentalancia]

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

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

[Russell Coker]

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

That usually means that you don't have PAM configured correctly.  Probably your xdm is not compiled with SE support and you are not using pam_selinux.so .

>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

I am working on test VMs for Debian now and plan to do such things.

>By the way, Tresys' SMTP server is blocking some mail from dynamically
>allocated mobile Internet connections (using barracudanetworks.com). I

You shoud configure your phone to send through a smart host.  I am going to run such a server for SE testing, contact me off list for an account.
-- 
My blog    http://etbe.coker.com.au

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

[Guido Trentalancia]

Hi Russell,

thanks for your reply.

On Wed, 09/03/2011 at 19.03 +1100, Russell Coker wrote:
> 
>  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).
> 
> That usually means that you don't have PAM configured correctly.  Probably your xdm is not compiled with SE support and you are not using pam_selinux.so .

The first. It's a simple pam config without pam_selinux.so (for gdm). I
think I had removed it temporarily because it was causing issues.

> >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
> 
> I am working on test VMs for Debian now and plan to do such things.

Excellent. What do you mean for VMs ? In any case if you have time to do
it then please try to do something which applies to everybody and can
then be customized for Debian if necessary.

Christopher did not comment on this (yet)...

> >By the way, Tresys' SMTP server is blocking some mail from dynamically
> >allocated mobile Internet connections (using barracudanetworks.com). I
> 
> You shoud configure your phone to send through a smart host.  I am going to run such a server for SE testing, contact me off list for an account.

Yes, of course if I change my SMTP server... But most people are not
bothered of doing that. I think the idea behind stuff such as barracuda
is good but unfortunately it does not be apply very well to the case of
dynamically assigned addresses.

I had to reply on the list in any case because of the other issues.
Perhaps you can send me an account off-list... The same thing happened
with your address Russell.

Regards,

Guido

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

[Russell Coker]

>> >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
>> 
>> I am working on test VMs for Debian now and plan to do such things.
>
>Excellent. What do you mean for VMs ? In any case if you have time to
>do

I am going to setup virtual machines for testing different configurtions.

>it then please try to do something which applies to everybody and can
>then be customized for Debian 

For domain transitions it is mostly a matter of having a cron job or nagios entry that searches for wrong entries such as processes in kernel_t or initrc_t.

>> You shoud configure your phone to send through a smart host.  I am
>going to run such a server for SE testing, contact me off list for an
>account.
>
>Yes, of course if I change my SMTP server... But most people are not
>bothered of doing that. I think the idea behind stuff such as barracuda
>is good but unfortunately it does not be apply very well to the case of
>dynamically assigned addresses.

Blocking dynamic addresses is a standard practice.  Everyone who is capable of doing free software development is capable of configuring their MUA.

>I had to reply on the list in any case because of the other issues.
>Perhaps you can send me an account off-list... The same thing happened
>with your address Russell.

Ok

-- 
My blog    http://etbe.coker.com.au

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

[Guido Trentalancia]

On Wed, 09/03/2011 at 22.23 +1100, Russell Coker wrote:
> >> >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
> >> 
> >> I am working on test VMs for Debian now and plan to do such things.
> >
> >Excellent. What do you mean for VMs ? In any case if you have time to
> >do
> 
> I am going to setup virtual machines for testing different configurtions.
> 
> >it then please try to do something which applies to everybody and can
> >then be customized for Debian 
> 
> For domain transitions it is mostly a matter of having a cron job or nagios entry that searches for wrong entries such as processes in kernel_t or initrc_t.

What's wrong with just a "make check" target in refpolicy ?

There is major limitation with this: reboot and/or restarting of
services required. In the simple solution that I was thinking of, this
limitation could be documented and printed out: echo $limitation ; sleep
10 ; carry out basic sanity checks.

It's still better than nothing. And the idea of developing more advanced
tests with time sounds quite attractive to me.

> >> You shoud configure your phone to send through a smart host.  I am
> >going to run such a server for SE testing, contact me off list for an
> >account.
> >
> >Yes, of course if I change my SMTP server... But most people are not
> >bothered of doing that. I think the idea behind stuff such as barracuda
> >is good but unfortunately it does not be apply very well to the case of
> >dynamically assigned addresses.
> 
> Blocking dynamic addresses is a standard practice.  Everyone who is capable of doing free software development is capable of configuring their MUA.

Personally I would never do that outside of my home because I would not
be able to afford the risk of loosing something at work. Filtering based
on message content and other patterns sounds more reliable to me. And
they are not proprietary/commercial solutions: I have control over that.

> >I had to reply on the list in any case because of the other issues.
> >Perhaps you can send me an account off-list... The same thing happened
> >with your address Russell.
> 
> Ok

That's very kind of you. Cheers.

Guido

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

[Russell Coker]

On Thu, 10 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> > For domain transitions it is mostly a matter of having a cron job or
> > nagios entry that searches for wrong entries such as processes in
> > kernel_t or initrc_t.
> 
> What's wrong with just a "make check" target in refpolicy ?

It just doesn't work.

The main problem I've found in transitions not working is binaries getting 
renamed, which "make check" can never find.

The next issue is application misconfiguration, such as an xdm program not 
having the correct PAM configuration, again it's not something that you can 
check through policy.

> There is major limitation with this: reboot and/or restarting of
> services required. In the simple solution that I was thinking of, this
> limitation could be documented and printed out: echo $limitation ; sleep
> 10 ; carry out basic sanity checks.

Rebooting a VM is no big deal at all.  It's something that can be done by a 
cron job.

Also I'd like to automate the process of an X login and running some 
applications in KDE and GNOME sessions.  Any suggestions of how to do this 
would be appreciated.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] run/build-time sanity checks

[Guido Trentalancia]

On Thu, 10/03/2011 at 01.59 +1100, Russell Coker wrote:
> On Thu, 10 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> > > For domain transitions it is mostly a matter of having a cron job or
> > > nagios entry that searches for wrong entries such as processes in
> > > kernel_t or initrc_t.
> > 
> > What's wrong with just a "make check" target in refpolicy ?
> 
> It just doesn't work.
> 
> The main problem I've found in transitions not working is binaries getting 
> renamed, which "make check" can never find.

But do you mean application or daemon binaries ? That would be
classified as a labeling problem.

There are infinite degrees of freedom with the naming of executables
(not necessary "binaries"). I suppose that the reference policy targets
a reference system. And the reference system is an upstream system. And
upstream systems should have no degrees of freedom on the naming of
executables. Even if the reference system did not exactly coincide with
an upstream system, the reference system would still be unique by
definition (I don't know exactly, maybe it's a system being run at
Tresys).

> The next issue is application misconfiguration, such as an xdm program not 
> having the correct PAM configuration, again it's not something that you can 
> check through policy.

That's not a problem with refpolicy I think. That's a local
misconfiguration (or even intentional).

At least initially, such a "make check" should not target any possible
SELinux configuration or misconfiguration. I think that's a different
issue. That would fall under another class of testing. That would be an
overall testing of the effectiveness of
specific_custom_linux_system/SELinux/refpolicy for the end-user. Very
useful, perhaps also complex and expensive but in any case a different
thing in my imagination.

> > There is major limitation with this: reboot and/or restarting of
> > services required. In the simple solution that I was thinking of, this
> > limitation could be documented and printed out: echo $limitation ; sleep
> > 10 ; carry out basic sanity checks.
> 
> Rebooting a VM is no big deal at all.  It's something that can be done by a 
> cron job.
> 
> Also I'd like to automate the process of an X login and running some 
> applications in KDE and GNOME sessions.  Any suggestions of how to do this 
> would be appreciated.

Through xdmcp and/or x11 ports ? But I suppose a bit of compiled code
(ideally C) would be required here. The applications could then be
started automatically through the session manager (e.g. gnome-session
configuration) ? Then after a few seconds the main script checks that
everything is running in the proper context. Finally it kills everything
and creates the report (or iterates for other configurations).

Regards,

Guido

[refpolicy] run/build-time sanity checks

[Russell Coker]

On Thu, 10 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> > The main problem I've found in transitions not working is binaries
> > getting renamed, which "make check" can never find.
> 
> But do you mean application or daemon binaries ? That would be
> classified as a labeling problem.

Yes, a labeling problem that is very common.
 
> There are infinite degrees of freedom with the naming of executables
> (not necessary "binaries"). I suppose that the reference policy targets
> a reference system.

No, the reference policy targets Fedora, RHEL, Debian, Gentoo, and any other 
distribution that has people sending patches!

> And the reference system is an upstream system.

Where "upstream" is defined to mean any of the major distributions of Linux, 
then yes.

> And
> upstream systems should have no degrees of freedom on the naming of
> executables.

No, they have heaps of freedom.  Red Hat decides to have a program named 
"httpd" for legal reasons, Debian names the same program "apache", and then 
renames it to "apache2" for some reason.  We just have to deal with this 
stuff.

> Even if the reference system did not exactly coincide with
> an upstream system, the reference system would still be unique by
> definition (I don't know exactly, maybe it's a system being run at
> Tresys).

I think that Tresys mostly works with Red Hat based systems, they do work on 
RHEL servers, Fedora, and they probably have some Rawhide (Red Hat bleeding 
edge) systems in there too.  Some of the Tresys employees are Gentoo people so 
they probably have some Gentoo systems.

> > The next issue is application misconfiguration, such as an xdm program
> > not having the correct PAM configuration, again it's not something that
> > you can check through policy.
> 
> That's not a problem with refpolicy I think. That's a local
> misconfiguration (or even intentional).

True, but we want to find and fix as many problems as possible.

> > Rebooting a VM is no big deal at all.  It's something that can be done by
> > a cron job.
> > 
> > Also I'd like to automate the process of an X login and running some
> > applications in KDE and GNOME sessions.  Any suggestions of how to do
> > this would be appreciated.
> 
> Through xdmcp and/or x11 ports ? But I suppose a bit of compiled code
> (ideally C) would be required here. The applications could then be
> started automatically through the session manager (e.g. gnome-session
> configuration) ? Then after a few seconds the main script checks that
> everything is running in the proper context. Finally it kills everything
> and creates the report (or iterates for other configurations).

http://search.cpan.org/~ctrondlp/X11-GUITest-0.22/GUITest.pm

There are a variety of test frameworks for X11 available, the above is the 
first Google hit.  I'm not sure whether it's what I will eventually use, but I 
have done some Perl programming and I have many friends who are Perl experts 
who can help me so it seems like a good possibility.

What I want to do is test clicking on a URL from kmail to launch a web 
browser, saving a file from the web page (EG a PDF) to disk and then viewing 
it, changing the web browser program (from Konqueror to Iceweasel and then 
Chrome) and testing the process with all of them.  Then do the same things 
with Jabber clients and other things.

Also for this I want to have test servers setup.

I'd like to run up all common ISP services on a test machine and then connect 
to them from the common clients (at least two for every common protocol) and 
make sure that it all works.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

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

[Christopher J. PeBenito]

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

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

[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

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

[Christopher J. PeBenito]

On 03/14/11 13:23, Guido Trentalancia wrote:
> 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:
>>>>> 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".

Actually, this is one of the reasons I created the sestatus tool (see
sestatus -v): to help people determine certain the context of key files
and processes.  It doesn't validate that the contexts are correct, but
it makes it easy to find them.

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

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

[Guido Trentalancia]

On Mon, 14/03/2011 at 14.04 -0400, Christopher J. PeBenito wrote:
> On 03/14/11 13:23, Guido Trentalancia wrote:
> > 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:
> >>>>> 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".
> 
> Actually, this is one of the reasons I created the sestatus tool (see
> sestatus -v): to help people determine certain the context of key files
> and processes.  It doesn't validate that the contexts are correct, but
> it makes it easy to find them.

The sestatus tool can be used for init only and not much more. But
that's fine. I can't see what's wrong with integrating that into a "make
check" target. Assume the end-user does not know anything about SELinux
(not even that there is a sestatus tool).

Next one could be dbus (if its module is enabled in the policy), so
something based on:

ps axZ | grep dbus-daemon | grep -q system_dbusd_t || echo "FAIL: dbus
daemon might be running in the wrong context"

This checks will all be one-line. They can be made a bit more robust,
but still one-line.

Regards,

Guido

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

[Guido Trentalancia]

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.

Yes, I can now confirm. Everything past the X login runs in xdm_t
because pam_selinux open is disabled for gdm. Enabling pam_selinux open
for gdm leads to graphical login failures. I am trying to sort this out
now. Is it a known issue ?

Do you believe such a case (gdm not using pam_selinux) should be dropped
and not considered as a possible scenario ?

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

Regards,

Guido

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

[Christopher J. PeBenito]

On 3/10/2011 4:53 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.
>
> Yes, I can now confirm. Everything past the X login runs in xdm_t
> because pam_selinux open is disabled for gdm. Enabling pam_selinux open
> for gdm leads to graphical login failures. I am trying to sort this out
> now. Is it a known issue ?
>
> Do you believe such a case (gdm not using pam_selinux) should be dropped
> and not considered as a possible scenario ?

The login application needs to set the right context for the user 
logging in.  A login app that does not do this is malfunctioning w.r.t. 
SELinux.  It is not a valid scenario in the policy.  I will remove the 
xdm_t dbus access that I added from your consolekit patch, and ignore 
the other patches that have additional xdm_t dbus permissions.

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

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

[Guido Trentalancia]

On Mon, 14/03/2011 at 08.44 -0400, Christopher J. PeBenito wrote:
> On 3/10/2011 4:53 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.
> >
> > Yes, I can now confirm. Everything past the X login runs in xdm_t
> > because pam_selinux open is disabled for gdm. Enabling pam_selinux open
> > for gdm leads to graphical login failures. I am trying to sort this out
> > now. Is it a known issue ?
> >
> > Do you believe such a case (gdm not using pam_selinux) should be dropped
> > and not considered as a possible scenario ?
> 
> The login application needs to set the right context for the user 
> logging in.  A login app that does not do this is malfunctioning w.r.t. 
> SELinux.  It is not a valid scenario in the policy.  I will remove the 
> xdm_t dbus access that I added from your consolekit patch, and ignore 
> the other patches that have additional xdm_t dbus permissions.

Ok, that's fine. If gdm is only supported with pam+selinux and not with
just pam, then that should be removed.

As soon as I have managed to get pam_selinux open working, I will test
and see if there is something missing.

Sorry for the misunderstanding.

Regards,

Guido