SE-DBUS

[Havoc Pennington]

Hi,

On Mon, 2004-03-08 at 14:54, Stephen Smalley wrote:
> Not one of the listed contexts, but a context which has the necessary
> permission (acquire_svc) to the listed context for the service name.  So
> the mapping of service names to contexts is dbus-specific, but the
> central SELinux policy is consulted to see whether the requesting
> process context has permission to the service context.  Not just a
> direct matching of contexts.

Thanks, that makes sense.

> I think we'd be fine with such integration, provided that longest
> matching prefix matching on service names is still supported and there
> is an ability to specify a default context for the completely unmatched
> case.  But note that this is not an ownership rule, just a labeling of
> the service name for use in acquire permission checks.

Right, I understand that. I just want the dbus-specific stuff in the
dbus config file (dbus-specific = mapping dbus service names into
security contexts, i.e. the mapping from dbus terms to selinux terms).

Once we're dealing with security contexts and not dbus services, it
makes sense to me that it's all in the selinux policy file. Sounds like
we're on the same page.

Default context for the unmatched case makes sense, for sure.

Can you give me the use case for the longest matching prefix feature?
The reason current dbus policy doesn't support prefixed wildcarding is
that I figured it'd probably result in security holes, e.g. cups
namespace today might contain:

 org.cups.PrinterStatusCheckInterface

but in future someone might add:

 org.cups.PrinterRemoteControlInterface

If we say that org.cups.* can all be owned by some security context,
then any process that can obtain rights to PrinterStatusCheckInterface
can also own PrinterRemoteControlInterface, or MyRootKitInterface.

Keep in mind that service names are 99% of the time going to have only
two meaningful levels of hierarchy:
 a) which organization created them ("org.cups")
 b) the exact interface

For a), there is no logical relationship created; e.g. com.redhat. may
contain all kinds of unrelated interfaces. com.redhat.* wouldn't be
meaningful for a security policy.

For b), surely you want to specify the whole thing...

However this discussion plays out, it seems logical to me to keep the
whole dbus config file in sync and working the same way, at least for
analagous cases.

Where current dbus does allow a wildcard is a full wildcard:
 <deny send_destination="*"/> 

this is to let you set the default.

I'd say it's logical to do prefix-matching with an explicit glob:
 <allow own="org.cups.*"/>
just because this keeps people from accidentally allowing more than they
intended. But I can't think of an example where something like
org.cups.* is a good idea.

> >  - An orthogonal question is whether something like this is allowed:
> >    <policy security_context="foo_t">
> >      <allow send_destination="org.foo.bar"/>
> >    </policy>
> >    i.e. can a security-context-associated policy use the fine-grained
> >    access controls available to user and group associated policies. 
> >    I don't see why not, as it could allow additional security and 
> >    is essentially free to implement. It could never _open_ 
> >    holes not permitted by the send_msg policy in SELinux as that 
> >    check is separate.
> 
> Possible, but not clear how this would be used.

You would use this if you want to do more than simply allow/deny all
communication between two processes. e.g. you want to allow a process to
send messages XY but not message Z to service S.

For example, with CUPS we can block all messages other than the expected
ones from being sent and received. So even if a user app somehow obtains
send_msg rights when it isn't supposed to have them, it is still unable
to send anything weird to CUPS, only the usual printer status checks or
whatever.

I think the way I suggested is wrong though. One way to do it in the
spirit of your existing patch is to allow tagging a <policy> with the
equivalent of your acquire_svc/send_msg (what are these called?
capabilities?) and then the policy for which apps the <policy> applies
to comes from the SELinux config. 

So for example:
<policy capability="ask_cups_for_printer_status">
  <deny send_destination="*"/>
  <allow send_destination="org.cups.PrinterStatusCheck"
send_type="method_call" send_member="GetStatus"/>
</policy>

Then in SELinux config define which security contexts are allowed to do
ask_cups_for_printer_status just as you currently check for send_msg;
naturally you'd expect that the same apps that can connect to CUPS
directly can do this.

This way we keep the spirit of in the dbus config, mapping a dbus
concept into SELinux concepts; then in the SELinux config, setting the
policies to be applied to the concepts.

> Thanks for your comments.  Matt is away until June, but we will try to
> work on improving the patch as time permits until he returns and can
> resume his work on it.

OK. We may be able to work on this as well.

Havoc