policy analysis and generation work at...

© 2005 The MITRE Corporation. All rights reservedSELinux Symposium, March 2-4 2005 // Supported by the National Security Agency

Policy Analysis and Generation Work at MITRE

Amy L. HerzogJoshua D. GuttmanDavid R. HarrisJohn D. RamsdellAriel E. SegallBrian T. Sniffen


SELinux Policy Management

Goals of MITRE SELinux effort – Provide new capabilities to existing SELinux users – Lower barrier-to-entry for new types of SELinux installations

Sample scenarios:– Enterprise wants to use SELinux on internet-facing systems

Catch: Enterprise-specific applications must be supported

– Government organization wants to use SELinux as trusted base forparticular application, system

Require provable security, need policy as quickly as possible

:


One Solution

Build flexible, extensible policy management tools– Capture nuances of underlying system with appropriate model– Determine relevant security goals, policy design goals– Solve core problems while allowing for future expansion

Our Method: Information flow policy management tools– Focus on the creation and restriction of information flow

through the system– Support desirable flows, highlight undesirable flows

Currently Existing:– Policy analysis (with SLAT)– Policy generation (with polgen)

Planned for the future: – Compression, analysis extensions, requests?


Some Information Flow Problems

Policy generation:“I need to support this FTP server, but I want to make sure it’s

restricted by a least-privilege policy.”“My business requires these seven in-house tools to be able to

run on all of our web portals.” “I need an SELinux policy that supports segregation of various

types of information.”

Policy analysis:“I want to ensure that nothing other than the agent admin can

interfere with my monitoring agent.”“I want to know that these tools are only ones that can write

directly to the raw disk (or the package database, or…).”“I want to check that all mail flows directly through the virus-

checking program.”


Policy Generation with polgen


Policy Generation: General Approach

Focus on least privilege, automatic type generation: What does the program actually need to do? – Give the program only the privileges it actually needs

Basic idea: Program behavior pattern-based generation– What is the program trying to do?– What component interactions can we recognize?– What constitutes sensible policy for those interactions?

Benefits of this approach– Designed to support least privilege policies– Extensible:

Users can write their own recognizersNested levels of pattern support policy abstraction

– Mostly automated: Interactive policy generation


Polgen Walkthrough: Goal

Allow Jabber to run in a reasonable way on SELinux server– Open-source instant messaging server– Implemented by several processes, communicating by sockets– Clients run in user-space, server requires protection

Have some idea about goals ahead of time– Protect Jabber configuration files


Polgen Walkthrough: Overview

Capture information about candidate program with SELinux-aware strace, filter strace output– Currently dynamic tracing only—exercise program well!– Static analysis could be added as well

Detect information flow patterns in program behavior– Currently “local” patterns, e.g. shared library use

Suggest policy additions to the user– GUI supported by explanatory web pages– User decides which additions/changes make sense

Produce policy based on user input– Polgen-specific macros


Polgen Walkthrough: Pre-Work

Initial type generation accomplished with typegen– Seed configuration file, install new policy – Allows programs to be run in new type and easily identified in strace output, policy generation steps

Jabber typegen.conf file excerpt:

name jabberd2

role system_r types unconfined_t

exec jabberd /usr/local/bin/jabberd

...

exec s2s /usr/local/bin/s2s

dir jabberd_etc /usr/local/etc/jabberd

dir jabberd_var /usr/local/var/jabberd


Polgen Walkthrough: Collecting Traces

Exercise program with SELinux-aware strace– Functions only in permissive mode – Output from strace expansive, must be filtered

Jabber output ~2MB of text

Filter strace output with pre-processing script– Tracks read/write system calls to file descriptors created using

open(), socket(), pipe()– Tracks file descriptors through different processes, threads– Each output line contains PID, system resource,

resource/directory/domain contexts, system call, etc.

Filtered Jabber output 48KB of text. Sample line:335 Open "/usr/local/lib/libldap-2.2.so.7“root:object_r:lib_t FILE R root:object_r:lib_t 3 119 user_u:system_r:jabberd2_jabberd_t


Polgen Walkthrough: Recognizing Patterns

Run spar program on filtered strace output

Around one dozen patterns currently recognizable by spar– Temporary/configuration file use, shared library use, pipe use– Pipeline, mediator, proxy, hub-and-spoke

Some excerpts from Jabber traces: – Configuration file instances

General files in /etc/, /usr/local/etc/jabberd/ files, etc. – Also finds instance of “hub and spoke” pattern

A collection of processes (“spokes”) communicate with one another through a central “hub”In this case, router process acts as the hub


Polgen Walkthrough: Pattern Discovery

Polgen can also help user understand programs

– Patterns provide view into how the program operates

– These can suggest new information flow goals for programs

Example: Hub-and-spoke pattern in Jabber server

