From: jason@perfinion.com (Jason Zaman)
Date: Thu, 1 Sep 2016 22:06:02 +0800
Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file
 contexts
In-Reply-To: <1472732930.30863.18.camel@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>
	<20160901042035.GA23615@meriadoc.perfinion.com>
	<1472722380.6210.17.camel@trentalancia.net>
	<20160901115329.GA9845@meriadoc.perfinion.com>
	<1472732930.30863.18.camel@trentalancia.net>
Message-ID: <20160901140602.GA2268@meriadoc.perfinion.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, Sep 01, 2016 at 02:28:50PM +0200, Guido Trentalancia wrote:
> Hello Jason,
> 
> thanks for getting back on this.
> 
> On Thu, 01/09/2016 at 19.53 +0800, Jason Zaman wrote:
> > On Thu, Sep 01, 2016 at 11:33:00AM +0200, Guido Trentalancia wrote:
> 
> [...]
> 
> > > 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...
> > 
> > This helped a lot but I am still unclear what the original problem
> > is.
> 
> The original problem is that the patch that I posted to update the
> gnome policy and the gnome file contexts leads to the conflicting type
> rules issues.
> 
> It's a limitation of the current situation.
> 
> What the patch does (its description) has been posted here:
> 
> http://oss.tresys.com/pipermail/refpolicy/2016-August/008324.html
> 
> Try by yourself, by applying such patch, then modifying as indicated by
> Christopher (moving dbus related statements from the gnome role
> template to the dbus module) and finally using the prefixed types (at
> the moment it uses user_dbusd_t, which won't work for all users).
> 
> It shouldn't take very long to apply the patch and modify it... At
> least you can touch the problem with your own hands.
> 
> > > > 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.
> > 
> > As you realized, this kind if thing is not allowed:
> > ????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;
> > 
> > There are typically two ways to fix it, the easiest is prefixed types
> > so
> > that the transitions become:
> > ????type_transition user_dbusd_t bin_t:process user_t;
> > ????type_transition staff_dbusd_t bin_t:process staff_t;
> 
> That is what doesn't work: the prefixed types. They lead to conflicting
> type rules.
> 
> > dbus is currently setup like this along with most other kinds of
> > programs that need their own domain but then need to transition back
> > to
> > the user's shell (eg staff_sudo_t, and a few login type things are
> > what
> > first come to mind).
> > 
> > The other way is to have the program be selinux aware. Ie link with
> > libselinux and query the policy for what should be used.
> > For example, when running a user's cronjob, cron will look in
> > /etc/selinux/mcs/contexts/default_contexts for the line and query all
> > the role/type combos until it finds one that is allowed by the policy
> > for that user. For these kinds of things the program basically does
> > setexeccon() before the exec to manually set it so do not require the
> > type_transition rules at all.
> 
> I don't think this is the right approach for the problem at hand.
> 
> > DBus is also SELinux aware and it looks like logic for something like
> > this might already exist. On my system I have:
> > /etc/selinux/mcs/contexts/dbus_contexts but it's empty so not sure
> > what
> > should be in it.?
> 
> It's probably reserved for dbus file contexts.
> 
> > There are many ways to fix a problem like this depending on a lot of
> > things.
> > 
> > > 
> > > 
> > > > 
> > > > 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).
> > 
> > I still do not understand exactly what problem you are trying to
> > solve
> > tho. What is running and what is it trying to do? Can you show some
> > error messages?
> > 
> > Are these lines the ones that are giving issues? Why do you need the
> > lines at all?
> > dbus_domain_transition(at_spi_t, user_dbusd_t)
> > dbus_domain_transition(gnome_settings_t, user_dbusd_t)
> 
> 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.
at-spi shouldnt be trying to start it.

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

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

> > > 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.
> 
> Regards,
> 
> Guido