M eeting Critical Security Objectives with Security-Enhanced Linux - PowerPoint PPT Presentation

M eeting Critical Security Objectives with Security-Enhanced Linux Peter A. Loscocco Information Assurance Research G roup National Security Agency Co-author: Stephen D. Smalley, NAI Labs 1 roup ■ Inform ation A ssurance R esearch G ■

Presentation Outline • O perating system security • The Flask architecture • Security-enhanced Linux • Example security server • Meeting critical security objectives • Future Direction 2 roup ■ Inform ation A ssurance R esearch G ■

The Need for Secure OS • Increasing risk to valuable information • Dependence on O S protection mechanisms • Inadequacy of mainstream operating systems • Key missing feature: Mandatory Access Control (MAC) – Adm inistratively-set security policy – Control over all subjects and objects in system – Decisions based on all security-relevant inform ation 3 roup ■ Inform ation A ssurance R esearch G ■

W hy is DAC inadequate? • Decisions are only based on user identity and ownership • No protection against malicious software • Each user has complete discretion over his objects • O nly two major categories of users: superuser and other • Many system services and privileged programs must run with coarse-grained privileges if not as superuser 4 roup ■ Inform ation A ssurance R esearch G ■

W hat can M AC offer? • Strong separation of security domains • System and data integrity • Ability to limit program privileges • Protection against tamper and bypass • Processing pipelines guarantees • Authorization limits for legitimate users 5 roup ■ Inform ation A ssurance R esearch G ■

M AC Im plem entation Issues • Must overcome limitations of traditional implementations – M ore than just M ultilevel Security – Address integrity, least privilege, separation of duty issues – Com plete control using needed security relevant inform ation – Control relationships between subjects and code • Policy flexibility required – One size does not fit all! – Ability to change the m odel of security – Ability to express different policies within given m odel – Separation of policy from enforcem ent • Maximize security transparency 6 roup ■ Inform ation A ssurance R esearch G ■

Custom ize according to need • Separation policies – Establishing Legal Restrictions on data – Restrictions to classified/com partm ented data • Confinement policies – Restricting web server access to authorized data – M inim izing dam age from viruses and other m alicious code • Integrity policies – Protecting applications from m odification – Preventing unauthorized m odifications of databases • Invocation policies – Guaranteeing that data is processed as required – Enforcing encryption policies 7 roup ■ Inform ation A ssurance R esearch G ■

Security Solutions with Flexible M AC • Confines malicious code – Can safely run code of uncertain pedigree – Constrains code inserted via buffer overflow attacks – Lim its virus propagation • Allows effective decomposition of root – Root no longer all powerful – Lim its each root function to needed privilege – Elim inates m ost privilege elevation attacks • Allows effective assignment of privilege – Servers need not run with com plete access – Servers and needed resources can be isolated – Separate protections for system logs 8 roup ■ Inform ation A ssurance R esearch G ■

Toward a New Form of M AC • Research by NSA with help from SCC • G eneralized from prior Type Enforcement work • Provide flexible support for security policies • Cleanly separate policy from enforcement • Address limitations of traditional MAC • DTMach, DTO S, Flask 9 roup ■ Inform ation A ssurance R esearch G ■

The Flask Security Architecture • Cleanly separates policy from enforcement. • W ell-defined policy interfaces. • Support for policy changes. • Allows users to express policies naturally. • Fine-grained controls over kernel services. • Caching to minimize performance overhead. • Transparent to applications and users. 10 roup ■ Inform ation A ssurance R esearch G ■

The Flask Security Architecture Subject, object, Security Server Object Manager class, requested Access Policy Policy Vector Decisions Enforcement Cache Yes/no Access vector SID/Context Object/SID Mapping Mapping 11 roup ■ Inform ation A ssurance R esearch G ■

Policy Decisions • Labeling Decisions: O btaining a label for a new subject or object. • Access Decisions: Determining whether a service on an object should be granted to a subject. • Polyinstantiation Decisions: Determining where to redirect a process when accessing a polyinstantiated object. 12 roup ■ Inform ation A ssurance R esearch G ■

