SENG 5199-3 Data and Network Security Lecture 11 Access Control

1. SENG 5199-3 Data and Network SecurityLecture 11Access Control Yongdae Kim

2. News Today • Drobbox insecurity • Epsilon • DHCP client flaw • Anatomy of RSA attack • Anonymous vs. Sony • Tor

3. Operating Systems • Typical OS classes focus on the resource allocation function of the OS. • Another important function of the OS is resource protection: • Preventing errors in one process from effecting another’s • Protecting the system’s resources from misuse.

4. OS Security • OS Security is essentially concerned with four problems: • User authentication links users to processes. • Access control is about deciding whether a process can access a resource. • Protection is the task of enforcing these decisions: ensuring a process does not access resources improperly. • Isolation is the separation of processes’ resources from other processes.

5. Access Control • The OS mediates access requests between subjects and objects. • This mediation should (ideally) be impossible to avoid or circumvent. ? Object Subject Reference monitor

6. Definitions • Subjects make access requests on objects. • Subjects are the ones doing things in the system, like users, processes, and programs. • Objects are system resources, like memory, data structures, instructions, code, programs, files, sockets, devices, etc… • The type of access determines what to do to the object, for example execute, read, write, allocate, insert, append, list, lock, administer, delete, or transfer

7. Access Control • Discretionary Access Control: • Access to objects (files, directories, devices, etc.) is permitted based on user identity • Each object is owned by a user. • Owners can specify freely (at their discretion) how they want to share their objects with other users, • by specifying which other users can have which form of access to their objects. • Discretionary access control is implemented on any multi-user OS (Unix, Windows NT, etc.). • Mandatory Access Control: • Access to objects is controlled by a system-wide policy • for example to prevent certain flows of information. • In some forms, the system maintains security labels for both objects and subjects • based on which access is granted or denied. • Labels can change as the result of an access • Security policies are enforced without the cooperation of users or application programs. • Mandatory access control for Linux: http://www.nsa.gov/research/selinux/

8. Access Control Matrix

9. Representations • An access control matrix can be represented internally in different ways: • Access Control Lists (ACLs) store the columns with the objects • Capability lists store the rows with the subjects • Role-based systems group rights according to the “role” of a subject.

10. Access Control Lists • The ACL for an object lists the access rights of each subject (usually users). • To check a request, look in the object’s ACL. • ACLs are used by most OSes and network file systems, e.g. NT, Unix, and AFS.

11. ACL Problems • To be secure, the OS must authenticate that the user is who (s)he claims to be. • To revoke a user’s access, we must check every object in the system. • There is often no good way to restrict a process to a subset of the user’s rights.

12. Capabilities • Capabilities store the allowed list of object accesses with each subject. • When the subject requests access to object O, it must provide a “ticket” granting access to O. • These tickets are stored in an OS-protected table associated to each process. • No widely-used OS uses pure capabilities. • Some systems have “capability-like” features: e.g. Kerberos, NT, OLPC, Android

13. ACL vs. Capabilities • Capabilities do not require authentication: the OS just checks each ticket on access requests. • Capabilities can be passed, or delegated, from one process to another. • We can limit the privileges of a process, by removing unnecessary tickets from the table.

14. Roles • In many systems, subjects play one or more roles. This role includes access to objects. • Users log in as their role, and can access the objects needed for that role. • For example a hospital might have roles like: Doctor, Nurse, Pharmacist, Receptionist, Lawyer, Accountant, Executive… • Because there are fewer roles than subjects, the access control matrix is stored efficiently.

15. Roles … … S1 S2 S3 Sm S1 S2 S3 Sm R1 R2 O1 O2 … On O1 O2 … On

16. Unix/POSIX Access Control

17. Unix/POSIX Access Control • Traditional Unix uses a restricted form of access control list on files. • Every user is identified by an integer number (user ID). • Every user also belongs to at least one “group”, each of which is identified by an integer number (group ID). • Processes started by a user inherit the user and group ID. • Each file carries both an owner’s user ID and a single group ID. • Each file carries nine permission bits. • The first three specify whether “read”, “write”, and “execute” access is granted if the process user ID matches the file owner ID. • Otherwise, if one of the group IDs of the process matches the file group ID, the second bit triplet determines access. • If this is also not the case, the final three bits are used.

18. Unix/POSIX Access Control • In the case of directories • the “read” bits decide whether the names of the files in the directory can be listed • the “execute” bits decide whether “search” access is granted • that is whether any of the attributes and contents of the files in the directory can be accessed via the directory. • Write access to a directory is sufficient to remove any file and empty subdirectory in it, independent of the access permissions for what is removed. • Berkeley Unix added a tenth access control bit: the “sticky bit”. • If it is set for a directory, then only the owner of a file in it can move or remove it, even if others have write access to the directory. • This is commonly used in shared subdirectories for temporary files, such as /tmp/ or /var/spool/mail/.→ User ID 0 (“root”) has full access.

19. Unix/POSIX Access Control kyd@dio (~) % id uid=3259(kyd) gid=717(faculty) groups=717(faculty),1686(mess),1847(S07C8271),1910(F07C5471),2038(S08C8271) kyd@dio (~) % ls -l News_and_Recent_Events.zip -rw-rw-rw- 1 kyd faculty 714904 Feb 22 10:00 News_and_Recent_Events.zip kyd@dio (/web/classes02/Spring-2011/csci5471) % ls –al drwxrwsr-x 4 kyd S11C5471 512 Jan 19 10:23 ./ drwxr-xr-x 46 root daemon 1024 Feb 17 23:04 ../ drwxrwsr-x 3 kyd S11C5471 512 Feb 16 00:36 Assignment/

