Unix, History

Transcription

1 Operating systems Examples from Unix, VMS, Windows NT on user authentication, memory protection and file and object protection. Trusted Operating Systems, example from PitBull

2 Unix, History

3 Unix, History

4 Unix Each user has a unique id and belongs to one or more groups. Users are divided into three domains: user, group and world (all). The privileged user is called root. Runs in two modes: kernel and user.

5 User authentication The kernel itself treats users as numbers. Each user is identified by a unique integer, the user id or uid A separate database outside the kernel assigns a textual name, the user name to each user id. Other information in the database: Username Password, in an encrypted form. Numeric user id. Numeric group id. Full name or other description of account. Home directory. Login shell (program to run at login).

6 User authentication The basic user database in a Unix system is the text file, /etc/passwd (called the password file). Any user on the system may read the password file, so that they can, for example, learn the name of another user. Many Unix systems have shadow passwords. This is an alternative way of storing the password: the encrypted password is stored in a separate file, (e.g. /etc/shadow), which only root can read. The /etc/passwd file only contains a special marker in the second field. Any program that needs to verify a user is setuid, and can therefore access the shadow password file.

7 /etc/passwd examples No shadow password file: troot:lrlqho051w3c.:0:1:operator:/:/usr/local/bin/tcsh sroot:kfi6w.uvpzeng:0:1:operator:/:/bin/sh rolle:bv4vybp.fsbng:6915:43:roland Parviainen:/c8/rolle:/usr/local/bin/bash Shadow password file: root:x:0:0:root,,,:/root:/bin/bash rolle:x:501:501:roland Parviainen:/home/rolle:/bin/bash

8 Logging in Logging in from a terminal

9 File and object protection Has a single hierarchical tree structure; all of the mounted files and filesystems are presented as one integrated virtual filesystem. Devices such as soundcards, modems and floppy drives are represented by a device special files in /dev/. Example: /dev/sound Every file and directory in the virtual filesystem is represented by one inode. An inode contain, among other things, the following information: mode: describes what this inode represents as well as access rights to it. user and group ids: the owner and the group of the file.

10 File and object protection Access rights: read (r) write (w) execute (or access for directories) (x) set user or group ID on execution (s) A combination of rights can be set for each domain (user, group and world). s is only valid for user and group. Access rights also applies to device special files, e.g /dev/sound. Some Unix operating systems also has Access control lists, such as Secure HP-UX or Solaris.

11 File and object protection, example Want to give access to /dev/sound to Alice, Bob and Carol but not Dave Create a new group abc, containing Alice, Bob and Carol Change the group of /dev/sound to abc Create a group sound, change the group of /dev/sound to sound Add Alice, Bob and Carol to group sound

12 File and object protection, example cron run commands at specified times Commands to be run are stored in /var/spool/cron/, owned by root A user adds a command using the crontab command crontab need to be set uid root! drwx root root 4096 nov 19 20:01 /var/spool/cron/ -rwsr-xr-x 1 root root jul /usr/bin/crontab

13 File and object protection, example You can send a message to another user logged in using the write command The write command need to have permissions to write text to any user s text terminal write set group id tty All text terminal devices owned by group tty -rwxr-sr-x 1 root tty 7900 apr 25 15:06 /usr/bin/write crw--w rolle tty 136, 6 maj 3 19:11 /dev/pts/6

14 Memory protection Each process in the system has its own virtual address space. These virtual address spaces are completely separate from each other. Paging.

15 Memory protection Example of information in the page table (from Linux on Alpha): V: Valid FOE: "Fault on execute", Whenever an attempt to execute instructions in this page occurs, the processor reports an error and passes control to the operating system FOW: "Fault on write", As above, but an error on write FOR: "Fault on read", As abobe, but an error on read KRE: Code running in kernel mode can read this page URE: Code running in user mode can read this page KWE: Code running in kernel mode can write to this page UWE: Code running in user mode can write to this page Page frame number

