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