From: guido@trentalancia.net (Guido Trentalancia)
Date: Thu, 01 Sep 2016 11:33:00 +0200
Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file
 contexts
In-Reply-To: <20160901042035.GA23615@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>
Message-ID: <1472722380.6210.17.camel@trentalancia.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Jason.

On Thu, 01/09/2016 at 12.20 +0800, Jason Zaman wrote:
> On Mon, Aug 22, 2016 at 09:39:58PM +0200, Guido Trentalancia wrote:
> > 
> > Update for the gnome module:

[...]

> Hey,
> 
> I've been fairly busy lately so didnt closely follow this thread and
> its
> too long now for me to understand what exactly the problems are.

I'll point you to a few right messages to read in this thread to
understand the problem clearly...

Please read the following messages in order:

http://oss.tresys.com/pipermail/refpolicy/2016-August/008360.html?(non-
quoted message text only)

http://oss.tresys.com/pipermail/refpolicy/2016-August/008369.html?(non-
quoted message text only)

What Dominick added here is partly true, although at the I have had
some success with re-writing the policy for the whole desktop (or most
of it):

http://oss.tresys.com/pipermail/refpolicy/2016-August/008370.html

http://oss.tresys.com/pipermail/refpolicy/2016-August/008374.html

http://oss.tresys.com/pipermail/refpolicy/2016-August/008382.html

http://oss.tresys.com/pipermail/refpolicy/2016-August/008385.html

http://oss.tresys.com/pipermail/refpolicy/2016-August/008384.html

The following messages are about a possible way to solve the problem
without changing the actual policy (which can be tricky):

http://oss.tresys.com/pipermail/refpolicy/2016-August/008397.html

http://oss.tresys.com/pipermail/refpolicy/2016-August/008398.html

http://oss.tresys.com/pipermail/refpolicy/2016-August/008400.html

So, you have an excellent excerpt now...

> If I followed correctly, it seems like the biggest problem currently
> is
> transitioning to/from dbus? can you show the "ps auxfZ | grep dbus"
> lines?

The problem is transitioning from a user domain (user, staff, sysadm or
xguest) to other domains such as dbus (or gkeyring) and then back to
the initial user domain.

At the moment the policy uses variable types built using the user
argument ($1) passed to the gnome/dbus role() interface.

Such approach has big limitations and the current framework is poorly
designed with respect to the ability to perform the above mentioned
transition.

> How exactly are you running into problems? Can you post a very
> minimal
> command that triggers the problems? Is there some hello world I can
> put
> in /usr/share/dbus-1/services and a command to trigger the issue?

It's more complex than just starting a command. There are problems in
the underlying framework when the modified policy is loaded
(conflicting type rules, i.e. conflicting type transitions).

One way to solve the problem is by changing the policy. I have had some
success so far, however it's tricky, expensive and it's not the optimal
solution.

A possible optimal solution is proposed in the last two or three
messages that I posted (see the last two or three messages quoted
above).

> 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.

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.

Regards,

Guido