16 VMS OpenVMS: originally called VMS (Virtual Memory System) First conceived in 1976 as a new operating system for Digital's new, 32-bit, virtual memory line of computers, eventually named VAX (Virtual Address extension) VMS version X0.5 was the first released to customers, in support of the hardware beta test of the VAX-11/780, in VAX/VMS Version V1.0 shipped in Now runs on Digitals (Compaq) Alpha computers. C2 Certified

17 VMS, Authentication Keeps a history of the user's passwords, which prevents the selection of passwords that have been used recently. Can be made to enforce the changing of passwords on a regular basis. A user can be forced to select a password from a randomly generated collection. A password selected by a user is checked against a list of commonly used passwords. Passwords are stored in the User Authorization File (SYS$SYSTEM:SYSUAF.DAT) using one-way encryption.

18 VMS, System architecture

19 VMS, Hardware Protection Mechanisms CHMx: x: K,E,S,U (Kernel, Executive, Supervisor, User) Kernel is the only mode with access to the full instruction set; the other three operate using the restricted subset of instructions. REI returns to the former mode. CHMx can only change inwards towards "higher" modes. REI can only change outwards towards "lower" modes. Executive: For RMS only, record managements services (handles all files on disk) Supervisor mode: For CLI, command line interface

20 VMS, Object and File protection To determine the rights a domain (i.e. user, subject), the system checks the following mechanisms in order: Access control lists User identification codes (UICs) Privileges

21 VMS, Object and File protection Read Write Execute Delete Control File Read, print or copy Write or modify Execute if program Delete Change rights Folder List all entries Create new files List specified entries Delete if empty Change rights

22 VMS, UIC Protection UIC, User Identification Code Divides the users into four domains: System, Owner, Group and World. Each user belong to one group System: a special Group System and Owner has control rights World never has control rights (System rights, Owner rights, Group Rights, World rights) E.g.: (RWED, RWE, RE, R)

23 VMS, Privilege Protection 64 bits are available for each user. Examples: SYSPRV causes the user to be treated as if the user were in the System domain. BYPASS permits unconditional and unlimited access to an object. READALL permits read and control access. When a program is run, the users privileges are merged with the privileges for the program (using OR). This provides the ability for unprivileged users to run privileged programs.

24 VAX Security Kernel Targeted at the A1 level of the TCSEC. Backwards compatible with VMS The security kernel emulated the VAX hardware, including all modes, virtual memory, I/O devices etc. Built twice during the 1980's. Terminated in 1990.

25 Windows NT Windows NT 3 Late 80's Windows NT Windows NT Windows 2000 (5.0) Feb 2000 Windows XP (5.1) Late 2001

26 Windows NT Based on a microkernel, designed to be as small as efficient as possible. Most operating services are implemented by semi-independent secondary subsystems. Two execution modes: user mode and kernel mode. Kernel mode: complete access to every system resource and of all memory.

27 NT, System architecture

28 NT, System architecture I/O Manager: controls most input and output Object Manager: creates, modifies and deletes system objects (e.g. a file or process) Security Reference Manager (SRM): grants and denies requests for access to objects and system resources by the object manager. Relies on Security Access Tokens (SATs)

29 Memory system Demand paged, virtual memory system Flat, linear 32-bit address space (up to 4 GB) Pages 4kB in size Pages in use are redirected to physical RAM

30 User authentication The privileged user is called Administrator by default (can be changed). Items may be temporarily protected against the Administrator account, but Administrator can always change their permissions to gain access. Passwords are stored in the user accounts database (Security Account Database, SAD) hashed (a one-way encryption). The SAD is managed by the security account manager (SAM). The encrypted passwords can be read by a user. Users can be forced to change their passwords after a period of time. A history of already used passwords can also be stored. Users can be locked out of the system after a certain amount of failed login attempts.

31 Local Security Authority (LSA) Validates local and remote logins Generates access tokens during the login process Manages local security policies Provides user authentication and validation Logs audiot messages generated by the SRM (Security Reference Monitor)

32 Security Reference Monitor, SRM Runs in kernel mode Responsible for checking access to objects

33 Security subsystem Security Policy Database Login process Local Security Authority Security Account Manager Audit log Security Account Database User Mode Security Reference Monitor Kernel Mode

