Outline Access control: mechanism and policy Unix filesystem - PDF document

Outline Access control: mechanism and policy Unix filesystem concepts CSci 4271W Development of Secure Software Systems Project 1 expectations Day 8: Unix Access Control Unix permissions basics Stephen McCamant Exercise: using Unix permissions University of Minnesota, Computer Science & Engineering More Unix permissions Configurability Confidentiality and integrity Basic idea: let one mechanism (implementation) support a variety of security policies Access control directly serves two security goals: I.e., make security a system configuration Confidentiality, opposite of information disclosure Classic example for today: OS access control Integrity, opposite of tampering Flexible mechanism to support different policies By prohibiting read and write operations respectively Trade-off: an incorrect configuration can lead to insecurity Access control policy Access control matrix Decision-making aspect of OS grades.txt /dev/hda /usr/bin/bcvi Should subject ❙ (user or process) be allowed to Alice r rw rx access object (e.g., file) ❖ ? Bob rw - rx Carol r - rx Complex, since admininstrator must specify what should happen Slicing the matrix Groups/roles ❖ ✭ ♥♠ ✮ matrix impractical to store, much less Simplify by factoring out commonality administer Before: users have permissions Columns: access control list (ACL) After: users have roles, roles have permissions Convenient to store with object E.g., Unix file permissions Simple example: Unix groups Rows: capabilities Complex versions called role-based access control Convenient to store by subject (RBAC) E.g., Unix file descriptors

Outline One namespace Access control: mechanism and policy Unix filesystem concepts All files can be accessed via absolute pathnames Project 1 expectations made of directory components separated by slashes I.e., everything is a descendant of a root directory Unix permissions basics named ✴ Exercise: using Unix permissions More Unix permissions Filesystems and mounting Special files and devices Some hardware devices (disks, serial ports) also There may be multiple filesystems, like disk partitions look like files or removable devices Usually kept under ✴❞❡✈ One filesystem is the root filesystem that includes Some special data sources look like devices the root directory ✴❞❡✈✴♥✉❧❧ , ✴❞❡✈✴③❡r♦ , ✴❞❡✈✴✉r❛♥❞♦♠ Other filesystems are mounted in place of a Some OS data also available via ✴♣r♦❝ and s②s directory filesystems E.g., ✴♠❡❞✐❛✴s♠❝❝❛♠❛♥✴♠♣✸♣❧❛②❡r✴♣♦❞❝❛st✳♠♣✸ E.g., ✴♣r♦❝✴s❡❧❢✴♠❛♣s Current directory, relative paths Inodes Most information about a file is a structure called an At a given moment, each process has a current inode working directory Changed by ❝❞ shell command, ❝❤❞✐r system call Includes size, owner, permissions, and a unique inode Pathnames that do not start with ✴ are interpreted number relative to the current directory Inodes exist independently of pathnames Directory entries and links Entries . and .. A directory is a list of directory entries, each Every directory contains entries named ✳ and ✳✳ mapping from a name to an inode ✳ links back to the directory itself These mappings are also called links ✳✳ links back to the parent directory, or itself for the “Deleting a file” is really removing a directory entry, root The system call ✉♥❧✐♥❦

(Hard) links Symbolic links Multiple directory entries can link to the same inode Symbolic links are a different linking method A symbolic link is an inode that contains a pathname These are called hard links Most system calls follow symbolic as well as hard Only allowed within on filesystem, and not for links to operate on they point to directories Outline Report overall length Access control: mechanism and policy 4-5 pages in US Letter (8.5 x 11in), 1 inch margins Unix filesystem concepts Double-spaced 10 point Times, Times Roman, or Project 1 expectations Computer Modern Roman Unix permissions basics Figures, code examples, etc., go at the end, don’t count in the 4-5 pages. Exercise: using Unix permissions Will submit online as PDF More Unix permissions Threat modeling Auditing for vulnerabilities There are at least four bugs that are definitively You should include at least one data-flow diagram problematic The diagram should have enough detail to inform You need to identify at least three your threat modeling Good to also include: E.g., ❜❝✐♠❣✈✐❡✇ should not be a single component Dangerous locations that are not vulnerable in the current Threats should include, but are not limited to, the program Dangerous locations that you’re not sure if they can be ones you’ll address in the auditing attacked Attacks Rules reminders This is an individual assignment, not collaborative Include three for full credit, you should be sure they Non-spoiler Piazza or office-hour discussions are OK work The writing should be entirely your own Include enough detail to convince me that you really did make the attack work Use of public, non-class materials is allowed, but should be acknowledged For attack inputs, consider showing figure of hex No specific requirement for citation format for this project dump with relevant parts highlighted

