Contents

This manual documents polgen, a collection of Security-Enhanced Linux Policy Generation Tools, version 1.4.

Copyright © 2007 The MITRE Corporation.

This manual and the program it documents are free software; you can redistribute each and/or modify each under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

1. Introduction

In January of 2001, the National Security Agency released a prototype version of a security-enhanced Linux system. They implemented Mandatory Access Control (MAC) security mechanisms, providing flexible support for a wide range of security policies. Both type enforcement and role-based access control components were incorporated into the access controls. Recent reference policy developments have improved policy generation support by modularizing policy.

This document describes how to use MITRE's SELinux policy generation tools, collectively called polgen, which provide a systematic way to generate reference policy for programs on an SELinux system. polgen generates policy for a program based on patterns in the program's behavior. This process is predictable and repeatable, but interactive. The user, presented with a suggested policy description, can review and modify that description before actual policy is produced. Also, polgen supports optional policy analysis to ensure that the newly generated policy does not adversely affect existing (enforced) security goals.

This manual assumes some knowledge of the SELinux system. In particular, we assume the reader is familiar with basic SELinux enforcement mechanisms, reference policy file format, security contexts, and class-permission pairs. Readers can refer to "Configuring the SELinux Policy" for background. This document is included in the SELinux distribution. The section titled "Flask Concepts" is particularly important.

polgen makes use of the pre-existing module interface files. These must be loaded on your system. They should be available from the same source that gave you your policy. Red Hat distributes them as a package called selinux-policy-devel. To see if selinux-policy-devel is installed, type rpm -ql selinux-policy-devel. If it is not installed you will need to install it by typing yum install selinux-policy-devel.

You can read this document by any of three modes. First, to get started you can read the material in the Installation and Quick Start sections. Second, if you are interesting in details about each of the polgen components there are several sections to explore. In Capturing Program Behavior, we describe the use of software architecture modeling and of dynamic trace analysis to capture system call-level program behavior and SELinux information. In Recognizing Patterns, we provide an overview of our behavior analysis approach and cover the use of the spar pattern recognizer. Following this in Post-Processing, we describe the generated files. In Batch-Processing Script, we provide the user with a modifiable script that will run all post-behavior-capture polgen components. Advanced Techniques describes how to write your own pattern recognizers. The third mode is to follow the details of a worked example. Complete Example section contains a guide to the worked example that is included in this distribution.

2. Installation