Policy Changes • Interfaces to AVC for policy changes • Callbacks to O bject Managers for retained permissions • Sequence numbers to address interleaving • Revalidation of permissions on use 13 roup ■ Inform ation A ssurance R esearch G ■

Controlled Services • Permissions are defined on objects and grouped together into object classes • Examples – Process: code execution, transitions, entrypoints, signals, wait, ptrace, capabilities, etc. – File: fd inheritance and transfer, accesses to files, directories, file system s – Socket: accesses to sockets, m essages, network interfaces, hosts – System V IPC: accesses to sem aphores, m essage queues, shared m em ory – Security: accesses to security server services 14 roup ■ Inform ation A ssurance R esearch G ■

Security Server Interface • O bject Labeling – Request SID to label a new object • int security_transition_sid(ssid, tsid, tclass, *out_sid) – Exam ple of usage for new file label • error = security_transition_sid(current->sid, dir->i_sid, FILE, &sid); 15 roup ■ Inform ation A ssurance R esearch G ■

Security Server Interface (cont.) • Access Decisions – Request Access Vector for a given object class/perm ission • int security_com pute_av(ssid, tsid, tclass, requested, *allowed, *decided, *seqno); – Ignores access vectors for auditing and requests of notifications of com pleted operations 16 roup ■ Inform ation A ssurance R esearch G ■

Security Server Interface (cont.) • Access Vector Cache (AVC) – security_com pute_av() called indirectly through AVC • int avc_has_perm _ref(ssid, tsid, tclass, requested, *aeref, *auditdata) – aeref is hint to cache entry. If invalid then security_com pute_av() is called • File permission check shortcuts – int dentry_m ac_perm ission(struct dentry *d, access_vector_t av ) 17 roup ■ Inform ation A ssurance R esearch G ■

Perm ission Checking Exam ples • unlink from fs/namei.c:vfs_unlink() error = dentry_m ac_perm ision(dentry, FILE_UNLINK); if (error) return error; – Additional directory-based checks for search and rem ove_nam e perm issions • Process to socket check from net/ipv4/af_inet:inet_bind() lock_sock(sk); ret = avc_has_perm _ref(current->sid,sk->sid,sk->sclass, SOCKET_BIND &sk->avcr); release_sock(sk); if (ret) return ret; 18 roup ■ Inform ation A ssurance R esearch G ■

Perm ission Checking Exam ples • execve() from fs/exec.c:prepare_binprm () if (!bprm ->sid) { retval = security_transition_sid(current->sid, inode->i_sid, S EC C LA SS _PR O C ES S, & bprm ->sid); if (retval) return retval;} if (current->sid != bprm ->sid & & !bprm ->sh_bang){ retval = A VC _H AS _PE R M _A U D IT(current->sid, bprm ->sid, P R O C E SS , TR A N SITIO N , &ad); if (retval) return retval; retval = process_file_m ac_perm ission(bprm ->sid, bprm ->file, P R O C E SS _EN TR YP O IN T); if (retval) return retval;} retval = process_file_m ac_perm ission(bprm ->sid, bprm ->file, P R O C E SS _EX EC U TE); if (retval) return retval; • Also checks file:execute, fd:inherit, process:ptrace 19 roup ■ Inform ation A ssurance R esearch G ■

API Enhancem ents • Existing Linux API calls unchanged • New API calls for security-aware applications: execve_secure, mkdir_secure, stat_secure, socket_secure, accept_secure, etc. • New API calls for application policy enforcers: security_compute_av, security_transition_sid, etc. 20 roup ■ Inform ation A ssurance R esearch G ■

Exam ple Security Server • Implements combination of Role-Based Access Control, Type Enforcement, optional Multi-Level Security. • Labeling, access, and polyinstantiation decisions defined through set of configuration files. • Example policy configuration provided. 21 roup ■ Inform ation A ssurance R esearch G ■

Exam ple Policy Configuration: TE Concepts • Domains for processes, types for objects. • Specifies allowable accesses by domains to types. • Specifies allowable interactions among domains. • Specifies allowable and automatic domain transitions. • Specifies entrypoint and code execution restrictions for domains. 22 roup ■ Inform ation A ssurance R esearch G ■