Core Policy Management Infrastructure for SELinux

Transcription

1 Core Policy Management Infrastructure for SELinux 2005 SELinux Symposium Karl MacMillan Tresys Technology

2 Core Policy Management Infrastructure Production systems need policy management addition and removal of application policy updates to existing policy user and role administration Required to fully leverage dynamic policy core capability available supporting infrastructure required Infrastructure needs to be secure and robust ideally across multiple systems

3 Policy Management Robustness Current policy management not robust changes and updates use a compile process errors are compile errors requires complete development environment no strong dependency model source policy is closely coupled difficult to automate with tools Current weaknesses force compromises Fedora / RHEL does not require source policy prevents important local customizations Some workarounds available transformation of binary policy on load

4 Policy Management Security Policy modifications are controlled but only in a granular way Single permission for policy loading grants access to change any portion of the policy no provision for least-privilege e.g., seuser granted complete policy control No secure delegation of policy administration give ability to change portion of a policy ensure that overall policy intent not changed No means to verify security goals on policy change e.g., automated analysis Policy managed on a single system basis

5 User-space Object Managers User-space object managers enforce access control over internal resources using the SELinux access control model DBus, passwd, and X are current examples Creates additional object classes currently requires kernel modifications no dynamic object class registration All policy loaded into kernel even policy only enforced in user-space wastes precious kernel resources

6 Policy Management Projects Tresys working on two projects policy modules policy server Both addresses robustness and security Policy modules functionally complete submission for upstream soon Policy server in progress continuation of module work prototype available Projects available on Sourceforge

7 Policy Module Introduction Three main goals create manageable binary policy modules different from existing kernel binary format including labeling information support loosely coupled policies strong dependency model infrastructure to securely manage modules manage and link modules on production systems maintain consistent, coherent policy at all times verify security goals on policy change Other design goals migration path from existing infrastructure preserve existing kernel binary format

8 Policy Module Architecture Introduction Two major components development tools checkmodule, sepackagemodule,... policy module store and tools semodule Development tools allow policy developers to create policy modules Policy module store and tools manage policy modules on production systems

9 Policy Module Infrastructure file contexts application source checkmodule policy module policy package Module Store modules base module linker K development production semodule linked policy e r n file contexts expander e l policy source checkmodule base module base package file contexts kernel binary

10 Policy Module Challenges Linking modules requires preserving and expanding attributes expanding wildcards ( * and ~ ) in both rules and declarations addition and awareness of identifier scope Required widespread changes to libsepol modified libsepol supports kernel binary format base module format module format security-server functionality only supports kernel format

11 Policy Store and Tools Policy store is structured files and directories protected by the policy contains modules and file contexts semodule manages the policy store provides atomic transactions multiple modules can be added or removed failures result in abort of entire transaction enforces consistency and coherency performs locking against multiple writers executes policy verification applications creates and loads kernel binary

12 Checkmodule New policy compiler for modules Introduces new language features language subset for modules - excludes object class declaration labeling statements dependency handling of policy identifiers users, roles, types, attributes, object classes, and bools both required and optional identifier sets link-time conditional policy statements based on optional identifier sets Shares substantial code with checkpolicy

13 Module Language Example module test 1.0; require { class file { getattr setattr read write ioctl read execute entrypoint lock };... attribute domain, userdomain, file_type, exec_type; role sysadm_r, user_r, system_r; type sysadm_t, user_t; } optional gnome { type gnome_t, xserver_t; } type test_t, domain; type test_exec_t, file_type, exec_type; role sysadm_r types test_t; role user_r types test_t; domain_auto_trans(userdomain, test_exec_t, test_t) ifopt (gnome) { allow test_t gnome_t : file { getattr read }; allow test_t xserver_t : file { read write ioctl getattr setattr }; }

14 Policy Server Introduction Three goals fine-grained policy access control least-privilege on policy change delegation of policy management enhanced policy management (local and remote) robust support for user-space object managers Architecture comprised of two components policy management server user-space security server

15 Architecture Overview Policy management server contains canonical policy mediates all changes to policy eventually including remote changes enforces access control on policy policy object model hierarchical constraints distributes policy to security servers (user and kernel) kernel only receives kernel policy User-space security server provides access control decisions to user-space dynamic object class management / registration

16 Language extensions Policy object model abstraction of policy into object classes e.g., policy.user, policy.role, policy.type objects explicitly labeled policycon policy rules controls changes to policy meta-policy Hierarchical constraints introduces hierarcy into policy identifier namespaces e.g., apache, apache.cgi, apache.cgi.user children s access constrained to be a subset of the parent patches and separate verifier available

17 Policy Management Infrastructure QUESTIONS?