[refpolicy] Do we need to keep "aliased" interfaces?

[sven.vermeulen@siphos.be (Sven Vermeulen)]

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