20. Mandatory Access Control policies • Restrictions to allowed information flows are not decided at the user’s discretion (as with Unix chmod), but instead enforced by system policies. • Mandatory access control mechanisms are aimed in particular at preventing policy violations by untrusted application software, which typically have at least the same access privileges as the invoking user.

21. Air Gap Security • Uses completely separate network and computer hardware for different application classes. • Examples • Some hospitals have two LANs and two classes of PCs for accessing the patient database and the Internet. • Some military intelligence analysts have several PCs on their desks to handle top secret, secret and unclassified information separately. • No communication cables are allowed between an air-gap security system and the rest of the world. • Exchange of storage media has to be carefully controlled. • Storage media have to be completely zeroized before they can be reused on the respective other system

22. Data Pump/Data Diode • Like “air gap” security, but with one-way communication link that allow users to transfer data from the low-confidentiality to the high- confidentiality environment, but not vice versa. • Examples: • Workstations with highly confidential material are configured to have read-only access to low confidentiality file servers.

23. The Bell/LaPadula model • Formal policy model for mandatory access control in a military multi-level security environment. • All subjects (processes, users, terminals) and data objects (files, directories, windows, connections) are labeled with a confidentiality level • e.g. unclassified < confidential < secret < top secret. • The system policy automatically prevents the flow of information from high-level objects to lower levels. • A process that reads top secret data becomes tagged as top secret by the operating system, as will be all files into which it writes afterwards. • Each user has a maximum allowed confidentiality level specified and cannot receive data beyond that level. • A selected set of trusted subjects is allowed to bypass the restrictions, in order to permit the declassification of information.

24. The covert channel problem • Reference monitors see only intentional communications channels, such as files, sockets, memory. • However, there are many more “covert channels”, which were neither designed nor intended to transfer information at all. • A malicious high-level program can use these to transmit high-level data to a low-level receiving process, who can then leak it to the outside world. • Examples for covert channels: • Resource conflicts – If high-level process has already created a file F, a low-level process will fail when trying to create a file of same name → 1 bit information. • Timing channels – Processes can use system clock to monitor their own progress and infer the current load, into which other processes can modulate information. • Resource state – High-level processes can leave shared resources (disk head position, cache memory content, etc.) in states that influence the service response times for the next process. • Hidden information in downgraded documents – Steganographic embedding techniques can be used to get confidential information past a human downgrader (least-significant bits in digital photos, variations of punctuation/spelling/whitespace in plaintext, etc.).

25. Key Management for Authentication

26. Kerberos vs. PKIvs. IBE • Still debating  • Let’s see one by one!

27. Kerberos • Basic • A, B, a TTP share long-term pairwise secret keys a priori • TTP either plays the role of KDC and itself supplies the session key, or serves as a key translation center (KTC) • A and B share no secret, T shares a secret with each • Goal: for B to verify A’s identity, establishing shared key • Description • A requests for credential to allow it to authenticate itself • T plays the role of a KDC, returning to A a session key encrypted for A and a ticket encrypted for B • The ticket contains the session key and A’s identity

28. A, B, NA EKBT(k, A, L), EKAT(k, NA, L, B) EKBT(k, A, L), Ek(A, TA, Asubkey) Ek(TA, Bsubkey) Kerberos (cnt.) T • EKBT(k, A, L): Token for B • EKAT(k, NA, L, B): Token for A • L: Life-time • NA? • Ek(A, TA, Asubkey): To prove B that A knows k • TA: Time-stamp • Ek(B, TA, Bsubkey): To prove A that B knows k B A

29. Kerberos (cnt.) • T • AS (Authentication Server) in Kerberos paper • Properties • secure and synchronized clocks • If password-based, protocol is susceptible to password-guessing attack • Asubkey and Bsubkey allow transfer of a key from A to B • Lifetime is intended to allow A to re-use the ticket

30. EKAG(kAB, NA’, L, B), EkGB(kAB, A, L, NA’), B, NA’ EKGT(kAG, A, L), EKAT(kAG, NA, L, G) A, G, NA EKGT(kAG, A, L), EkAG(A, TA), B, NA’ EKGB (kAB, A, L, NA’), EkAB(A, TA’, Asubkey) Ek(TA’, Bsubkey) Kerberos (Scalable) T (AS) G (TGS) B A

31. Public Key Certificate • Public-key certificates are a vehicle • public keys may be stored, distributed or forwarded over unsecured media • The objective • make one entity’s public key available to others such that its authenticity and validity are verifiable. • A public-key certificate is a data structure • data part • cleartext data including a public key and a string identifying the party (subject entity) to be associated therewith. • signature part • digital signature of a certification authority over the data part • binding the subject entity’s identity to the specified public key.

32. CA • a trusted third party whose signature on the certificate vouches for the authenticity of the public key bound to the subject entity • The significance of this binding must be provided by additional means, such as an attribute certificate or policy statement. • the subject entity must be a unique name within the system (distinguished name) • The CA requires its own signature key pair, the authentic public key. • Can be off-line!

33. Data Part • a validity period of the public key • a serial number or key identifier identifying the certificate • additional information about the subject entity (e.g., street or network address) • additional information about the key (e.g., algorithm and intended use); • quality measures related to the identification of the subject entity, the generation of the key pair, or other policy issues; • information facilitating verification of the signature (e.g., a signature algorithm identifier, and issuing CA’s name) • the status of the public key (cf. revocation certificates).

34. ID-based Cryptography • No public key • Public key = ID (email, name, etc.) • PKG • Private key generation center • SKID = PKGS(ID) • PKG’s public key is public. • distributes private key associated with the ID • Encryption: C= EID(M) • Decryption: DSK(C) = M

35. Discussion (PKI vs. Kerberos vs. IBE) • On-line vs. off-line TTP • Implication? • Non-reputation? • Revocation? • Scalability? • Trust issue?