# Copyright (c) 1999, 2000 The University of Utah and the Flux Group.
# All rights reserved.
# 
# Contributed by the Computer Security Research division,
# INFOSEC Research and Technology Office, NSA.
# 
# This file is part of the Flux OSKit.  The OSKit is free software, also known
# as "open source;" you can redistribute it and/or modify it under the terms
# of the GNU General Public License (GPL), version 2, as published by the Free
# Software Foundation (FSF).  To explore alternate licensing terms, contact
# the University of Utah at csl-dist@cs.utah.edu or +1-801-585-3271.
# 
# The OSKit 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 GPL for more details.  You should have
# received a copy of the GPL along with the OSKit; see the file COPYING.  If
# not, write to the FSF, 59 Temple Place #330, Boston, MA 02111-1307, USA.

The policy database is generated by applying GNU m4 to the
concatenation of a set of policy-independent configuration files in
the flask subdirectory and a set of a policy-dependent configuration
files in the security/policydb subdirectory.  The resulting
configuration is written to security/policy.conf.  This file is then
compiled by the checkpolicy program to security/policy, and installed
as /ss_policy.  In addition to being read by the security server, the
configuration files in flask subdirectory are used during the kernel
build to automatically generate symbol definitions used by the object
managers for security classes, initial SIDs and permissions.

It is also possible to test the security server functions on a given
policy configuration by running the checkpolicy program.  This program
is built from the same sources as the security server component of the
kernel, so it may be used both to verify that a policy database will
load successfully and to determine how the security server would
respond if it were using that policy database.  A menu-based interface
is provided for calling any of the security server functions after the
policy is loaded.  The program of the same name that is in the
syscalls directory was derived from this program.  That program
provides a means of actually invoking the interfaces of a running
security server component in a kernel.

The policy-independent configuration files in the flask subdirectory
are:
1) security_classes -
   This file has a simple declaration for each security class.
   The corresponding symbol definitions are in the automatically
   generated header file include/linux/flask/flask.h. 

2) initial_sids - 
   This file has a simple declaration for each initial SID.
   The corresponding symbol definitions are in the automatically
   generated header file include/linux/flask/flask.h. 

3) access_vectors - 
   This file defines the access vectors.  Common prefixes for
   access vectors may be defined at the beginning of the file.
   After the common prefixes are defined, an access vector
   may be defined for each security class.
   The corresponding symbol definitions are in the automatically
   generated header file include/linux/flask/av_permissions.h.

Since the symbol definitions generated from these files are used
during the kernel build, the values of existing security classes and
permissions may not be modified during load_policy.  However, new
classes may be appended to the list of classes and new permissions may
be appended to the list of permissions associated with each access
vector definition.

The policy-dependent configuration files in the security/policydb
subdirectory are:
1) mls - 
   This file defines the MLS levels and maps each access vector
   permission to a set of MLS base permissions.  The levels
   are defined by declaring the sensitivities, defining an
   ordering on the sensitivities, declaring the categories
   and defining which categories may be associated with
   each sensitivity.

2) te - 
   This file defines the type enforcement domains/types, the
   default type labeling rules and the type enforcement tables.

3) rbac - 
   This file defines the roles, the domains/types that may be
   associated with each role and the role dominance relationship.
   The relationship between roles and domains/types is enforced
   by only issuing SIDs for security contexts that have a valid
   (role, domain/type) pair.  When a policy change causes
   the security context for an existing SID to become invalid,
   the SID is invalidated.

4) constraints - 
   This file defines additional constraints on permissions
   in the form of boolean expressions that must be satisfied in order
   for specified permissions to be granted.  These constraints would
   typically be used to limit permissions based on user identity or
   to limit permissions based on the role dominance relationship.

5) users -
   This file defines the set of roles and MLS ranges that may be
   associated with each user.  The relationship between users and
   roles and the relationship between users and MLS ranges is
   enforced by only issuing SIDs for security contexts that have
   a valid (user, role, MLS range) triple.  When a policy change causes
   the security context for an existing SID to become invalid,
   the SID is invalidated.

6) initial_sid_contexts -
   This file defines the security context for each initial SID.
   A security context consists of a user identity, a role, a type and
   a MLS range.  If left unspecified, the high MLS level defaults to the
   low MLS level.  The syntax of a valid security context is:

     user:role:type:sensitivity[:category,...][-sensitivity[:category,...]]

