MLS/MCS on SE Linux Russell Coker

What is SE Linux? A system for Mandatory Access Control (MAC) based on the Linux Security Modules (LSM) framework Uses features of role-based and domain-type access control Removes the power of UID 0, I have run several machines with root as the guest account Offers restrictive controls only – can not grant any access that is denied by Unix permissions

What is wrong with Unix security? Programs have full control over the access given to files they create (DAC) Therefore no protection against malicious software, “social engineering”, and bugs in privileged software which may result in the software granting inappropriate access to files (EG creating a mode 777 file in /tmp) Too coarse grained - root vs non-root gives boolean security model for many cases Security model does not allow tracking of identity across change of UID Does not separate integrity and secrecy controls

Domain Type access control Every process has a domain, every object (file, directory, socket, etc) has a type. The domains are a sub-set of the types (IE types that can apply to processes). A domain is the type for a process, SE Linux does not strongly distinguish between domains and types. The domain of a process will be used as a target context for operations such as sending signals Each object that a process may act on has a type Policy rules determine what access every domain has to each type

Role Based Access Control Each role has a list of domains that may exist in it At login time the security context is changed (identity, role, and domain), also the newrole program may be used to change roles (comparable to an su operation) A role doesn’t often change, unlike the domain which may change often automatically without the user noticing The role determines which domains are permitted Roles may also be changed through role_transition rules in some situations, this is currently only used for the administrator to launch daemons

Identities The Identity is usually the Unix account name and is compiled into the policy database Identity controls the available roles which controls the available domains – but this level of control is not used in the Targetted policy

Policy Written at a high level with M4 macros In future it will be written in XML Compiled into a binary form that is understood by the kernel Loaded by /sbin/init at the start of the boot process before any other programs are executed A modified policy can be loaded at any time by the administrator

Multi Level Security SE Linux also includes support for Multi-Level Security (MLS) Implemented in a flexible manner which is under the control of policy Expected that the DT model protects the system integrity while MLS protects data secrecy MLS support includes levels (equivalent to Top Secret, Secret, Classified, and Unclassified), there may be an arbitrary number of levels which are numbered Also includes categories which may be used for departments, projects, etc. Categories are also numbered and there may be an arbitrary number of them. Support for preventing “read-up” and “write-down”

MLS data flows Squares are files, ellipses are processes

LSPP Certification Working with IBM and HP to get Common Criteria LSPP (Labeled Security Protection Profile) and RBAC (Role Based Access Control) certification for RHEL 5 at EAL 4+ level of assurance Roughly comparable to B1 in the old “Rainbow Book” Trusted Computer Systems evaluation Certification applies to hardware platform. Some customers will use RHEL on other hardware trusting that it is equivalent, but the certifications will strictly only be applied to HP and IBM hardware. Requires MLS support in the print server (labeled print jobs and controls to prevent an insecure printer from receiving classified data) Requires significantly greater auditing support (some of which is being put into RHEL4)

Auditing RHEL4U2 includes auditd, the daemon for storing audit data. In RHEL4 the kernel can be instructed to audit file/directory access based on the PID of the process, the name of the file/directory, and some other criteria. For RHEL5 we will have auditing functionality in every security critical application (for LSPP). A system process that runs a program on behalf of a user (mail server delivering or login program) will set the loginuid so that all actions can be audited to the user responsible. SE Linux audit messages go to the auditd in RHEL4 (if it is installed) and in RHEL5

Multi Category Security (MCS) Policy developed by James Morris of Red Hat using a sub-set of the MLS features MLS is too complex for most users and administrators. Most systems do not have the secrecy requirements to justify the work. Only has a single level so levels play no part in determining access Categories used to determine access, login programs will assign an appropriate set of categories to the user Only applies to file access at this time For each file the MCS policy will permit full read/write access to every process that has a set of capabilities that is a super-set of it’s capabilities. This allows information leaks, but is required by the expectations of most Unix administrators and users. MCS does not implement the Bell la Padula model (MLS), it is not a sub-set of the MLS functionality, it is a different policy that uses the same kernel and policy features that MLS uses

Q/A NSA SE Linux site SE Linux web pages Russell Coker