From SELinux Wiki
Revision as of 14:52, 24 October 2009 by CraigGrube (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Assured pipelines provide the ability to move data between different information domains by carefully specifying a set of processing steps that must occur. Assured pipelines are simple in nature, having only a small number of properties that must be guaranteed to provide correct operation. Assured pipelines must be non-bypassable, tamperproof, and verifiable.

SELinux provides mandatory access control mechanisms that are ideal for building assured pipelines. SELinux type enforcement provides fine-grained access control that can express a wide range of information flow policies. This expressiveness is important in situations where policy involves information domains and relationships that aren’t as simple as those provided by traditional MLS policies.

As opposed to building a single monolithic application that performs all operations necessary to process data, assured pipelines allow smaller standalone applications to be built. Each application performs a single simple operation on the data. The smaller applications are easier to analyze, test, and evaluate for correctness and trustworthiness. It also allows third party applications or COTS applications to be integrated as a pipeline stage without requiring tight integration with other processing.

In a trustworthy system, when information must pass from one application to another for processing, separation of processing is not sufficient to guarantee that the system policy is being enforced. An assured pipeline can use a mandatory access control (MAC) policy to place tight controls on how processing stages may interact with each other and guarantee that processing occurs in the proper order.

Traditional MAC policies such as multi-level security (MLS) can be adapted to provide adequate protection for some types of assured pipelines, but cannot easily adapt to all. A more flexible policy, such as type enforcement can provide fine-grained permissions that express a wider range of information flow pipelines. In cases where assured pipelines are established specifically to allow for data label change and downgrades or to permit export to another system with a lesser privilege (such as a cross domain guard), an MLS policy cannot be used. Since the downgrade operation would be a violation of the MLS policy, the pipeline stages must be privileged to allow data “write-down” operations. When many pipeline stages are privileged, it becomes difficult to make assertions about proper information flow. With a type enforcement policy such as SELinux, types can be used to confine input and output data types for each stage in the pipeline and guarantee that data flows only in the appropriate direction.

Traditionally, limitations in mandatory access control policies and the desire to reduce overall complexity has resulted in assured pipelines that are only serial in nature – all processing is a single set of sequential stages. However, pipelines do not need to be strictly linear. As long as the information flow policy supports it, pipelines can have branches or can loop back to re-process data.

Type enforcement also allows for more appropriate processing of audit and monitoring information. With an MLS system, audit information from pipeline stages would typically need to perform a write-up operation to the highest-level label for all data processed. Since type enforcement is not a hierarchical policy with an implicit flow direction, audit data can flow in a more natural path that does not necessitate a central trusted log component.



Most trustworthy Information systems require a mechanism to import data into the system for further analysis, processing, or dissemination. However, trustworthy systems require that extra care be taken to avoid providing a mechanism to introduce content that could be damaging or disruptive to the system.

While users sometimes may be trusted to import data directly, a more secure system would require data to pass through a set of non-bypassable filters before it may be used. An assured pipeline could be used to guarantee that necessary filters are run in the proper order and that data is not available until it has successfully passed through all necessary processing.

With a type enforcement policy such as SELinux data on removable media such as CDROMs, USB Flash-based tokens, scanners, external hard disks with file systems not containing trustworthy security labels for all files, etc. can be assigned a default label by the policy. The default label will preclude any access to the raw data files except by the first stage of the processing pipeline.

A set of carefully built processing applications can examine the file data to determine if it may be safely added to the system. Only upon exit from the pipeline would the data be labeled so that it may be accessed by other applications. If the data were rejected at any time, the security policy would preclude any access. At an early stage in the pipeline, output could branch depending on the format of the incoming data so format-specific processing or translation can be performed. In a subsequent stage, processing can collect and continue with serialized processing.

Example processing might include:

  • Reject all files that are not ASCII text
  • Convert all MS Word documents to ASCII text, PDF or TIFF
  • Scan with antivirus software
  • Allow user to specify appropriate security label
  • Reject encrypted or archived files (zip, etc.)


The current pipeline performs the following steps:

  • Import files from specified source into pipeline for processing.
  • Scan files for viruses using ClamAV.
  • Convert Word documents to text using catdoc.
  • Convert PDF documents to text using pdftotext.
  • Verify jpg files contain JPEG data using ImageMagick.
  • Export files from pipeline into drop directory.

Following successful installation the pipeline scripts will be available in /usr/local/bin and sample files for processing with the pipeline will be in /media/sample.

Files that successfully make their way through the pipeline will be available in /home/inbox and should all have type pipeline_processed_t.


A sample kickstart is available for building a very basic system with the pipeline scripts and SELinux policy installed. The most convenient way to install the demonstration is to boot a system or VM using Fedora Core 11 installation media and at the kernel boot prompt add the option ks=http://www.selinuxproject.org/~cgrube/pipeline/kickstart/ks.pipeline.cfg.

Binary RPM packages are available here. And source RPM packages and tarballs are available here.

Using the pipeline

The main script controlling the pipeline, pipeline-import.sh, takes two command line arguments:

  • -p - will display the SELinux context of each stage of the pipeline as they execute.
  • -i {dir} - specifies the directory from which files should be imported.

To import the sample files:

  • use chcon -R system_u:object_r:pipeline_unclean_t:s0 /media/sample to change the labels of the files to the type the pipeline operates on
  • Run pipeline-import.sh -i /media/sample.
  • View the processed files in /home/inbox.