Why secure the OS? Works directly on the hardware but can be - PDF document

Why secure the OS? � Works directly on the hardware but can be adapted during runtime Operating System Security � Data and process are directly visible � Application security can be circumvented from lower layers = > good scope because: � Hardware is too narrow and inflexible � Application and Network is too broad The basis of protection: Privilege levels in 80X86 Seperation processors � Physical separation � Procedures can � Processes use different physically devices access objects only � Temporal separation in their own ring or I/O . . . � Process (with different security demands) execute function OS in outer rings at different time � Logical separation � Procedures can � Processes and objects are logical separated so invoke subroutines that they are not aware of each other only in their own � Cryptographic separation ring � Data and computation is concealed by cryptography to the outside Privilege levels - A problem Reference Monitor � Outer ring procedures have a need to � Reference Monitors control access to execute procedures on a lower ring objects � e.g. An application (level 4) want to save a file (level 3) � Solution: A gate (well defined access way) � Physical - Memory Management allow the call (execute only) of lower ring procedures � To prevent abuse (outer ring asks lower ring to transfer an object to the outer ring) both the � Logical - File Management current privilege level and the calling privilege level need to be verified 1

Simple Memory protection Simple memory protection Tagged Architecture Fences � A fence is a predefined address � Each memory segment has a INT 124 which separates the a process tag which indicates INT 12 from another � the memory type which implies OP AND � (e.g. The OS and the User the allowed operation spaces) STR Result � Base and Boundary are � or explicitly the allowed variable type of fences operations R 123 � Base defines a starting address � A tagged architecture can have RW 12 � Boundary defines an upper address limit a high granularity X AND � Different types of base and � Compatibility of code suffers boundary for different spaces can R Result exist Segmentation Paging � Higher granularity then fences because it � Same granularity as segmentation but refers to items (data, code) pages are of fixed size � This implies variable length which makes boundary checks problematic � The fixed page size enables more effective boundary checks � Each address reference can be checked for protection � The associate of protection level to the � Different protection levels can be assigned to object will not work because pages objects cannot be associate to a specific object � Shared objects can have different protection levels for the involved parties File Access User Management � Explicit: The access rights are explicitly � User – a subject with access rights defined � Default User � Unix: Root (UID 0), daemon, bin ... � e.g. ACL or AC-Matrix � Windows: Administrator, Guest, SUPPORT ... � Implicit: The access rights are bound to � Groups – a mean to organize users and add some knowledge and who every posses granularity the knowledge get access � Unix: System(GID 0), terminal ... � e.g. cryptography � Windows: Users, Power Users, Administrator ... 2

Root in UNIX/LINUX Object management � -rwxr-xr-x 1 AZ root � Become root only when absolutely necessary 10 Apr 15 21:21 file � Allow root access only trough su or sudo � s instead of x in owner and � Allow root access remotely only when using group means that the SSH and sudo owners/groups rights and not the users rights are used � Think twice before executing a command as � t for directories means sticky root and use absolute path names and prevents users other than � Do not specify as “ / ” root‘s home directory the owner or root to delete � Restrict the PATH so that it only contains a files in such a directory minimum number of entries � ACL for Linux available under: http://acl.bestbits.at/ Setting of rights during object creation � Linux the first permission is set by the program but then umask complement Windows Security logically added (AND) � Windows solves this by inheritance - Container objects (directories) pass Windows 2000, Windows XP and Windows Server 2003 their ACL rights to child's (files or directories) http://www.microsoft.com/technet/default.mspx � This inheritance can be blocked and explicit rights can be defined � Inherited ACL cannot be edited (grayed) Registry Active Directory � Windows network � The registry contains a lot of security use Active Directory critical information to manage � Operating system security configuration identities and � User accounts and password broker relationships between distributed � Security activities with and for the resources registry � In AD a two-way � Set security relevant keys (e.g. Disable transitive trust is insecure hash) – regedit.exe assumed by default � Protection of registry entries with AC rights 3

Active Directory Domain/Group Policies � To regulates security � The domain model policies are used (each domain contains Domain A (Root) users, groups and � Domain/group policies regulate for machines) forms a tree Domain B one domain/group of domains (Child) � Inheritance can be � Additionally users, controlled groups and computers � Local computer Domain C (Child) can be organized in policy Organizational Units � A resultant set of (OU). policies is build Security Administration Encrypted File System (EFS) � EFS can encrypt/decrypt files transparently (Command Line, Explorer and Backup support) when using the NTFS file system � How it works � File/Directory encrypted symmetrically (AES in 2003 and DES in XP) with a „file encryption key“ (FEK) � FEK is encrypted with the users Public Key and eventually with the recovery keys (if enabled) � A list of encrypted FEK is attached to the File Event Monitoring Security tool for Windows � Event Log service � Management Consol monitors the system � See earlier � Policies configure � Security Baseline Analyzer the event monitor � Example in the lecture � Event viewer shows the events 4

Generic � Do not install packages you do not need Linux Security � Verify the Hash Value of the package/files � Do not start services and demons you Linux Kernel 2.4.x and 2.6.x do not need � If you want more security in Linux you can use additionally tools System start-up Shadow File � Lock the BIOS � Passwords are stored in /etc/passwd Root:toarjakdfnjasdjf:0:0:root:/root:/bin � Lock LILO (GRUB) /bash � Set the permission to lilo.conf � PW are hashed but that is not enough � Require a PW when booting in single-user because the file can be access by (put the user into a root shell) mode everyone � Control the start scripts to see what � Solution: /etc/shadow services are started at which run levels � Can only be accessed by root � Can age PW‘s PAM syslog – system loging utility Plugable authentication module More info: www.kernel.org/linux/libs/pam/ 5

PAM.d PAM.d � A file for each PAM aware application � Control flags must return success; execution continues � File entry required requisite must return success; failure stop Module type control flag module path arguments execution not required; if the only it determines optional � Module types sufficient if success all remaining are ignored auth prompt the user for identification [value1=action1...] extended control flag for account checks aspects of the users account more control session provides functions before and after session � Arguments establishment (e.g. environment ...) password responsible for updating the user � A number of argument regulate the reporting behavior authentication token (syslog and application) PAM example Security tools for Linux auth required /lib/security/pam_securetty.so � Bastille auth required /lib/security/pam_env.so � Tool to investigate the system weaknesses and harden linux auth sufficient /lib/security/pam_unix.so likeauth � Tripwire nullok auth required /lib/security/pam_deny.so � Assuring system consistency with check sums auth required /lib/security/pam_nologin.so � CRACK account required /lib/security/pam_unix.so � Password cracking program for Linux password required /lib/security/pam_cracklib.so retry=3 � SARA password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow nis � Vulnerability testing (not only for Linux) password required /lib/security/pam_deny.so � Nessus session required /lib/security/pam_limits.so � Another scanner where you can also write your own attack session required /lib/security/pam_unix.so scripts session optional /lib/security/pam_console.so � ... Requirements � Mechanisms Trusted operating systems � Strong Authentication � MAC or RBAC � Controlled and monitored invocation of processes � Virtualization � Assurance 6