OpenXT Summit Modular Policy -> Access Control Session

[Stephen Smalley]

Hi,

I'd like to propose changing the Modular Policy discussion session on
day 2 with a broader discussion of OpenXT access control. Below is a
draft list of discussion topics to cover in this session. Please
suggest any additions, changes, or removals, as well as provide feedback
on the proposal to expand the scope of the session.

Session: OpenXT Access Control: XSM/Flask, SELinux, v4v firewall,
rpc-proxy, and more!

Topics:

* Unifying access control in OpenXT

OpenXT makes rich use of a variety of existing access control
mechanisms, such as XSM/Flask, SELinux, and XenStore permissions and
introduces several of its own unique access control mechanisms, such
as the v4v and rpc firewalls and hardcoded logic in the rpc-proxy and
other components such as dbd. While each of these mechanisms serves a
legitimate purpose in the OpenXT architecture, they differ in
semantics, policy languages, flexibility/configurability and
trust/assurance implications. The result is a system whose overall
security policy is difficult to understand, analyze, and check against
security goals, and whose trusted computing base is larger and
potentially less amenable to dom0 decomposition than desired.

This topic is to explore the current state of access control
architecture in OpenXT and initiate a dialogue on how we might migrate
toward a more unified access control architecture.

* Improving the use of XSM/Flask

XSM/Flask is enabled and enforcing in OpenXT, with separate Flask
domains for each kind of domain/VM used in OpenXT (e.g. dom0, ndvm,
uivm, stubdom, guests). In OpenXT, XSM/Flask establishes a mandatory
policy over inter-VM communications (IVC) via grants, event channels,
and v4v that provides a hard upper bound over allowed IVC. However,
OpenXT is not presently using various capabilities of XSM/Flask, some
of which were added to XSM/Flask after OpenXT's predecessor was first
developed. These unused or underutilized features include
capabilities such as:
- leveraging XSM/Flask to support dom0 decomposition,
- controlling which domains can use device passthrough (and for which
devices),
- enabling creation of domains whose memory cannot be read by dom0
once created,
- enabling creation of fully isolated domains,
- enforcing information flow between domains (e.g. guest -> nilfvm ->
ndvm), and
- providing peer domain context information for use in userspace
access control decisions,

This topic is to discuss how we might advance OpenXT's usage of
XSM/Flask to meet platform security goals or better support third
party usage of OpenXT.

* Leveraging SELinux more fully

SELinux is enabled and enforcing in dom0 and in the network driver VM
(ndvm), with separate SELinux domains for each of the processes
running in these VMs. In OpenXT, SELinux is applied to harden dom0
and the ndvm, limiting the services within them to least privilege and
constraining even admin logins. SELinux is also leveraged to confine
and isolate qemu instances if running without stub domains (although
stub domains are the default in OpenXT).

While OpenXT's usage of SELinux is beneficial, it fails to fully
capitalize on SELinux's abilities, such as:
- tailoring the SELinux policy for each VM to that VM's particular
functionality and security goals,
- fully confining all processes to least privilege (i.e. removal
of the unconfined module and fully specifying allowed actions for
all domains),
- enforcing specific security goals across all (or most) processes,
such as W^X, kernel self-protection, restricted-ptrace, and
- enforcing D-BUS restrictions (to complement and potentially obsolete
portions of the rpc firewall).

SELinux is also not presently leveraged in the user interface VM
(uivm) atl all, nor is it being leveraged for userspace access control
by the OpenXT userspace components.

Further, SELinux is not being leveraged to enforce access controls
over v4v accesses by individual processes within a domain. SELinux
could be leveraged to enforce specific access controls over which
processes can send or bind to specific v4v ports, providing true
separation of the v4v endpoints in SELinux-enforcing domains, and to
limit which Linux v4v ioctls can be used by different processes.

Lastly, SELinux is only being applied locally within a VM/domain, and
is not being leveraged to convey local process security contexts to
other domains on IVC requests. This could be used to support userspace
access control decisions based not only on the sending domain but also
the sending process within that domain.

This topic is to discuss how we might leverage SELinux more fully
in OpenXT.

* Modular policy and policy management

Upstream XSM/Flask presently only supports building monolithic policy.
XSM/Flask provides support for dynamic reloading of the entire policy
and finer-grained mechanisms for specific forms of runtime policy
manipulation such as object labeling and boolean changes via the
hypercall interface. Tools exist for reloading policy or altering such
settings from dom0, but no real support exists for any persistent or
higher level policy management.

Modern Linux distributions support SELinux modular policy and (local)
policy management facilities. Prior work (e.g. the SELinux policy
management server) has explored distributed policy management and
access control over policy changes (meta policy), but this has not
transitioned from prototypes to production code. Policy management
tools exist for Linux, but are limited to local administration of
policy and presume a single tenant/owner of policy.

In OpenXT today, XSM/Flask and SELinux policies are each built from a
single source package, are fully compiled during system build, and are
installed as part of the read-only, measured root filesystem. As
such, even when policy is built modularly (as it is for SELinux), that
modularity is not being leveraged to support per-package or per-VM
policies even in the source tree, and policy modules cannot be added
or removed at runtime (aside from upgrades). The OpenXT XSM/Flask
policy further does not presently allow any policy changing hypercalls
at runtime.

This topic is to discuss modular policy and policy management at all
levels of the system, from hypervisor to guest and VM packaging. What
capabilities are needed at build time and at runtime for OpenXT, and
how can we best achieve them in a manner that preserves the platform
security properties?

* rpc-proxy and v4v firewall: Current State and Future Directions

This topic is to discuss rpc-proxy and v4v firewall, looking at their
current state and where we want to take them going forward. This may
end up being covered by the first topic above, but is called out here
separately to ensure we discuss them at some point.