Evaluating SENG Paul Kuliniewicz CS 526 Project Fall 2005 Background SENG experimental alternative policy language for SELinux Goal eliminate the need for macros in the existing language Macros complicate policy analysis Approach Add high level features to policy language to replace typical macros Current Status Last semester Initial design of SENG This semester Evaluated whether it meets its design goals Verdict A promising start but still work to do Introduction to SELinux Adds MAC support to Linux kernel Access decisions controlled by policy Model based on type enforcement Each process assigned a domain Each object assigned a type Domains granted permissions over types Access allowed if process s domain has the desired permission over the object s type Problems with Existing Language Policy rules operate on TE matrix directly All higher level abstractions implemented through preprocessor macros Macros can have arbitrary effects not even bound by syntax of policy language Policy analysis tools can t handle macros No good way to model macro behavior in TE Solution Add well defined language features to replace macros SENG Features Sets Group together related domains types classes or permissions permset r file perms addto r file perms read getattr lock ioctl SENG Features Abstract Resources Combine multiple objects into a single resource that can be used in an allow rule resource shared libs use addto shared libs use d allow d ld so file rx file perms allow d device dir search allow spamd t shared libs use SENG Features Templates Creates new domains and types derived from existing ones type ANYDOMAIN log t resource log write addto log write d type transition d var log t dir d log t file automatic allow spamd t log write Analysis Methodology Question Do SENG s features eliminate the need for macros and make policies easier to write Try rewriting part of the example policy using SENG Policies for SpamAssassin AMaViS and ClamAV Verdict SENG helps but still some problems Some desirable policies can t be expressed Some language features have awkward syntax Major Problems No support for existing language s self keyword Impossible to accurately have a domain refer to itself in a rule Solution add support for it Some macros have no SENG equivalent Take domain and type as parameters and operate on them Solution abstract permissions similar to abstract resources but apply to any type not just predefined ones More Major Problems SENG treats domains and types as distinct But some permissions can be assigned to non domain types Solution don t treat domains as special Type transitions are hard coded into compiler Limits flexibility given to policy writer Solution allow policy writer to specify custom kinds of type transitions Even More Major Problems Using ANYDOMAIN in domain template forbidden Prevents recursive instantiation and unbounded policy growth at compile time But too conservative Such templates can be useful Solution Allow it but have compiler check for recursion No support for conditionals Needed to prevent tight coupling of modules Solution Add support for them Minor Problems Syntax for adding elements to sets is awkward Solution allow sets to be populated in definitions Single flat namespace causes too many conflicts Solution use separate namespaces whenever possible Conclusion SENG doesn t solve all problems in existing language Goal of eliminating need for macros is feasible But most remaining ones do have a clear solution Current design of SENG is a promising start Next deadline 2006 SELinux Symposium
View Full Document
Unlocking...