From: guido@trentalancia.com (Guido Trentalancia) Date: Mon, 14 Mar 2011 18:26:09 +0100 Subject: [refpolicy] [PATCH 13/34]: patch to allow networkmanager dbus chat In-Reply-To: <4D7E0DC8.7040001@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> <1299793980.4680.5.camel@tesla.lan> <4D7E0DC8.7040001@tresys.com> Message-ID: <1300123569.3071.8.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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