SE-DBUS

[Stephen Smalley]

On Sat, 2004-03-06 at 16:20, Havoc Pennington wrote:
>  - for sepolicy.conf.in, we define a mapping from service *names* 
>    to security contexts. If I understand correctly, any connecting
>    process with one of the listed contexts is allowed to own the 
>    service or any service starting with that string. This configuration 
>    is dbus-specific. If I have this wrong please correct me.

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.

>  - for sending a message from connection A to connection B, we check 
>    the actual security contexts read from those file descriptors, 
>    and see if send_msg is allowed. This allow/deny is in the SELinux 
>    conf files not in anything dbus-specific. please correct this if 
>    confused.

Right; the contexts are obtained from the kernel via getpeercon.

>  - If I have the above correct, I think we should replace sepolicy.conf
>    with an extension to the regular dbus config file format, simply:
>    <policy security_context="foo_t">
>      <allow own="org.foo.bar"/>
>    </policy>
>    this avoids the whole extra config file parser. Since selinux.conf
>    is totally dbus specific anyway and even in the same location as the 
>    dbus conf files, I don't see why it should be a separate format.
>    It can be a separate file, as <include> directives are supported.

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.

>  - 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.

>    However, I wonder if a separate send_msg capability makes sense; 
>    perhaps the permission check here should just hinge on whether
>    process A could normally write to a pipe or socket going to 
>    process B. i.e. is there a case where you want to control 
>    whether A and B can talk via dbus separately from whether A and 
>    B can talk at all? Or is fine-grained automatically better?
>    Are pipes, sockets, and other IPC mechanisms distinguished today?

Yes, we would like to support such distinctions at the lowest level, and
the SELinux policy does this today for pipes, sockets, and other IPC
mechanisms.  Higher level policy languages may eventually be developed
that hide this granularity when it isn't necessary, but it is desirable
to support it.

>  - If there are policies keyed off security context, is it more 
>    complex than "connection has security context foo_t" when deciding 
>    whether to apply the policy? I get the impression it is

I'm not certain I understand your question, but the policy is:
- always applied,
- based on pairs of contexts (and object security class and operation),
- concerned about data flow in the system among security contexts, in
order to enforce confidentiality and integrity requirements.

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.

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