34 User authentication The user authentication process Enter the useridand password The password is hashed (encrypted) and sent to the local security authority (LSA) LSA makes a call to SAM and compares the hash stored in the SAD. LSA creates an access token using the user's account Security ID (SID) and group SIDs. The NT explorer shell opens with the user's access token attached.

35 User authentication WinLogon (User, Password) AT Win32 subsyst. 6 7 AT 1 AT LSA 2 5 SAM 3 4 New process AT 8 Explorer AT SAD

36 Access Tokens Access tokens are created by the Local Security Authority after SAM validation, as part of a successful logon process. All processes created by the user has a copy of the token attached to it. Information in the token: User's security identifier (SID) Group security identifiers User privileges Primary Group SID (only used by the POSIX subsystem) Default ACL (assigned to any object created by the user)

37 Possible user privileges Around 30 specific 'user rights' can be assigned to users or groups. Examples: Access this computer from network Change the system time Shut down the system Not even administrators have all privileges by default

38 File and object protection The NTFS (NT File System) has some security features: Discretionary Access Control (DAC). Journaling Information about files are stored in the master file table (MFT). Examples of information: the filename, security attributes, etc. Files have only a single owner, group ownership does not exist. Access control lists (ACLs) are used to control access to files, directories and objects.

39 File protection NTFS Permission Read (R) Write (W) Execute (X) Delete (D) Change Permissions (P) Take ownership (O) delete a folder Folders Display folder names, attributes, owner & permissions Add file & folders, change a folders attribute, display owner & permissions Display folder attributes, make changes to folders within a folder, and display owner & permissions Change a folders permissions Take ownership of the folder Display file data, attributes, owner & permissions Display owner & permissions, change file attributes, create data in and append data to a file. Display file attributes, owner & permissions. Run a file if it is an executable. Delete a file File Change the permissions on the file Take ownership of a file.

40 PitBull From Argus Systems Add on to Sun Solaris and IBM AIX Has features comparable to B2 Principles: Information Compartmentalization Role Compartmentalization Least privilege Kernel-level enforcement

41 Information Compartmentalization Preventing any user (inc. root) from viewing or modifying information the user is not cleared for. Prevent compromises in one application from being used for attacks against other unrelated applications MAC, mandatory access controls Based on Sensitivity Labels - SLs. Every object has a SL (including files and processes) Some objects can have more than one SL, such as directories (to specify a range for example)

42 SLs Two components: classifications and compartments Classification - hierarchical, such as Top Secret, Secret, Confidential Compartments - non-hierarchical A SL can have any number of compartments Example: Top Secret: A, B

43 Dominance relationships Dominant, Equal and Disjoint A process can read but not write any file which it dominates but does not equal Writes are permitted if and only if the process's SL equals the file's SL Examples: A process with a Top Secret SL can read but not write a file with a Confidential SL A Top Secret: A process can neither read nor write a Confidential: A B file

44 Clearance A user have three SLs, which form the clearance of the user Minimum, default and maximum SL At login, a user get the default SL, unless an SL is requested: login: smith -e "othersl a b" Can not change SL while running without special privileges

45 Role Compartmentalization Access to a root shell should not give control of the entire system Combination of privileges and authorizations root's old "can do anything"-privilege has been divided into smaller abilities called privileges Example: Mounting filesystems, Changing MACs, etc. Authorizations are assigned to users Privileges belong to processes and executable files If a user is not authorized for a privilege, executing a privileged file will not help Different users for configuring hardware, adding users, changing MACs and SLs.

46 Least privilege A process should only have the minimum necessary privileges A user should only have the authorizations necessary to do his duties

47 Compartment A https-weba Process: Secret: Web, Server, A Compartment B https-webb Process: Secret: Web, Server, B Shared files SL: Confidential: Web, Server HTML docs for https-weba SL: Confidential: Web, A Owner: weba User weba SL: Conf.: Web, A Auths: LOGIN WEBA EXECENV HTML docs for https-webb SL: Confidential: Web, B Owner: webb User webb SL: Conf.: Web, B Auths: LOGIN WEBB EXECENV

48 PitBull Summary Complex to administer Still relies on the integrity of the kernel

49 Data base security Next time