# 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,...]]