From: guido@trentalancia.net (Guido Trentalancia) Date: Tue, 30 Aug 2016 23:46:22 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <08ff72bd-3fdb-a3a9-a077-76d3f35b0ae0@ieee.org> 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> <1472330498.25935.7.camel@trentalancia.net> <1472334513.25935.16.camel@trentalancia.net> <6b1697f1-2aaf-3727-5b69-8794a0f85530@gmail.com> <7EAFAD82-CDDA-47E3-950E-4D5610686C6C@trentalancia.net> <1472584981.15862.15.camel@trentalancia.net> <08ff72bd-3fdb-a3a9-a077-76d3f35b0ae0@ieee.org> Message-ID: <1472593582.9749.6.camel@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Tue, 30/08/2016 at 17.37 -0400, Chris PeBenito wrote: > On 08/30/16 15:23, Guido Trentalancia wrote: > > > > Hello Christopher. > > > > On Sun, 28/08/2016 at 14.40 -0400, Chris PeBenito wrote: > > > > > > On 08/28/16 11:37, Guido Trentalancia via refpolicy wrote: > > > > > > > > > > > > Things are very far from working naturally as they are. > > > > > > > > On the other hand, the patches are surely far from being > > > > complete > > > > or stable yet, but at least every version allows to start the > > > > Gnome > > > > desktop. > > > > > > > > Now I met this major problem, it looks by all means a > > > > limitation of > > > > the existing framework, but I am sure that it will be sorted > > > > out... > > > > > > > > I am also waiting to hear from Christopher about this. > > > > > > The way I see it is that general purpose desktops are incredibly > > > complicated and are not designed with security in mind.??I wonder > > > if > > > the > > > policy complexity needed to confine it all actually buys a > > > proportional > > > amount of security gains.??I'm not saying it shouldn't be done, > > > but I > > > am > > > skeptical that it is worth it. > > > > Apart from confining the whole desktop, what I recently proposed to > > Dominick for further evaluation is as follows: > > > > - we patch the libsepol code so that it creates all the conflicting > > type rules instead of aborting; > > - we also patch the policy enforcing code, so that when it needs to > > enforce one of such conflicting type rules, it first searches for > > duplicates and then it enforces the one that matches the calling > > context. > > > > Do you think the above is feasible (in particular, "matching the > > calling context") ? > > I don't know what you mean by "matching the calling context."??A? > conflicting type transition looks like this: > > type_transition source_type exec_type:process new_domain; > type_transition source_type exec_type:process other_new_domain; > > I don't see how you can decide between the two if they both exist in > the? > policy (unless they are in opposite if/else blocks, which is valid). type_transition session_dbusd_t bin_t:process user_t; type_transition session_dbusd_t bin_t:process staff_t; type_transition session_dbusd_t bin_t:process sysadm_t; type_transition session_dbusd_t bin_t:process xguest_t; At the moment, they cannot coexist (conflicting type rules). Imagine that we insert all of them into the policy. The process that is running as session_dbusd_t (the source) is actually classified as user_u:user_r:session_dbusd_t (or equivalently for the other three possible cases). So, for the case at hand, we know that the first rule should be considered for such process: we enforce: type_transition session_dbusd_t bin_t:process user_t; Theoretically, we can select the correct rule for each calling process by looking at the full context of such process. Am I missing something ? Regards, Guido