These tools are packaged according to GNU standards. For complete information, see the `INSTALL' file included with this distribution. However, the distribution can be easily compiled and installed in the following way:

The polgen tarball includes the spar pattern-recognition engine and an SELinux-aware version of strace. In addition, we include our example E-Commerce suite.

1. tar xzf polgen-1.4.tar.gz
2. Change to the directory containing the package's source code. Run the command ./configure. You can change the location of the installation; this manual will assume it has been installed into /usr/local.
3. Type make to compile the package.
4. Type make install to install the programs, data files, and documentation.
5. Copy /usr/local/share/polgen/polgen.if to /usr/share/selinux/devel/include/services/. This installs the polgen utility macros where they'll be available for newly written policy.

To confirm that the polgen programs were installed properly, try the following:

$ type -all stracesc
stracesc is /use/local/bin/stracesc

3. Quick Start

The generation process can be performed entirely on an SELinux machine, or it can be split between an SELinux machine and another machine. The type generation, stracesc, and stracesc filtering components must be run on an SELinux system. Pattern recognition and policy generation can be performed elsewhere if desired; use the --with-stracesc=no option when installing polgen on the secondary system.

Once installation is complete, there are four distinct phases when generating policy with polgen. The basic steps of polgen usage are:

• Initialization, bringing the program onto the SELinux system and putting it into a temporary type;
• Dynamic capture of traces of the program's behavior and processing those traces;
• Pattern recognition on the traces;
• Interactive decisions to modify the generation of a policy.

We start this section with a short list of commands run in the most typical use of polgen.

3.1 Command List

Substitute the program you wish to analyze for program_name, and the directory into which that program was installed is program_dir (e.g., /usr/local). The commands below will create a minimal set of types to bootstrap the analysis, invoke information flow capture, and run the polgen services.

1. Generate basic initial types for the program and place the program in those types. The easiest way to acomplish this is by writing a polgen .psl file called program_name.psl for the application and have polgen create the .te, .if, and .fc files. A minimal .psl file will contain the following lines.

   prefix=program_dir exec_prefix=$prefix/bin logdir=/var/log component $exec_prefix/program_name { entry_point 1 type process reads { /etc/program_name.cfg } writes { $logdir/app.log } }

   Be sure to include all the new directories and file names that the program will access via reading or writing. entry_point 1 indicates that this component is an entry point for program execution. This corresponds to a type_transition statement in the .te file. Other more extensive examples of .psl files appear later in this manual.

   The spar pattern recognizer (one component of the polgen software) will create the initial, temporary policy in a directory called results:

   $ spar -n program_name

   Following this, you should add the temporary module to the overall policy.

   $ cd results $ make -f /usr/share/selinux/devel/Makefile # /usr/sbin/semodule -i temp_program_name.pp # /sbin/restorecon -v -r program_dir /etc/program_name.cfg

2. Capture traces of behavior.

   To trace the behavior of the program on the target SELinux system, run it inside the modified strace:

   $ stracesc -fX -o trace_path program_name command_line_args $ trackall trace_path

   While the program is running, exercise it in as many different ways as possible. polgen will only learn about behaviors you demonstrate here. The trackall program will filter the stracesc output, producing digested trace files containing only the system call information useful for pattern recognition. You can control the output directory of trackall with the option -o. The naming convention for these files is program_name.tracked.

3. Analyze the tracked information.

   $ firefox file:///`pwd`/results/home.html

   Now rerun all the steps above starting with running spar. Before it looked only at the tiny .psl file you wrote. Now it will learn also from the dynamic behavior as captured in the .tracked files. As you proceed, use program_name.pp instead of temp_program_name.pp.

Here ends the quick-start. The rest of this manual provides a more detailed explanation of how and why to use polgen.

4. Capturing Program Behavior

polgen helps you generate new types for your programs based on seeing them run. To see them run on an SELinux system, they must already have types.

To bootstrap this policy generation process, one must set up an initial set of types and create .te, .fc, and .if files for the program under analysis. This can be done in a minimalist fashion by cutting and pasting from other modules, or you can create a .psl file in which you describe the architecture of the program and offer advise on what should go into the policy. The next section provides information on PSL.

4.1 Polgen Specification Language (.psl) files

Application designers and developers may wish to initiate the analysis by entering a description of the software in terms of its components and connectors. To do this you can generate a .psl file and place it in directory containing the program analysis.

The following example is an psl description of jabberd suitable for bootstrapping the analysis.

prefix=/home/user_name/opt/jabberd
exec_prefix=$prefix/bin
etcdir=$prefix/etc
pkgetcdir=$etcdir/jabberd
vardir=$prefix/var
pkgvardir=$vardir/jabberd
logdir=$pkgvardir/log
piddir=$pkgvardir/pid

component $exec_prefix/jabberd {
     entry_point 1
     type process
     reads { $pkgetcdir/jabberd.cfg }
}

component $exec_prefix/c2s {
     type process
     reads { $pkgetcdir/c2s.xml}
     writes { $piddir/c2s.pid,
              $logdir/c2s.log}
}

component $exec_prefix/s2s {
     type process
     reads { $pkgetcdir/s2s.xml}
     writes { $piddir/s2s.pid,
              $logdir/s2s.log}
}

component $exec_prefix/router {
     type process
     reads { $pkgetcdir/router.xml, router_users.xml}
     writes { $piddir/router.pid,
              $logdir/router.log}
}

component $exec_prefix/resolver {
     type process
     reads { $pkgetcdir/resolver.xml}
     writes { $piddir/resolver.pid,
              $logdir/resolver.log}
}

component $exec_prefix/sm {
     type process
     reads { $pkgetcdir/sm.xml}
     writes { $piddir/sm.pid,
              $logdir/sm.log}
}

These components may read or write to files or make socket connections. Note that in the example, $prefix is used indicating that the location in the file structure will be set at configuration time and hence not known to developers. As a first step in the analysis, you should define prefix for your installation. polgen then resolves unknown directories from the declarations at the beginning of the file.

Files with the .psl extension contain an architecture description of the application. These descriptions segment the application into a hierarchy of components. Components can be code modules that follow the organizational structure of the application code or, importantly for polgen analysis, they can be processes that realize information flow through the code modules that they use. Thus, PSL provides a static program description that can complement the results of dynamic analysis. Description of PSL constructs that go beyond those needed for bootstrapping are contained in a separate reference manual. This manual is still under review, but will be provided in subsequent releases.

4.2 Trackall

We need to perform an analysis of the programs' behavior. We use the stracesc program to tell us all of the system calls the program makes during its run. Remember that stracesc only tracks the program's behavior during a particular run, rather than its potential behavior. for complex programs you will need to run through a range of typical activities while tracing the program. For example, when tracing a web browser you would want to not only visit a few websites, but also make sure to change the browser's configuration and use standard plugins. Formally, stracesc performs dynamic, not static, analysis, so you need to execute all code paths.

The dynamic analysis must be captured on an SELinux machine. All examples run so far have been on a system in permissive mode; no special policy has been written to allow stracesc to function properly in enforcing mode (though this is considered for future releases of polgen).

$ stracesc -fX -o program program
$ trackall -o tracked_data_dir program

These commands will produce trace files containing system call information useful for pattern recognition. When trackall is called with the -o option, the script will place output files in output_directory. The naming convention for these files is program.tracked. It can be moved to the system or location where you will generate policy.

4.3 How trackall Works

The trackall program converts stracesc output into a format that is easy to analyze, and then invokes the trackfd program. The trackfd program performs the data reduction for the spar program. This script can also be useful outside of the policy generation context, to make sense of trace files and offer insight into a program's behavior.

An essential part of the data reduction is the summarization of the life cycle of a file descriptor. For each file descriptor created by a program, the trackfd program creates a data structure. The data structure is updated whenever a system call is found that applies to the file descriptor. Finally, when a file descriptor is closed, a summary of the activity associated with the file descriptor is written to the output.

5. Recognizing Patterns

5.1 Spar

The program spar, the Security-enhanced linux PAttern Recognizer, searches .tracked and/or .psl files for particular behavior patterns and presents them to the user through a menu-like interface and a collection of web pages.

5.2 Running spar

We have designed polgen tools to help SELinux administrators generate modular, predictable policy for individual programs. Our approach is based upon the identification of interaction patterns in program behavior, eventually at multiple abstraction levels. As patterns are recognized in program behavior (and perhaps modified by the user), policy targeted to those specific interactions can be generated. This approach will produce policy that is specifically tied to an individual program, and can support least-privilege in a predictable and repeatable way.

Currently, our tools look for low-level process interaction patterns in the behavior of the target program (such as the use of temporary files). For each of these individual patterns, our tools suggest policy descriptions to the end user, who can interactively determine the policy descriptions before generating actual policy files.

The spar program provides you with the freedom to locate your tracking results (spar input), and results (spar output) in directories of your choosing. In what follows, we refer to these two directories as track_data_dir, and results_data_dir, respectively.

If you ran trackall with the -o option, track_data_dir will be the output directory you specified in the previous step.

The spar program is run from a Unix shell. The command line arguments for running spar are as follows.

• -h: Help
• -n: Specify name for program--default is the name of the directory where tracked data is located
• -d: Specify tracked data directory--default is directory in which spar is run
• -o: Specify output directory--default is to create a subdirectory named results inside the directory where spar is run.

As illustration, the following command is used to analyze data from the track_data_dir directory. The output is placed in the results_data_dir directory and the analyzed program name is myprog.

$ spar -n myprog -d track_data_dir -o results_data_dir

When you run spar, you will see running commentary as spar reads tracked files generated from stracesc, identifies pattern use, and writes out results in XML and HTML formats. When the initial analysis is completed, spar prompts the user for refinements prior to generating .te, .fc, and .if files.

Using a web browser, you may examine the patterns and policy suggested in home.html which is found in results_data_dir.

5.3 User Interaction

After completing its automated analysis of tracked files, spar provides a policy author with an opportunity to fine tune type settings prior to automated policy generation. Using the menu interface, you can modify the specifications for .te, .fc and .if files. In addition spar allows users to modify type assignment strategies in several ways. Users can declare that spar should minimize the number of new types created or that spar should never change a type of any non-polgen_temp types. If these options are not selected, users will be able to enforce the constraints but on a case-by-case basis. Finally, the user can specify an alternate type to be used to replace all "unconfined_t" occurences.

1. You can accept or reject spar assertions about patterns of interactions. In some cases, Spar creates new types to enforce constraints associated with patterns. In the interface, patterns realizations are marked with a filled-in or open box. Filled-in indicates that polgen will assign policy consistent with the patterns constraints. An open box indicates either that evidence for the pattern is insufficient or that an external element would have to have its type reassigned. You should carefully examine these settings to ensure that the policy matches your expectations.
2. You can also set up and provide your own name for groups of processes. The notion is that you may want to establish new types for all files read or modified by processes in a group. For both steps 1 and 2, you will find help through spar-generated HTML pages. For this support click on the help button and go to the Pattern Instances or Resource pages.
3. You can indicate expectations about the needs for exposing internal types which can be accessed by types from other programs. polgen uses this information to create a .if file for a reference policy.
4. The next step will be for you to confirm spar's type assignments based on your step 1 and 2 input. You will be able to select a group and pattern designation for a type or return to an original type. The default is to apply pattern and group constraints for internally created types and to use an original type for others. If you override one of these original types, spar will ask for confirmation.
5. The final step is to set the directory level for all files with a new type. This information shows up in the .fc file and conforms to the regular expression protocols for .fc files.

The eventual use-case for this generation software is for large patterns to be recognized and communicated to the user, e.g. "This program is a web server", based on a particular collection of modular sub-patterns found in the program's behavior (e.g., "This program is a network daemon listening on port 80 that uses configuration files, log files, and interacts with user files while running."). Currently, spar recognizes some higher-level security patterns and some modular pattern "building blocks". The complete list of patterns is listed in the next section.

5.4 Patterns Recognized by spar

Currently, spar recognizes some higher-level security patterns and some modular pattern "building blocks". The complete list of patterns recognized in program behavior follows. In some cases, there are multiple recognizer modules for each pattern. Future versions of these tools will recognize more patterns, and may also include more sophisticated recognizers for existing patterns.

• TempUse: This pattern captures interactions in a program indicative of the use of temporary files. To protect the program from malicious external interactions, it is best to give these temporary files a protected type to which only the program itself has permissions. We currently flag an interaction as temporary file usage if there are write() system calls in the /tmp directory.
• SharedLibrary: This pattern attempts to recognize the use of shared libraries. To ensure that programs cannot over-write or modify these libraries, we suggest policy that grants the program permission to simply open the file for reading. We flag an interaction as shared library usage if the program attempts an open() system call on a file containing the string .so somewhere in the file name.
• Logger: This pattern recognizes the creation and use of log files in the behavior of a program. It should never be the case that a program can overwrite existing log files, so we suggest policy granting the program to create new log files if necessary, and modify those files via the append operation. We flag an interaction as log file usage if files are accessed in a directory containing the string var/log.
• Config: This pattern recognizes the use of configuration files. Like temporary files, configuration files should be tightly protected. We suggest policy that gives configuration files a new type related to the type of the program. The user then must specify those parties responsible for maintenance of the configuration files. We flag an interaction as configuration file usage if files are accessed in a directory containing the string etc or if files are accessed beginning with a . (anywhere in the file system).
• LibSelinuxInit: This pattern attempts to recognize libselinux initialization, which happens often as many programs are now linked against libselinux. There are two levels of policy suggestion for this pattern, one of which is currently implemented. If the program is linked against libselinux and later invokes a call that needs access to selinuxfs or an /etc/selinux/$SELINUXTYPE policy file, we suggest rules allowing the program to make the access. We recognize this linking if a program shows attempts to read from /proc/mounts or /etc/selinux/config, with subsequent accesses to nodes in selinuxfs or /etc/selinux. In future versions, if the program never actually invokes a call needing such access, we will suggest policy incorporating a dontaudit statement.
• SingleProcessMediator: This subset of the Mediator pattern (see below) captures the case where one wants a single process to maintain the contents of a collection of resources, as in the case of a database management process. We mark an interaction as a single process mediator pattern when a single process is reading from and writing to a collection of files. In this case, we suggest policy granting the process access to the types of the files it manages.
• Pipeline: This pattern recognizes multiple processes acting in concert to provide an information flow pipeline. Our suggested policy for a pipeline creates new types for information in the pipeline, which should be kept segregated from the rest of the system. We recognize a pipeline by looking for chains of contexts where information is passed from context to context, and not modified by processes external to the chain.
• Pipe: This pattern recognizes processes that communicate via pipes, by examining system calls. No particular policy for pipes is currently recommended.
• Mediator: This multi-process interaction pattern signifies the case where a mediator process handles all communications among a set of processes. In this case, policy should ensure that the set of processes cannot pass information to one another directly, but instead must pass information to (and receive it from) the mediator process.
• Proxy: This multi-process interaction pattern attempts to recognize the proxy interaction, where clients make requests to services through an intermediary (the proxy). Policy for this pattern should forbid direct communication between the client and the service, and allow communication through the proxy.
• CanCheckSELinux: This pattern occurs when an application reads from /proc/filesystems and /proc/self/attr/current. The policy recommended is to allow the application type to read from the appropriate types for these files.
• CGI: This pattern is a building block for the kind of activity seen in a web server application. The recognizer finds situations where a server execs both a shell and script process, the shell and script are connected by information flow, and the shell generates data that is read by the server. CGI activity may require additional information flow over and above that seen in the web server. To enable the user to only provide access at the CGI level, we call out this additional CGI activity as part of our web-based policy author support.
• ClientServer: This pattern is found by identifying a client-side socket connect that is subsequently accepted by a server.
• Client: This pattern captures the situation where a client establishes a connection to a process that is not being traced. In both the ClientServer and Client cases we allow the application type to make the necessary socket connections.
• Interpreter: This pattern occurs when an application reads both a program file (written in say Python or Perl) and also reads the interpreter for the program.

spar also recognizes near-matches for patterns, and allows the user to confirm, deny, and/or modify policy for those near-patterns.

6. Post-Processing

Human intervention in the spar output files is almost certain to be needed to precisely create the final policy. However, spar helps focus the human interaction by highlighting decision points and likely conflicts. It presents both complete sets of patterns to the user, and also identifies incomplete patterns, and incomplete groups of patterns (e.g., a program might be classified as a web server if only it used configuration files). There are three types of reports in spar's output directory.

• XML files can be used for passing to other tools. For example, the XML files contain node/edge descriptions that you can use as input for a visualization tool such as Royere.
• HTML files are produced for human understanding. In a hyperlinked way, they describe spar's findings and allow for easier editing for the third type of file, a python script. They offer information grouped in several different files:
  • Data files containing .psl files, .tracked files, and a difference report if both types of data are available.
  • On the "Pattern Instances" page, all pattern instances found by spar are listed. At the top of the page, a list of all patterns for which spar is looking is shown, with actual found instances hyperlinked. The rest of the page goes through the recognized patterns by type. For each one, a picture and all context/file descriptor information is shown.
  • On the "Context to Check" page, spar lists all policy changes that may require action to be taken by the user. If the tracked files didn't provide a security context, for example, this will be highlighted on this page. New type assignments and resources for which there are multiple type generation constraints (for example, if a program tries to write to an already-existing file) are also shown here.
  • "Sub-process Extensions" describes situations such as CGI patterns where a sub-process extends the reach of its parent process. The policy author may wish to note such extensions in the process of providing mimimal priviledges.
  • "External Resources" shows places where spar has considered and changed (or not changed) the context for a non-polgen_temp resource.
  • "Execution Transitions" shows places where a potential "can_exec" macro call has been rejected.
  • On the "Resources" page, all resources found by spar are listed, along with their security contexts.
  • On the "Security Context" page, spar presents the user with all processes and resources found, grouped according to security context.
  • "Policy" contains html versions of policy files. These are created for a standard policy and also for a reference policy.

7. Batch-Processing Script

The enclosed script runs the two programs that analyze stracesc output. Before use, it should be adjusted to fit your needs.

#! /bin/sh
# Run polgen post stracesc programs.
# Change the following settings to your tastes.

# Set this to polgen's bin directory if it is not on your path.
bindir=

# Derive the name of the system being analyzed
# from the current directory name.
name=$(basename $(pwd))

# Directory containing the stracesc output.
traces=traces

# Directory for file descriptor tracking output.
tracked=tracked

# Directory for spar output.
results=results

if [ ! -d "${tracked}" ]
then
  mkdir "${tracked}"
fi

"${bindir}trackall" -o "${tracked}" "${traces}"/*

if [ ! -d "${results}" ]
then
  mkdir "${results}"
fi

"${bindir}spar" -g -n "${name}" -d "${tracked}" -o "${results}"

8. Advanced Techniques

Most users will use spar in "batch" mode as described in these instructions thus far. However, if you are interested in examining spar capabilities in more detail, doing interactive explorations of a program's structure, or actually extending spar itself, this section provides information on the recognition process.

class RecogPipeline (SpecObj):
    pattern = Pipeline
    detection = "correct"

Recognizers are written in a semi-declarative fashion. What appears above is a Python class which defines a recognizer for Pipeline. The class has several attributes including "pattern" (i.e., the name of the pattern that is recognized), "collections" (descriptions of how to locate the constituent parts of the pattern), and "focus_name" (the name of the resource at the top of the chain). spar will compile this semi-declarative description into procedural Python code and place it in the current directory. This procedural code walks through all the resources identifying each one as the focus_name participant and then follows information and execution flow to other resources looking for matches to the constraints embedded in the collections. For example, consider the following complete description of a Pipeline recognizer.

class RecogPipeline(SpecObj):
    pattern = Pipeline
    detection = Correct
    collections =
       [Recog("r1 in [f for f in obj.out_to('write')\
          if not config_namep(f.name)\
          and singleton(f.in_edges)]",
             [Recog("middle in \
                  [m for m in r1.out_to('read') if m  != obj \
                   and m not in obj.receiving_from]", \
                    [Recog("r2 in \
                       [f for f in middle.out_to('write')
                        if not config_namep(f.name) \
                        and f != r1 and singleton(f.in_edges)]", \
                          [Recog("end = \
                            [e for e in r2.out_to('read') if \
                               e not in [obj, middle] +\
                               obj.receiving_from +\
                               middle.receiving_from]")])])])]
    focus_name = "begin"

In the example, an expression such as "r1_in [f for f in obj.out_to('write')]" indicates that the r1 participant in a pattern instance satisfies a constrain on its relationship to a process named "obj"--a local variable bound to the begin resource at top level. The format for Recog arguments is as follows. The first argument is a string of the form "participant-name = arbitrary Python code returning a list". The second optional argument is a list of additional recognition descriptions using the obj and any above participant names as local variables.

Running the procedural code stores solution trees in internal memory. A global class in the util module called PRGM holds all of the instances extracted. Each instance is a tree with root set to the "focus_name" participant and subtrees generated for collections of other participants. This information is stored as a dictionary with keys set to the names of the recognizers. Hence Util.PRGM.pattern_instances['RecogPipeline'] will return a collection of trees.

Items on these trees can then be explored in an interactive session using the Python interpreter.

9. Complete Example

This section describes an example of how to use our policy generation software. We have included instructions for the reader to run this example. Output from each step has been included. Each output file has the same name as the corresponding part of the example.

9.1 The E-Commerce Suite

For our example, we use a set of simple scripts designed to imitate an e-commerce software suite. There are three scripts, each representing a program we would want to design policy for: a server which receives orders over the network, an accounts receivable program which confirms that the order was legitimately paid for, and a shipping program which takes paid orders to be shipped. The server is esales.py. Accounts receivable is acct_rcv.py. Shipping is shipping.py. In addition, we have a client script which places an order. The client is salesclient.py.

We will walk through the pattern analysis process using these simple programs.

9.2 E-Commerce Suite installation:

Requirements: Python 2.2.3 or higher. These instructions assume you will be performing the installation on an SELinux machine. As described above, you may perform analysis of the traces on another machine if you wish.

The ECommerce suite requires a directory which it can freely change. (The /usr/local/ecomm directory is a reasonable alternative.) The ecomm-config script, which we added to your path, will copy all of the ECommerce files into ecomm-directory and configure them for your machine. NOTE: Do not perform these options in your home directory, or the file relabeling will not happen appropriately.

# cd /usr/local
# mkdir ecomm
# cd ecomm
# chown user:group .
$ ecomm-config

The first step is to generate a temporary minimal policy. To facilitate this for the example, the ecomm-config script creates a .psl file and copies the programs. For other applications, you can place the program and the .psl file in separate locations. Following is a copy of the .psl file we will use. Note that prefix has been set to the location of the program.

prefix=/usr/local/ecomm
exec_prefix=$prefix/bin
datadir = $prefix/share
pkgdatadir=$datadir/ecomm

component $exec_prefix/esales.py {
     type process
     entry_point 1
     writes {$pkgdatadir/orders(/.*)?}
}

component $exec_prefix/acct_rcv.py {
     type process
     entry_point 1
     reads {$pkgdatadir/orders(/.*)?}
     writes {$pkgdatadir/paid(/.*)?}
}

component $exec_prefix/shipping.py {
     type process
     entry_point 1
     reads {$pkgdatadir/paid(/.*)?}
}

The next step is to run spar. The -g option runs spar in batch mode, in other words, without the GUI.

$ spar -g -n ecommerce

Now, we can check to make sure that the generation was successful.

$ cd results
$ cat temp_ecommerce.fc
/usr/local/ecomm/paid(/.*)?                gen_context(system_u:object_r:ecommerce_pipeline_t, s0)
/usr/local/ecomm/orders(/.*)?              gen_context(system_u:object_r:ecommerce_pipeline_t, s0)
/usr/local/ecomm/bin/shipping.py           gen_context(system_u:object_r:polgen_temp_shipping_exec_t, s0)
/usr/local/ecomm/bin/acct_rcv.py           gen_context(system_u:object_r:polgen_temp_acct_rcv_exec_t, s0)
/usr/local/ecomm/bin/esales.py             gen_context(system_u:object_r:polgen_temp_esales_exec_t, s0)

Now we incorporate this temporary version of ecommerce in the running policy.

$ make -f /usr/share/selinux/devel/Makefile
# /usr/sbin/semodule -i temp_ecommerce.pp
# /sbin/restorecon -v -r ..

9.3 Dynamic Analysis of ECommerce

For the example, we will run stracesc on each important segment of the ECommerce suite: the e-sales server, accounts receivable, and shipping. We ignore the client, because we expect it to normally run on a different machine than the servers and are not trying to create the client machine policy.

$ cd /usr/local/ecomm/share/ecomm
$ stracesc -fX -o esales.py ../../bin/esales.py &
Running the client will give us a sample order.
$ ../../bin/salesclient.py
$ fg; C-c   This will kill the esales process. Normally, a server would run
indefinitely, but we don't need the server any longer, now that we have an order.
$ stracesc -fX -o acct_rcv.py ../../bin/acct_rcv.py
$ stracesc -fX -o shipping.py ../../bin/shipping.py
$ trackall -o /usr/local/ecomm *.py

Note that in this example, we will use the existing /usr/local/ecomm directory for spar input. To check your results, this directory should now contain the following files: esales.py.tracked, acct_rcv.py.tracked, shipping.py.tracked, ecommerce.psl. Next run spar again.

$ cd /usr/local/ecomm
$ spar -n ecommerce

9.4 Looking for Patterns

After automation and interaction with the user, /usr/results will contain output files showing any patterns spar has found in the input along with the generated .te, .fc, and .if files. These files describe spar's findings for the user.

The last step is to install the new module into the running policy.

$ cd results
$ make -f /usr/share/selinux/devel/Makefile
# /usr/sbin/semodule -i ecommerce.pp
# /sbin/restorecon -v -r ..

10. Using Polgen on non-Fedora Systems

10.1 Using polgen on Debian GNU/Linux

The current version of polgen should work just fine on a Debian/Sid system. You might get your interface files from the standard package selinux-policy-refpolicy-src instead of Red Hat's selinux-policy-devel.

Index

About This Document

This document was generated by Brian Sniffen on February, 27 2007 using texi2html 1.76.

The buttons in the navigation panels have the following meaning:

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

• 1. Section One
  • 1.1 Subsection One-One
    • ...
  • 1.2 Subsection One-Two
    • 1.2.1 Subsubsection One-Two-One
    • 1.2.2 Subsubsection One-Two-Two
    • 1.2.3 Subsubsection One-Two-Three     <== Current Position
    • 1.2.4 Subsubsection One-Two-Four
  • 1.3 Subsection One-Three
    • ...
  • 1.4 Subsection One-Four

This document was generated by Brian Sniffen on February, 27 2007 using texi2html 1.76.