Hi all
We need a gnome_dbus_chat_gconfd interface, but if I were to follow the same
development pattern as for instance gnome_dbus_chat_gkeyringd then I would
need to create a gnome_dbus_chat_gconfd(<prefix>, <userdomain>) and a
gnome_dbus_chat_all_gconfd(<userdomain>) interface.
Now, the one with prefix support is to work on the *_gconfd_t types. These
are all aliases to gconfd_t, so there is no need to have different
interfaces.
Is it ok to just have a gnome_dbus_chat_gconfd(<userdomain>) method?
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.
Wkr,
Sven Vermeulen
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)
I implemented the prefixes for gconfd because gconfd executes gnome
components on behalf of the user. The prefixes allow for confinement of
the desktop.
if you want to see what stuff gconfd runs see:
https://github.com/mypublicrepositories/myloginuser/commit/6466726fca0a391c37ba4ea0aaa27633be9fd98b
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...
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
On Fri, 2014-05-30 at 12:48 +0200, Sven Vermeulen wrote:
>
> 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 will leave that decision to you and others
My opinion though:
UBAC does not deal with the fact that we need to be able to tell selinux
when a confined domain needs to execute an file in a calling user domain
(or another confined domain type derived from the calling user domain)
On Fri, 2014-05-30 at 12:48 +0200, Sven Vermeulen wrote:
> Prefixes are used through the gnome_role_template() template for
> *_gkeyringd_t.
I did that because gkeyringd runs passwd (and maybe other coreutilities)
I wanted to be able to tell selinux that gkeyringd should run passwd in
the calling user domain (or alternatively a prefixed passwd domain)
On 05/30/2014 06:54 AM, Dominick Grift wrote:
> On Fri, 2014-05-30 at 12:48 +0200, Sven Vermeulen wrote:
>
>>
>> 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 will leave that decision to you and others
>
> My opinion though:
> UBAC does not deal with the fact that we need to be able to tell selinux
> when a confined domain needs to execute an file in a calling user domain
> (or another confined domain type derived from the calling user domain)
The preference would be to keep a common domain and separate it with UBAC except for the cases, as Dominick states, have type transition problems. Su and sudo are examples where the domains are essentially equivalent, but they have derived types so the default transition is back to the calling domain on shell exec().
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com