– This communication pattern also found in the Jabber documentation

– New information flow goal: Spoke processes communicate with one another only through hub

c2s

s2s router resolver

sm


Polgen Walkthrough: User Interaction

User presented with GUI– Choose patterns for which

they accept policy suggestions

– Optionally collect files in information-flow “groups”

– Confirm or reject all file type re-labeling

Contexts suggested depend upon patterns

– If no pattern detected, existing context shown

– For selected patterns, new type suggestions listed


Polgen Walkthrough: Interpreting Output

For assistance while using GUI, polgen produces a collection of web pages– Enhance human understanding– Describe pattern-recognition findings in hyperlinked way

Using frame, pages list– Processes found in traces– All pattern instances recognized in the traces– Manual actions requiring resolution– Security contexts found

When GUI completes, SELinux policy will be generated– .te file containing polgen-specific macro calls, “individual”

allows, type declarations– .fc file mapping types to filesystem


Web Pages: Config pattern Instance


Web Pages: Resources Accessed


Web Pages: Manual Actions Required


Policy Analysis with SLAT


Policy Analysis: General Approach

Focus on provable security guarantees: Does this policy meet these goals?

Basic Idea: Use model-checking algorithms to determine whether particular policy upholds information flow goals– Specify integrity, confidentiality goals with simple ‘diagram’

syntax– Particularly useful for specifying information flow pipelines– Receive proof that all goals are met or counterexample

Benefits of this approach– Clear answers about relevant security goals without looking

through policy– Extensible: If diagrams are not flexible enough, use logic


SLAT Walkthrough: Overview

Express information flow security goals in diagram format– Syntax easily translated from “pictures” of intended flows– Placed in SLAT input file

Construct model-checker input file from diagrams, policy.conf file– Use the lts2smv program to create input– SLAT currently uses NuSMV model checker

Examine output, perhaps correct policy– Model checker output includes counterexample if goals aren’t

met– Counterexamples can be traced to system executables and

corrected, added as exception for subsequent SLAT runs


SLAT Walkthrough: Protect Jabber Config Files

Ensure that any write-like flows ending in a configuration file type passes through an authorized role

Expressed as a picture:

Expressed in diagram syntax: [ r!:{sysadm_r}, TRUE;

r:{sysadm_r}, p=write;

]

t=jabberd_config_t;

*unauth

rolesysadm_r config_t

*, write


SLAT Walkthrough: Jabber “Hub-and-Spoke” Goal

One portion of goal: Ensure that information flowing from c2s process to s2s process always passes through router process

Expressed as a picture:

Expressed in diagram syntax: [ t=jabberd2_jabberd_c2s_t, TRUE+;

t=jabberd2_jabberd_router_t, TRUE+;

]

t=jabberd2_jabberd_s2s_t;

c2s_t router_t s2s_t* * **… …


SLAT Walkthrough: Interpreting Output

Trace Type: Counterexample

-> State: 2.1 <-t = sysadm_home_screen_tr = object_ru = user_uc = sock_file_cp = relabelfrom_p

-> State: 2.2 <-t = sysadm_tr = system_ru = system_uc = netlink_dnrt_socket_c

-> State: 2.3 <-t = initrc_tc = sock_file_c

-> State: 2.4 <-t = jabberd_config_tr = object_ru = user_uc = xserver_cp = write_p

Model checker returns either “specification is true” or counter-example

“Hub and Spoke” diagrams true

Configuration files diagrams unexpectedly false in our policy

– Object role can write to file by using relabeling permissions

– This rule inserted by policy author to enable screen to work

– User must now weigh benefit of screen vs. integrity gap


Summary

MITRE policy management tools create and restrict information flow throughout the system

Interactive policy generation through polgen– Generate policy for patterns, highlight points for human

decision Examine what the program is trying to doRecognize component interactions, or patternsSuggest sensible policy for those patterns

– Supports least-privilege policy generation

Provable policy analysis through SLAT– Simple diagram language for goal expression – Use model-checking algorithms to receive proof,

counterexample


Future Steps

Planned tool improvements: polgen– Expand collection of patterns recognized (“local” and more

abstract patterns)– Improve policy suggestions for all patterns– Enhance GUI usability – Investigate other dynamic analysis methods– Respond to community requests / suggestions

Planned tool improvements: SLAT– Respond to community requests / suggestions

Future tools planned: Compression, multi-policy analysis, composite analysis, ??


Further Information

Get software, share suggestions, for more information:– Amy Herzog ([email protected]), Brian Sniffen

([email protected]), John Ramsdell ([email protected]) – http://www.mitre.org/tech/selinux/

Questions?

mailto:[email protected]






http://www.mitre.org/tech/selinux/

http://www.mitre.org/tech/selinux/

policy analysis and generation work at...

Documents