Operating System Security

1. Operating System Security Susan Hinrichs CyberSecurity Spring 2005

2. Review of Concepts • Explore how these concepts are implemented in Windows XP and SE Linux • Least Privilege • Trusted Code Base • Access Control • Audit Trail • Pfleeger chapter 4 and first part of chapter 5 CyberSecurity Spring 2005

3. Windows NT Security Architecture • Suggested reading • Inside Windows NT, Helen Custer • Windows NT Security in Theory and Practice • MSDN http://msdn.microsoft.com • Addressing the base Windows security mechanisms, not .NET or Longhorn things CyberSecurity Spring 2005

4. NT Security Model • Ultimately NT security controls access and auditing • Implements the standard subject/object security model • Designed into NT. Implemented a security constrained “micro” kernel. • Not always used very well • Unexpected use of extensible elements like word macros or extensible DLL’s • Unprotected file systems • Attempts at backwards compatibility with older version of Windows caused some security problems (netbios and FAT) • Controls applied to core OS elements like processes and sockets in addition to the more tradition file system elements (NTFS) CyberSecurity Spring 2005

5. NT Security Elements • Subject – Process or thread running on behalf of the system or an authenticated user • Security ID (SID) – A globally unique ID that refers to the subject (user or group) • Access token – the runtime credentials of the subject • Privilege – ability held by the subject to perform “system” operations. Usually breaks the standard security model • Associated with the access token • Generally disabled by default. • Can be enabled and disabled to run at least privilege • Example powerful privileges • SeAssignPrimaryTokenPrivilege – Replace process token • SeBackupPrivilege – Ignore file system restrictions to backup and restore • SeIncreaseQuotaPrivilege - Add to the memory quota for a process • SeTcbPrivilege – Run as part of the OS CyberSecurity Spring 2005

6. Wordprocess Example subject Amer/shinrich DomainController Authentication Exchange DB of usersSID and privs AccessToken sid=123456 Privileges=SeBackup/disabled SeTcb/disabled CyberSecurity Spring 2005

7. Running at reduced privilege • Two system calls disable or remove privileges from the current access token • AdjustTokenPrivileges – enables/disables privileges • CreateRestrictedToken – permanently restrict or remove privileges CyberSecurity Spring 2005

8. More security elements • Object – Individually secured entity such as a file, pipe, or even a process • Rights – actions associated between object and subject. • Read, write, execute, audit • Access control list (ACL) • Associated with an object • Ordered list • Each access control entry (ACE) contains a subject and a right • Evaluated by the security subsystem to determine access to protected objects. • Discretionary ACLs control access • System ACLs control audit CyberSecurity Spring 2005

9. Still more security elements • Security Descriptor – represents an object in the system. Contains the following information: • Object’s owner • Object’s group • Object’s DACL • Object’s SACL • AccessCheck evaluates an ACL, subject, object triple • Called by many system calls • Can be called from user code too CyberSecurity Spring 2005

10. Example ACL \mydocs\hw1.doc Security Descriptor:sid=123456gid=78910DACL= SACL=null SID=Everyone:read SID=123456:read,write SID=22222:deny SID=Everyone:read SID=123456:read,write CyberSecurity Spring 2005

11. Working with ACLs • Accessed via FileExplorer. Right-click file/directory an select sharing and security. • Can programmatically create and traverse ACL’s • See MSDN for details CyberSecurity Spring 2005

12. NT Impersonation • Server program can run with client access token • ImpersonateLoggedOnUser - runs under the access token of the logged on user • Several variations of this system call which pull the impersonation token from various sources • RevertToSelf to return to the original user • SeImpersonatePrivilege has been introduced • Presumably client has lower privilege than server • Multiple impersonation levels to restrict token propagation CyberSecurity Spring 2005

13. ServerProgram1 ServerProgram2 ClientProgram Example impersonation AccessToken sid=11111 AccessToken sid=123456 Calculate my account balance Buy alaptop Client canconstrain impersonationpropagation AccountDB CyberSecurity Spring 2005

14. Other Windows Security Services • GINA - Ability to develop new login authentication mechanisms • LSA – Local service authority • CryptoAPI – Library for generically accessing cryptographic methods. Different CryptoAPI Service Providers can be plugged in CyberSecurity Spring 2005

