SE-DBUS

[Stephen Smalley]

On Wed, 2004-02-25 at 09:59, Havoc Pennington wrote:
> The way I expected the SELinux patch to work before seeing your patch
> was the same way UNIX groups currently work. That is, dbus daemon would
> query the SELinux contexts applying to each connection using the new
> getpeercon(), and then normal D-BUS policies would be applied based on
> those contexts. The policies would be defined in the standard D-BUS
> config files.
> 
> Can you back up and explain why this approach doesn't work and why you
> took the approach you did? (I probably need baby steps, don't assume I
> know too much about SELinux...)

Hi Havoc,

Thanks for looking at this.  Matt is in meetings most of today, so I
thought I would try to address your question.

Flexibility, analysis, protection, and management:
1) Flexibility - The SELinux architecture provides strong separation
between policy enforcement and policy decision-making, with a
well-defined API between them that has been designed and analyzed to
verify that it can support a wide range of security policies.  Directly
encoding the policy in the dbus configuration would weaken this boundary
and make it harder to change or extend the policy model without
corresponding changes to dbus-daemon itself.  dbus-daemon is just one
instance of a userspace policy enforcer; we have similar work in
progress for the X server, and anticipate corresponding changes to other
userspace apps that deal with multiple security contexts.  We would like
to have a unified model for all such enforcers rather than specialized
handling for each one.

2) Analysis - The approach you suggest would yield multiple
independently configured policies (i.e. the dbus configuration and the
normal SELinux policy) for what is actually a single mandatory access
control policy governing data flow in the system based on security
types.  That makes it difficult to analyze the overall security policy
being enforced by the system and would likely require further changes to
existing policy tools to handle the dbus configuration.

3) Protection - We want to be able to protect the dbus-related policy
(which as noted above is just part of a single mandatory policy) in a
manner consistent with the rest of the SELinux policy; splitting them up
makes this more difficult.

4) Management - With a single integrated policy, we can effect policy
changes in a coordinated manner and can provide a single interface for
managing the policy and delegating portions of policy management to
appropriate entities.  Work is actually soon to begin in this area.

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