DBus session bus -> separate security class?

DBus session bus -> separate security class?

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

Hi,

I'm working on updating the DBus policy to handle the addition of the
user session DBus instance.  However I ran into a problem - if we want
the user session DBus to be a userspace object manager as well (and I
think we do, long term), I think we really need for it to be a separate
security class.  Otherwise, there's no way to distinguish between the
two in the security policy.  For example, we might want to say in the
policy:

allow cupsd_t userdomain:dbus { send_msg };

to allow userdomain control over the CUPS daemon.  However this would
also mean that any session bus would allow the CUPS daemon to send
messages, if the cups daemon somehow got access to it (which is
unlikely, since it would have to have access to user_tmp_t:fifo_file,
but still).

Conversely, we might want to say for the session bus:

allow user_mozilla_t user_networkmanager_t:dbus { send_msg };

to e.g. allow Mozilla to tell the user's networkmanager (all running in
the user session) that it's ready to go offline.  We wouldn't want this
permission to be granted by the system bus daemon (although again this
is likely to be stopped by earlier permissions).

So I think we really want:

allow cupsd_t userdomain:system_dbus { send_msg };
allow user_mozilla_t user_networkmanager_t:session_dbus { send_msg };

I think unfortunately it's a bit late to change this for Fedora Core 3,
so likely what we'll do is just not have the session bus be a userspace
policy enforcer, or just run as user_t.  But long term I think we need
separate security classes.

Thoughts?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: DBus session bus -> separate security class?

[Stephen Smalley]

On Wed, 2004-09-01 at 12:03, Colin Walters wrote:
> I'm working on updating the DBus policy to handle the addition of the
> user session DBus instance.

In its own derived domain, using a macro, I hope.  $1_dbusd_t for $1 in
userdomain.

> So I think we really want:
> 
> allow cupsd_t userdomain:system_dbus { send_msg };
> allow user_mozilla_t user_networkmanager_t:session_dbus { send_msg };

Not clear that even this is what you want, as you may want to allow
different flows through the different user session bus instances.

It seems like a more general solution would be to alter the manner in
which dbusd labels its connections.  Instead of simply labeling them
with the peer context, you could call security_compute_create (which
internally maps to the kernel's security_transition_sid interface and
uses type_transition rules) on the peer context and the bus context, and
define type transition rules to map to derived types based on the pair
of contexts.

> I think unfortunately it's a bit late to change this for Fedora Core 3,
> so likely what we'll do is just not have the session bus be a userspace
> policy enforcer, or just run as user_t.  But long term I think we need
> separate security classes.

I don't think you want it to run in user_t or dbusd_t.  You want a
derived domain.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: DBus session bus -> separate security class?

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Wed, 2004-09-01 at 12:39 -0400, Stephen Smalley wrote:
> On Wed, 2004-09-01 at 12:03, Colin Walters wrote:
> > I'm working on updating the DBus policy to handle the addition of the
> > user session DBus instance.
> 
> In its own derived domain, using a macro, I hope.  $1_dbusd_t for $1 in
> userdomain.

Yes.

> It seems like a more general solution would be to alter the manner in
> which dbusd labels its connections.  Instead of simply labeling them
> with the peer context, you could call security_compute_create (which
> internally maps to the kernel's security_transition_sid interface and
> uses type_transition rules) on the peer context and the bus context, and
> define type transition rules to map to derived types based on the pair
> of contexts.

That does sound more general.  So were this implemented, the policy
might look like this:

type_transition cupsd_t $1_t:dbus $1_cupsd_t;
allow $1_cupsd_t $1_t:dbus { send_msg };

Is that correct?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: DBus session bus -> separate security class?

[Stephen Smalley]

On Wed, 2004-09-01 at 14:08, Colin Walters wrote:
> That does sound more general.  So were this implemented, the policy
> might look like this:
> 
> type_transition cupsd_t $1_t:dbus $1_cupsd_t;
> allow $1_cupsd_t $1_t:dbus { send_msg };
> 
> Is that correct?

Hmm...I was thinking that one would compute a derived type when a
service is acquired based on the peer context and bus context, and then
perform checks between the sender's context (obtained via getpeercon, no
derivation on send) and the derived context computed earlier when the
service was acquired.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.