From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 30 May 2014 12:48:03 +0200
Subject: [refpolicy] Do we need to keep "aliased" interfaces?
In-Reply-To: <1401445749.6837.8.camel@x220.localdomain>
References: <20140529165745.GA10882@siphos.be>
	<1401445749.6837.8.camel@x220.localdomain>
Message-ID: <20140530104803.GA1540@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, May 30, 2014 at 12:29:09PM +0200, Dominick Grift wrote:
> On Thu, 2014-05-29 at 18:57 +0200, Sven Vermeulen wrote:
> 
> > I really dislike the "all_gconfd" one as, in my opinion, it implies that
> > there are multiple gconfd domains "tied" together with some attribute, which
> > isn't the case.
> > 
> 
> I do not understand what you mean.
> 
> gconfd_t is aliases to $1_gconfd_t (i suppose) this is so that if a
> policy uses the older gconfd_t type that the interfaces still work
> 
> It is (i suppose) not the other way around)

Well, I just did a small test to try and confirm how aliases work.

  type foo_t;
  files_type(foo_t)
  typealias foo_t alias bar_t

  allow user_t foo_t:file read_file_perms;

With this loaded, my user can read files of both foo_t and bar_t labels.

If I change the allow rule to

  allow user_t bar_t:file read_file_perms;

then the user can still read both foo_t and bar_t.

So in my opinion, aliases do not make any "segregation" between types, and
are mostly useful when migrating policies (so that you can still continue to
use the old name for a while, even though it has been renamed).

> I implemented the prefixes for gconfd because gconfd executes gnome
> components on behalf of the user. The prefixes allow for confinement of
> the desktop.

Prefixes are used through the gnome_role_template() template for
*_gkeyringd_t.

But are prefix domains still something we want to work on? I thought that
proper desktop confinement is better done using the user-based access
control constraints. I know Fedora doesn't use UBAC by default, but it does
look like a valid approach to desktop confinement (that together with more
application domains).

We're using UBAC in Gentoo for a while now without major problems. The only
"downside" I see is that it cannot be overruled easily - I cannot allow
staff_u to read user_u files unless I update the UBAC constraint itself,
which would still be possible with prefixed domains. But I haven't
encountered the need for this situation yet.

> If you are going to allow "userdomain" to dbus_chat with all gconfd
> domain then that breaks the ability to confine desktop sessions from
> that perspective. Becuase userdomain in a core type attribute. It is not
> so easy to work around that one.
> 
> Not to mention that not all usedomains should be allowed to dbus chat to
> gconfd. only unpriv_userdomains (e.g. must have atleast access to GUI
> env, must have atleast access to login.
> 
> With gnome3, gconfd is pretty much gone. So this is legacy anyways but
> still...

I wouldn't allow a generic user domain access - in Gentoo I placed it, for
now, in the gnome_role_template() so that user domains that are allowed to
work with GNOME can.

Wkr,
	Sven Vermeulen