Outline UIDs and GIDs Access control: mechanism and policy To kernel, users and groups are just numeric Unix filesystem concepts identifiers Names are a user-space nicety Project 1 expectations E.g., ✴❡t❝✴♣❛ss✇❞ mapping Unix permissions basics Historically 16-bit, now 32 Exercise: using Unix permissions User 0 is the special superuser r♦♦t Exempt from all access control checks More Unix permissions File mode bits Interpretation of mode bits File also has one user and group ID Core permissions are 9 bits, three groups of three Choose one set of bits Read, write, execute for user, group, other If users match, use user bits If subject is in the group, use group bits ❧s format: r✇① r✲① r✲✲ Otherwise, use other bits Octal format: 0754 Note no fallback, so can stop yourself or have negative groups Directory mode bits Other permission rules Same bits, slightly different interpretation Only file owner or root can change permissions Read: list contents (e.g., ❧s ) Only root can change file owner Write: add or delete files Former System V behavior: “give away ❝❤♦✇♥ ” Setuid/gid bits cleared on ❝❤♦✇♥ Execute: traverse Set owner first, then enable setuid X but not R means: have to know the names Non-checks Outline Access control: mechanism and policy File permissions on st❛t Unix filesystem concepts File permissions on link, unlink, rename Project 1 expectations File permissions on read, write Unix permissions basics Parent directory permissions generally Except traversal Exercise: using Unix permissions I.e., permissions not automatically recursive More Unix permissions

Setting: files related to this class Users and groups Users: smccaman (instructor), paul1155 (TA), Student and course staff materials stude003 (student) Imagine everything is in Unix files on CSE Labs Groups: csci4271staff (instructor and TA), csci4271all Versus reality of a mixture of Unix with web-based systems like Canvas (staff and students) What I want from you Outline Access control: mechanism and policy Unix filesystem concepts Brainstorm sets of octal permissions bits that could Project 1 expectations be used For each permission bits set, give user, owner, and Unix permissions basics file/directory contents/use that would be sensible Exercise: using Unix permissions More Unix permissions Process UIDs and s❡t✉✐❞✭✷✮ Setuid programs, different UIDs If 04000 “setuid” bit set, newly exec’d process will UID is inherited by child processes, and an take UID of its file owner unprivileged process can’t change it Other side conditions, like process not traced But there are syscalls root can use to change the Specifically the effective UID is changed, while the UID, starting with s❡t✉✐❞ real UID is unchanged E.g., login program, SSH server Shows who called you, allows switching back More different UIDs Setgid, games Two mechanisms for temporary switching: Setgid bit 02000 mostly analogous to setuid Swap real UID and effective UID (BSD) But note no supergroup, so UID 0 is still special Remember saved UID , allow switching to it (System V) Classic application: setgid ❣❛♠❡s for managing Modern systems support both mechanisms at the high-score files same time

Special case: ✴t♠♣ Special case: group inheritance When using group to manage permissions, want a We’d like to allow anyone to make files in ✴t♠♣ whole tree to have a single group So, everyone should have write permission When 02000 bit set, newly created entries with But don’t want Alice deleting Bob’s files have the parent’s group (Historic BSD behavior) Solution: “sticky bit” 01000 Also, directories will themselves inherit 02000 Other permission rules Only file owner or root can change permissions Only root can change file owner Former System V behavior: “give away ❝❤♦✇♥ ” Setuid/gid bits cleared on ❝❤♦✇♥ Set owner first, then enable setuid