SELinux Symposium Notes: Session 2

[Editor's note: more notes taken during the talks given at the 2006 SELinux Symposium. There are probably errors and they are definitely incomplete. Use at your own risk, etc.]

Moving FLASK to BSD Systems (Chris Vance, SPARTA, Inc.)

no perfect security model or policy for all applications –> want framework, not direct kernel mods
good design durable — don’t reinvent wheel; get frameworks correct, then use them
split policy from enforcement; port Flask framework to other kernels’ MAC framework
FreeBSD servers, OS X desktop, but shared heritage
Mach IPC – 1000s msgs/sec to secure; BSD, I/O Kit, Mach all have syscall interfaces
Flask, TE stuffed into MAC module; userspace easily ported, no special kernel headaches
LSM less invasive; MAC provides more hooks — different despite similar goals
Darwin: ubiquitous app-level IPC, bleeding b/t BSD & Mach
BSD coverage fairly complete; Mach experiment

Design and Implementation of the SELinux Policy Management Server (Karl MacMillan et. al., Tresys Technology)

incremental deployment & customization of policy; foundation of loadable policy modules
policy access control, not current all-or-nothing model
fine granularity of modifications made to policy — facilitates local mods (e.g. network contexts)
policy controls policy access — class user, class type, etc., & policy components are labeled
metapolicy to specify how domains are allowed to modify the policy
policy hierarchy restricts scope of modifications (e.g. child can’t exceed perms of parent)
policy mgmt server has same libsemanage interface, enforces metapolicy
future: network policy mgmt
(“metapolicy”: small subset of overall policy in most cases)

Towards Automated Authorization Policy Enforcement (Vinod Ganapathy, University of Wisconsin (et. al. from Pennsylvania State University))

i.e., where do we install hooks into a kernel or user app? how to build them?
(security-aware apps need to ask for policy decisions too for app-level objects) e.g. X
common features: multiple clients, shared resources, operations on behalf of clients
building security-aware apps: proactive or retrofit legacy code: add ref mon checks to code
insight: security-sensitive operations have fingerprints; how to find them? how to use them?
use: locate using static analysis, and add hooks at those locations
find: analyze runtime traces & compare them to shorter traces, paring down to the fingerprint (which traces contain the operation must be given)
must know what the security-sensitive operations are conceptually, but not their implementation

Comments are closed.