15. Basic Unix Security Model • Multics addressed security very rigorously • The Multics security review report • Thirty Years Later: Lessons from the Multics Security Evaluation • Unix evolved from Multics in part as a more pragmatic OS • Security was one of the pragmatic causalities • But still has a security model that is frequently ignored/avoided • See Unix and Security: The Influences of History, Spafford. • User oriented security model • Implements a basic subject/object access matrix • File system elements have limited ACL • RWX for owning user, owning group, and other CyberSecurity Spring 2005

16. Unix Security Issues • Improper configuration • Relying on users to accurately set access control • Users have open expectations • Problems with password files • Salt – Extra piece of data combined with password before performing the one-way hash • Originally /etc/passwd stored encrypted password and salt information • With this file you can do an off-line password cracking attack. • Shadow password file moves this sensitive inform • Problems with Set UID and Set GUID • Hard to follow least privilege principle • Really only two levels of user • Root • Everyone else CyberSecurity Spring 2005

17. SE Linux Security Architecture • A bolt-on to the basic Unix security model • Implements a security server to interpret security policy • Leaves basic Unix security mechanisms alone. But replace key programs to require security server approval as well • E.g. the SE Linux identity and the Linux user are two separate things. • SE Linux labeling and Unix DAC are both applied • Suggested reading • Configuring the SELinux Policy by Stephen Smalley • Ignore the how to portions of this paper • Getting Started with SE Linux by Faye Coker • Writing SE Linux Policy HOWTO by Faye Coker CyberSecurity Spring 2005

18. Key SELinux Concepts • Users – Identifier for a single user or an equivalence class of users • Class – Type of an object, e.g., file or process • Roles – Specification of privileges or actions that can be taken by user fulfilling a role • Domains – Classification of a subject • Types – Classification of an object (really the same thing as a domain but applied to objects) CyberSecurity Spring 2005

19. More SELinux Concepts • Two basic security enforcement decisions • Access control: Can subject access object? • Labeling: What label should a new object have? • Very general policy language enables the specification of many models. Ships with two specifications • Targeted. Only applies SELinux policy to a few service • Strict. Applies SELinux policy to every thing • Entities are labeled with triples • User, Role, Type or Domain • E.g., Bob:user_r:corporate_t • When displayed from the “id” command means • Logged on as user Bob fulfilling the user_r role in the corporate_t domain • When displayed off file foo from “ls –Z foo” means • Created by user Bob while in user_r role. Member of corporate_t type CyberSecurity Spring 2005

20. Policy Language Overview • Type declaration • typetype-name [ aliasalias-id ] [, attr-id] ; • E.g., type sshd_t, domain, privuser, privrole; • Binds a type name to some attributes CyberSecurity Spring 2005

21. Type Transition • Defines the rules for the type of a new object • type_transitionsource_typestarget_types:classesnew_type; • Source_type is the type/domain of the creating subject. • Target_type is the type of the parent object, e.g. directory in the file system case • E.g., type_transition sshd_t tmp_t : devfile_class_set cardmsg_dev_t ; • When sshd daemon creates a device file in the tmp directory, the new file is labeled with cardmsg_dev_t • devfile_class_set is a M4 macro CyberSecurity Spring 2005

22. Access Vector Rules • Rules that determine which domains can access which types • (allow | auditallow | dontaudit) src_typetarget_type:classespermissions; • When a subject of src_type accesses an object of target_type, it has the specified permissions if object is one of the specified classes • E.g., allow sshd_t shell_exec_t : file execute; CyberSecurity Spring 2005

23. Role Based Access Control • Provide indirection between a user and the privileges of a user • A user can fulfill multiple roles • Multiple users can fulfill the same role • User groups can act as a weak substitution for Roles • User may be capable of multiple roles but will only operate with one active role • Reduce privilege exposure CyberSecurity Spring 2005

24. Role Syntax • Role Definition • rolenametypetype_set; • Defines which domains (types) a role can be assumed in • E.g., role staff_r type staff_t; • Role Allow • allowcurrent_rolenew_role; • E.g., allow staff_t sysadm_t ; • If not specified cannot take one new role from current role CyberSecurity Spring 2005

25. SELinux Summary • Policies can be quite complex • Strict policies can mess up “normal” Unix daemons • But once the complex policy has been created and proven, the normal user cannot evade it • More execution details for SELinux in upcoming lab. CyberSecurity Spring 2005