Security Enhanced Linux

Transcription

1 Security Enhanced Linux Bengt Nolin October 13, 2004 Abstract A very brief introduction to SELinux; what it is, what is does and a little about how it does it. 1

2 1 Background 1.1 What Security-Enhanched Linux (SELinux) is an implementation of Flask for the Linux kernel. Flask is a Mandatory Access Control (MAC) architecture developed by the U.S National Security Agency and the Secure Computing Corporation (SCC). SELinux is included in the mainline Linux kernel since the 2.6 tree. It is now supported by Debian, Fedora, Gentoo, Redhat, Slackware, SuSE and others. 1.2 Why The traditional UNIX user separation between superuser (root) and ordinary users are far too simple when constructing a secure OS. The classical Discretionary Access Control (DAC) just takes user identity and resource ownership in consideration when determining access. Many services require more privileges than an ordinary user but far less than what root offers. The end result being that an exploited program may compromise the whole system. Using SELinux, programs can be allowed just the access they need for operating thus minimizing or completely eliminating a malicious or flawed program from infecting other parts of the system. Even untrustworthy applications can be run without the possibility of breaking the system. 1.3 How In a MAC system objects (files, sockets etc) and subjects (processes) are given a label. Access from a subject or object to another subject or object must be allowed by the policy defined on their labels. This is enforced by the Security Server which is a new kernel component that contains the policy decision logic. There are two basic policy-independent data types: security contexts and security identifiers (SID). Security identifiers are bound to all objects that need a label and then mapped to some security context at run time. The mapping is handled by the Security server which then looks at the appropiate security context for making the decision. Since the Security server only handles SID:s it doesn t have to know the details of the policy it enforces. This allows for switching of the Security Server depending on what policy is to be used in the system. In fact, the security server implemented depends on which policy the system is going to use. SELinux comes with a pretty capable Security Server and an example policy created at NSAI Labs, that meets many common general security objectives. 2

3 2 The example Security Server The default Security Server is a mix of Role-Based Access Control (RBAC) and Type Enforcement (TE). A security context is defined by a combination of identity, role and type. 2.1 Type Enforcement Each process are assigned a domain and each object a type. The model restricts access to types for the domains, allowing a process to only access a certain set of objects, be it a file, directory or a socket. A domain is also considered a type, so domain to domain access is also restricted. Types are divided into classes so that access to a raw socket differs from access to a TCP socket. 2.2 Role-Based Access Control Users (subjects) are assigned roles and permissions with that role and each role defines entrance to a domain. Transitions between roles often require user authentication to protect from malicious applications changing roles. Transitions can also be limited to only occur in specified domains. 2.3 Identity-Based Access Control The user identities used in SELinux are not related to the ordinary Linux UID:s. This is because UID:s can be changed with the setuid call to something more suitable for the current task, without the actual user invoking these actions is changed. This implies accountability problems. A different set of user identities also requires less change in the way that the kernel handles UID:s. 3

4 3 Examples About 140 permissions divided into 28 object classes are defined in the SELinux Security Server. These are rather specific and allow for a complex policy. The permissions are checked against the Security Server at specific points throughout the kernel subsystems. A process can be disallowed in using the connect call for sockets but allowed to use the listen call. A service may append to a log file but not read, write or delete it. A mailserver can bind the smtp port, append logs, handle the mail spool and read its configuration files, but no more. A standard user with access to the user t and sysadm t domains may run the su command to become root but is still unable to run the proccesses allowed for the sysadm t domain since his/hers identity are still the same, the role hasn t changed. Efter invoking the newrole command, invocation of the processes are enabled. The performance of SELinux is pretty good considering the many permission checks and it is by all means usable in a real system. No optimizations have been made, but the Security server caches access decisions to speed up consecutive queries. Overall it s a good choice for building a secure system. 4

5 References [1] Peter A. Loscocc and Stephen D. Smalley. Meeting Critical Security Objectives with Security-Enhanced Linux. In Proceedings of the 2001 Ottawa Linux Symposium. [2] Peter A. Loscocc and Stephen D. Smalley. Integrating Flexible Support for Security Policies into the Linux Operating System. In Proceedings of the FREENIX Track of the 2001 USENIX Annual Technical Conference. [3] Stephen D. Smalley. Configuring the SELinux Policy. [4] Gentoo x86 SELinux Handbook. 5