Core Policy Management Infrastructure for...

© 2005 Tresys Technology, LLC (www.tresys.com/selinux, [email protected])

Core Policy Management Infrastructure for SELinux

2005 SELinux Symposium

Karl MacMillan <[email protected]>Tresys Technologyhttp://www.tresys.com

mailto:[email protected]

mailto:[email protected]


Core Policy Management Infrastructure

Production systems need policy managementaddition and removal of application policyupdates to existing policyuser and role administration

Required to fully leverage dynamic policycore capability availablesupporting infrastructure required

Infrastructure needs to be secure and robustideally across multiple systems


Policy Management Robustness

Current policy management not robustchanges and updates use a compile process

errors are compile errorsrequires complete development environment

no strong dependency modelsource policy is closely coupled

difficult to automate with toolsCurrent weaknesses force compromises

Fedora / RHEL does not require source policyprevents important local customizations

Some workarounds availabletransformation of binary policy on load


Policy Management Security

Policy modifications are controlledbut only in a granular way

Single permission for policy loadinggrants access to change any portion of the policyno provision for least-privilege

e.g., seuser granted complete policy controlNo secure delegation of policy administration

give ability to change portion of a policyensure that overall policy intent not changed

No means to verify security goals on policy changee.g., automated analysis

Policy managed on a single system basis


User-space Object Managers

User-space object managersenforce access control over internal resourcesusing the SELinux access control model

DBus, passwd, and X are current examplesCreates additional object classes

currently requires kernel modificationsno dynamic object class registration

All policy loaded into kerneleven policy only enforced in user-spacewastes precious kernel resources


Policy Management Projects

Tresys working on two projectspolicy modulespolicy server

Both addresses robustness and securityPolicy modules functionally complete

submission for upstream soonPolicy server in progress

continuation of module workprototype available

Projects available on Sourceforgehttp://www.sf.net/projects/sepolicy-server


Policy Module Introduction

Three main goalscreate manageable binary policy modules

different from existing kernel binary formatincluding labeling information

support loosely coupled policiesstrong dependency model

infrastructure to securely manage modulesmanage and link modules on production systemsmaintain consistent, coherent policy at all timesverify security goals on policy change

Other design goalsmigration path from existing infrastructurepreserve existing kernel binary format


Policy Module Architecture Introduction

Two major componentsdevelopment tools

checkmodule, sepackagemodule, . . .policy module store and tools

semodule

Development toolsallow policy developers to create policy modules

Policy module store and toolsmanage policy modules on production systems


Policy Module Infrastructure

Module Store

modulesbase

module

linker

linkedpolicy

expander

kernelbinary

Kernel

policysource

filecontexts

checkmodulebase

packagefile

contexts

semodule

filecontexts

checkmodule

policypackageapplication

source

development

production

policymodule

basemodule


Policy Module Challenges

Linking modules requirespreserving and expanding attributesexpanding wildcards (‘*’ and ‘~’)

in both rules and declarationsaddition and awareness of identifier scope

Required widespread changes to libsepolmodified libsepol supports

kernel binary formatbase module formatmodule format

security-server functionality only supports kernel format


Policy Store and Tools

Policy store is structured files and directoriesprotected by the policycontains modules and file contexts

semodule manages the policy storeprovides atomic transactions

multiple modules can be added or removedfailures result in abort of entire transactionenforces consistency and coherency

performs locking against multiple writersexecutes policy verification applicationscreates and loads kernel binary


Checkmodule

New policy compiler for modulesIntroduces new language features

language subset for modules - excludesobject class declarationlabeling statements

dependency handling of policy identifiersusers, roles, types, attributes, object classes, and boolsboth required and optional identifier sets

link-time conditional policy statementsbased on optional identifier sets

Shares substantial code with checkpolicy


Module Language Examplemodule 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 };

}


Policy Server Introduction

Three goalsfine-grained policy access control

least-privilege on policy changedelegation of policy management

enhanced policy management (local and remote)robust support for user-space object managers

Architecture comprised of two componentspolicy management serveruser-space security server


Architecture Overview

Policy management servercontains canonical policymediates all changes to policy

eventually including remote changesenforces access control on policy

policy object modelhierarchical constraints

distributes policy to security servers (user and kernel)kernel only receives kernel policy

User-space security serverprovides access control decisions to user-spacedynamic object class management / registration


Language extensions

Policy object modelabstraction of policy into object classes

e.g., policy.user, policy.role, policy.typeobjects explicitly labeled – “policycon”policy rules controls changes to policy – “meta-policy”

Hierarchical constraintsintroduces hierarcy into policy identifier namespaces

e.g., “apache”, “apache.cgi”, “apache.cgi.user”children’s access constrained to be a subset of the parentpatches and separate verifier available


Policy Management Infrastructure

QUESTIONS?

Date post:	02-Jan-2019
Category:	Documents
Upload:	lamque
View:	223 times
Download:	0 times

Core Policy Management Infrastructure for...

Documents