From: dac.override@gmail.com (Dominick Grift) Date: Sat, 27 Aug 2016 19:17:50 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <1472318213.31962.2.camel@trentalancia.net> References: <1471099545.21480.27.camel@trentalancia.net> <1471296811.28802.0.camel@trentalancia.net> <1471704772.17584.9.camel@trentalancia.net> <1471894798.19333.1.camel@trentalancia.net> <1471956294.17467.4.camel@trentalancia.net> <1472075733.19800.4.camel@trentalancia.net> <1472317696.28955.1.camel@trentalancia.net> <1472318213.31962.2.camel@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/27/2016 07:16 PM, Guido Trentalancia wrote: > Hello Dominick. > > On Sat, 27/08/2016 at 19.10 +0200, Dominick Grift via refpolicy wrote: >> On 08/27/2016 07:08 PM, Guido Trentalancia via refpolicy wrote: > > [...] > >>>>>>>> On 08/22/16 15:39, Guido Trentalancia wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> + type dconf_t, dconf_exec_t, >>>>>>>>> dconf_home_t; >>>>>>>>> + type at_spi_t, at_spi_exec_t; >>>>>>>>> type gconfd_t, gconfd_exec_t, >>>>>>>>> gconf_tmp_t; >>>>>>>>> type gconf_home_t; >>>>>>>>> + type gnome_settings_t, >>>>>>>>> gnome_settings_exec_t; >>>>>>>>> + type gnome_settings_daemon_t, >>>>>>>>> gnome_settings_daemon_exec_t; >>>>>>>>> + type gnome_settings_schemas_t; >>>>>>>>> + type gkeyringd_exec_t, >>>>>>>>> gnome_keyring_home_t, >>>>>>>>> gnome_keyring_cache_home_t, gnome_keyring_tmp_t; >>>>>>>>> + type mime_info_t; >>>>>>>>> + type user_dbusd_t; >>>>>>>> >>>>>>>> This dbus type cannot be referenced directly in this >>>>>>>> module. >>>>>>> >>>>>>> If $1_dbusd_t is used to get the role/type prefix from the >>>>>>> caller, >>>>>>> then >>>>>>> it doesn't compile for some reason which is not yet clear >>>>>>> to >>>>>>> me. >>>>>>> >>>>>>> Any idea ? >>>>>> >>>>>> The $1_dbusd_t rules need to be contained in the dbus module, >>>>>> not >>>>>> the >>>>>> gnome module. Beyond that, it's tough to say what the >>>>>> problem >>>>>> is, >>>>>> without knowing the error messages. >>>>> >>>>> Suppose to have the following additional dbus interface: >>>>> >>>>> ####################################### >>>>> ## >>>>> ## Make a domain transition from a >>>>> ## given source domain to the >>>>> ## DBUS session bus domain using >>>>> ## the DBUS executable file type. >>>>> ## >>>>> ## >>>>> ## >>>>> ## The prefix of the user role (e.g., user >>>>> ## is the prefix for user_r). >>>>> ## >>>>> ## >>>>> ## >>>>> ## >>>>> ## Domain allowed access. >>>>> ## >>>>> ## >>>>> # >>>>> interface(`dbus_domain_transition_session_bus',` >>>>> gen_require(` >>>>> type dbusd_exec_t; >>>>> type $1_dbusd_t; >>>>> ') >>>>> >>>>> allow $2 dbusd_exec_t:file exec_file_perms; >>>>> domtrans_pattern($2, dbusd_exec_t, $1_dbusd_t) >>>>> ') >>>>> >>>>> and suppose that it is called by the following statement: >>>>> >>>>> dbus_domain_transition_session_bus($1, at_spi_t) >>>>> >>>>> where $1 = "user". >>>>> >>>>> During policy load, the following error is generated: >>>>> >>>>> Conflicting type rules >>>>> Binary policy creation failed at line 29393 of >>>>> /var/lib/selinux/refpolicy-06082016/tmp/modules/400/sysadm/cil >>>>> Failed to generate binary >>>>> /usr/sbin/semodule: Failed! >>>>> make: *** [Rules.modular:58: load] Error 1 >>>>> >>>>> The temporary file is deleted automatically and cannot be >>>>> inspected. >>>>> >>>>> I hope it is clear now... >>>>> >>>>> Do you have an idea ? It's the only thing missing before all >>>>> the >>>>> dbus >>>>> rules are moved from the gnome to the dbus module and I can >>>>> create >>>>> a >>>>> new version of this important patch. >>>> >>>> It's not so helpful unfortunately. My guess is that it is a >>>> conflicting >>>> type_transition. Unfortunately the compiler error message isn't >>>> helpful. >>> >>> I have just posted a patch on the SELinux mailing list to produce a >>> more meaningful error message for conflicting type rules, see the >>> following thread: >>> >>> [PATCH] libsepol: Produce more meaningful error messages for >>> conflicting type rules >>> >>> In this case, the conflicting type rule is: >>> >>> scontext=at_spi_t >>> tcontext=dbusd_exec_t >>> tclass=process >>> result=sysadm_dbusd_t >>> >>> which confirms the previous debugging results (it's the >>> type_transition >>> rule). >>> >>> Another one is similar, with scontext=gnome_settings_t. >>> >>> What I suspect is that when it compiles, it quadruplicates the type >>> transition for each of user, staff, sysadm and xguest, thus leading >>> to >>> conflicting rules. >>> >>> Therefore, the solution might be to use a common static name for >>> the >>> domain (for example, "session_dbusd_t" instead of "$1_dbusd_t"). >> >> and that will introduce other issues. because the session bus must be >> able to run things on behalf of the caller > > Thanks for providing a forecast of other issues. > > So, what's the way out of this damn loop ? > > I am almost getting lost... > I dont know. > Regards, > > Guido > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160827/5446cd68/attachment-0001.bin