From: guido@trentalancia.net (Guido Trentalancia)
Date: Thu, 01 Sep 2016 16:40:39 +0200
Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file
 contexts
In-Reply-To: <20160901140602.GA2268@meriadoc.perfinion.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>
	<20160901042035.GA23615@meriadoc.perfinion.com>
	<1472722380.6210.17.camel@trentalancia.net>
	<20160901115329.GA9845@meriadoc.perfinion.com>
	<1472732930.30863.18.camel@trentalancia.net>
	<20160901140602.GA2268@meriadoc.perfinion.com>
Message-ID: <1472740839.17989.11.camel@trentalancia.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, 01/09/2016 at 22.06 +0800, Jason Zaman wrote:
> On Thu, Sep 01, 2016 at 02:28:50PM +0200, Guido Trentalancia wrote:

[...]

> > At the moment the gnome desktop is not confined. It runs in the
> > user
> > domain.
> > 
> > One of the things that the patch does is to start confining the
> > gnome
> > desktop.
> > 
> > If you start doing so, you'll end up with needing transitions that
> > apparently cannot be supported by the current framework.
> > 
> > If you want to reproduce the problem, you need to start confining
> > the
> > gnome desktop: dconf, at-spi, gsettings, gnome-settings-daemon and
> > so
> > on. A way to start doing so is to try the patch (v4) that I posted
> > and
> > modify it as indicated by Christopher in the review.
> > 
> > > 
> > > Wouldnt they just need dbus send_msg? Why does it need to exec
> > > the
> > > dbus
> > > daemon? It should already be running, they dont need to start it
> > > or
> > > anything. Can you show some error messages?
> > 
> > The system dbus daemon is running, not the session one.
> 
> The session dbus is supposed to be started when you login first
> thing.

Yes, exactly.

> at-spi shouldnt be trying to start it.

Who said that ? At-spi starts with Gnome from the xdg autostart
directory by default.

> > > > > A lot of these other problems in this patch seem to be issues
> > > > > with
> > > > > dbus
> > > > > so lets fix that first then the other ones will be easier.
> > 
> > All I can say, is that the prefixed types don't work when you start
> > confining the gnome desktop.
> 
> You still haven't explained exactly what is trying to run what? What
> are
> the starting domains? what is the program? what is it trying to run?
> what are the domains (before and after the patch) of the things it
> tries
> to run? What are the error messages?
> 
> > 
> > Try by yourself, it takes 5 minutes to apply the patch and modify
> > it to
> > use the prefixed types instead of "user_dbusd_t".
> 
> Yeah, I know the rules dont work, I can see that without even
> building.
> My question is why do you need the rules? You keep saying you need
> these
> rules but what *exactly* do they fix? Once we know that we can
> suggest
> other solutions.

The new rules solve some problems in the current policy that don't let
Gnome to start and also they confine other pieces of Gnome that are not
currently confined (dconf, at-spi, gsd and so on).

Other things that are tackled by the patch are listed at the top of it
(description of the patch). It is several things all together.

> Using user_dbusd_t is useless. your patch would fix it for user_t,
> but
> staff_t and any others would be still broken.

Yes, I know. It was so because the prefixed types don't work properly.

I think we are starting to loop around the same arguments...

> > > > If you want to help implementing a patch, we need to identify
> > > > the
> > > > code
> > > > where such policy is actually enforced, so that there we can
> > > > track
> > > > the
> > > > calling user domain to choose the right type transition.
> > > 
> > > We need to take a step back, there are too many issues mixed
> > > together
> > > with this patch. fixing the policy to allow conflicting types
> > > sounds
> > > like the wrong solution to whatever the problem is.
> > 
> > At the moment, I still believe that is the optimal solution:
> > allowing
> > conflicts in the policy and resolving them at runtime by exploiting
> > the
> > knowledge of the user and role parts of the context.

The above is what is needed to achieve an optimal solution to the
problem that I encountered while developing this gnome patch.

Guido