From: guido@trentalancia.net (Guido Trentalancia)
Date: Tue, 30 Aug 2016 21:15:23 +0200
Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file
 contexts
In-Reply-To: <fd0e9bd4-f385-081b-36b5-ccf0c55cfa5c@gmail.com>
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>
	<e24eaac7-5277-23b5-f5db-d1a286920a9b@ieee.org>
	<1471956294.17467.4.camel@trentalancia.net>
	<d4e37b0e-79de-eee1-fa40-7888b5802591@ieee.org>
	<1472075733.19800.4.camel@trentalancia.net>
	<cb9a9019-2e69-dde1-e3cb-aa4382f3f589@ieee.org>
	<1472317696.28955.1.camel@trentalancia.net>
	<c49f1270-caa7-7e41-60dc-66ce0fe44e3c@gmail.com>
	<1472318213.31962.2.camel@trentalancia.net>
	<d5ad4d2b-f29f-1e45-84a1-a69dedd428f4@gmail.com>
	<1472330498.25935.7.camel@trentalancia.net>
	<fd0e9bd4-f385-081b-36b5-ccf0c55cfa5c@gmail.com>
Message-ID: <1472584523.15862.10.camel@trentalancia.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Dominick.

On Sat, 27/08/2016 at 22.57 +0200, Dominick Grift wrote:
> On 08/27/2016 10:41 PM, Guido Trentalancia wrote:
> > 
> > On Sat, 27/08/2016 at 19.17 +0200, Dominick Grift wrote:
> > > 
> > > On 08/27/2016 07:16 PM, Guido Trentalancia wrote:
> > 
> > [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 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.
> > 
> > We need to find a cure for this !!
> 
> I have been pleading for this for years. In my case the solution to
> these problems is DSSP and CIL. I was never able to solve these
> issues
> with reference policy unfortunately.
> 
> > 
> > 
> > What prevents it from running things on behalf of the caller ? And
> > what
> > do you mean exactly for running things on behalf of the caller ?
> 
> It hard to explain. The best way to appreciate what I mean is to
> experience it yourself. It will become clear as you move towards a
> fully
> confined desktop.
> 
> A lot of programs can be started by the session bus. Many of these
> programs started by the session bus on behalf of users run other
> programs and so forth and so forth. Some of these programs need to
> eventually be able run shell with a domain transition back to the
> login
> shell domain.
> 
> staff_t -> staff_dbus_t -> staff_myapp_t -> staff_t
> 
> To be able to do this we need to use derived types. You can't do it
> if
> theres a single session_dbus_t type.

I am hitting a similar situation at the moment with the modified gnome
and dbus modules...

user_t -> session_dbusd_t -> cannot execute bin_t or shell in the
user_t domain

Perhaps, it is possible to change the existing code so that it adds the
conflicting type rules, but then when it actually needs to apply them,
it looks up for duplicates and it only applies the one which matches
the calling context.

It should be feasible...

What do you say ?

We need to find a way out of this !

Best regards,

Guido