From: dac.override@gmail.com (Dominick Grift) Date: Thu, 25 Aug 2016 09:25:17 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <06A8C9EE-9D30-41C7-92A0-539905F3E92F@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> <06A8C9EE-9D30-41C7-92A0-539905F3E92F@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/25/2016 12:42 AM, Guido Trentalancia via refpolicy wrote: > It works fine in the latest version of this patch (from within the gnome module)!! > > So, why does it stop working when I create a dbus interface and call it from the gnome module? > > I am stuck with this unfortunately... > I have been there before. I have attempted to confined desktops for years. Facing all kinds of limitations of the reference policy. I am not saying that the issue you are facing is related to limitations to the refpolicy, because I do not know for sure. What I do feel i know is that confining complex desktops with reference policy is difficult if not impossible. The CIL policy was designed to deal with complex requirements. My DSSP policy demonstrates that with CIL , complex desktops can be confined. Besides the techinical issues there is also the issue of design with confining complex desktops. There are many patterns that become visible later in the process. Causing one to have to refactor the policy. I already see things in your patch where I personally would have done things differently taking into account the bigger picture. Basically a good approach would be to first confine the desktop fully. then look at that from a distance, and then write it again with in mind all the things you've learned. > How about the other missing patch for the "module_load" permission in the kernel and files modules? Have you found an alternative name for that interface? > > The patch for the kernel is waiting to get committed, along with the testcase and a small Makefile patch for the testsuite. > > I have also posted here a patch for the Reference Policy Makefile so that it integrates better with the SELinux testsuite (which at the moment works out of the box only on Red Hat). > > Best regards, > > Guido > > On the 25th August 2016 00:10:22 CEST, Chris PeBenito wrote: >> On 08/24/16 17:55, Guido Trentalancia wrote: >>> Hello Christopher. >>> >>> I have more detailed information about this problem... >>> >>> On Tue, 23/08/2016 at 19.02 -0400, Chris PeBenito wrote: >>>> On 08/23/16 08:44, Guido Trentalancia wrote: >>>>> >>>>> Hello Christopher ! >>>>> >>>>> Thanks for providing your valuable feedback. >>>>> >>>>> On Mon, 22/08/2016 at 21.15 -0400, Chris PeBenito 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. > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > -- 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/20160825/7c684dac/attachment.bin