OS Mechanisms (Unix-File System, Setuid)

Effective User Id (euid)

----Each process has a real, effective, and saved user ID (UID): ----Real UID (RUID): The actual user that started the process, inherited from parent. Identifies the user. ----Effective UID (EUID): The permissions granted to the process. Can be changed by setuid bit or seteuid() calls. Controls file access, port binding, etc. ----Saved UID (SUID): Stores previous EUID so it can be restored later. ----Similarly, there are real, effective, and saved group IDs (GID) that serve analogous purposes for groups. ----The EGID determines group permissions granted to the process. So in summary: ----RUID identifies the user, EUID determines process permissions, SUID allows restoring previous EUID. ----EUID is key for controlling access, changed by setuid or seteuid(). ----GID/EGID control group permissions. ----Multiple IDs allow separation of identification, privileges, and saved permissions.

Process Operations and IDs

----The root user has user ID (UID) 0. This gives the superuser access to any file on the system. ----When a process forks or executes a new program, it inherits the real, effective, and saved UID from the parent process. ----However, executing a file with the setuid bit set will change the effective UID to that of the file owner. ----There are system calls like seteuid() that allow a process to change its effective UID to specified value. This allows manipulating privileges. ----The full details are more nuanced: ----There are separate calls to set real, effective, and saved UIDs (setuid, seteuid, setreuid). ----Real ID represents the actual user, while effective ID represents current privileges. ----Saved ID allows switching back to previous privilege levels. So in summary, processes inherit IDs on fork/exec except with setuid files, but the system calls allow processes to manipulate privileges in various ways by changing the different types of UIDs. Managing privileges is complex.

Unix File Access Control

Each file entry in a directory is a pointer to a data structure called inode. mode - Type of file and access rights uid - User who owns the file gid - Group which owns the file atime - Access time mtime - Modification time itime - Inode alteration Block count - Size of file (sort of)

Unix

Each file has an associated owner and group. The owner is typically the user that created the file. The group allows setting common permissions for a set of users. The file owner sets the file permissions for read, write, and execute access for the owner, group, and other (everyone else). These rwx permissions are represented by a vector of four octal digits. Each digit represents the permissions for owner, group, and other. Only the file owner or root user can change the permissions on a file. This prevents other users from inadvertently or maliciously changing permissions. The ability to change file permissions is a privileged capability that cannot be shared or delegated to other users. This maintains security boundaries. Setuid and setgid bits are special permission bits that allow a file to temporarily elevate privileges when executed. More details on these later. In summary, file permissions strictly control access, are changeable only by the superuser, and setuid/setgid al

Unix Groups

Every user belongs to one or more groups. ●The GID of primary group the user belongs to is stored in passwd file. ●Groups useful for access control features. ●/etc/groups contains a list of all groups in the system along with GID's. ●Some special groups - ○wheel - group of administrators ○uucp, lp, etc. - groups corresponding to special users.

File Permission Bits

File permission bits apply to the underlying file, not symbolic links pointing to that file. So permissions are enforced on the real file, not the link. On some systems, if you have execute permission but not read permission, you can execute a program without being able to read/access the program file itself. However, on Linux read access is required to execute a program. This provides additional security. For directories, the execute permission bit allows listing files in that directory. Denying execute permission prevents viewing directory contents. This can improve security by hiding file names/contents, but may cause issues for programs trying to access files in that directory. File permissions can also be represented in octal notation: 0777 is rwx for owner, group, and other 0600 is rw for owner, but no access for group or other The octal digits represent the rwx permissions in each category. In summary, link permissions don't apply to the real file, execute meaning varie

Unix File Permission Bits

File permissions obtained by ls -l command First character indicates type of file ○ - plain file ○ d directory ○ c character device (tty or printer) ○ b block device ○ l symbolic link ○ Etc Look at slide 39 for the image

The slides answer:

Prioritized resolution of differences if user = owner then owner permission else if user in group then group permission else other permission

More on suid Bit

Sometimes unprivileged users must perform tasks that are privileged. ○ Change user's shell thereby modify /etc/passwd ●UNIX allows certain programs to change UID to their owner when executed. ○ SUID programs - change UID to owner. ○ SGID programs - change GID to owners group. ●ls -l command indicates if SUID or SGID ○ -rwsr-xr-x indicates SUID ○ -rwxr-sr-x indicates SGID

Unix Special Users

Special user with extra privileges -root. ○ UID is 0. ○ Can do (almost) anything!! ○ Holy grail of hackers! ●Other special users ○ daemon or sys - handles some network services ○ ftp - used for anonymous FTP access. ○ uucp - manages UUCP system. ○ guest - used for site visitors. ○ lp - used by printer system ○ Other special users exist

Limitations of Unix File System

limitations of abbreviated ACLs like those in UNIX: Abbreviated ACLs, like the standard user/group/other file permissions in UNIX, have limitations in expressing more complex access scenarios. For example, consider a case with 5 users - Anne, Beth, Cathy, Della, and Elle. Anne wants to set custom permissions: Beth - Read only Cathy - Write only Della - Read and write Elle - Execute only This is not possible to represent using the standard UNIX file permission bits for owner, group, and other. Those only allow setting read/write/execute for 3 categories. So abbreviated ACLs lack the flexibility to express custom combinations of access privileges for individual users. They are limited to broad categories like owner, group, other. More complex ACL systems allow configuring permissions on a per-user or role basis. But standard UNIX permissions are too coarse for scenarios requiring user-specific access controls. In summary, the limitations of abbreviated ACLs motivate more advanced

Unix File Permission Bits

●Next nine characters taken in groups of three indicate who can do what with the file ○R - Permission to read ○W - Permission to write ○X - Permission to execute ●The three classes of permission correspond respectively to ○Owner ○Group ○Other

Other augmentations exist

●SELinux ●AppArmor ●getfacl, setfacl ○https://www.golinuxcloud.com/setfacl-getfaclcommand-in-linux/ ●chown, etc. on Mac ○http://www.techrepublic.com/blog/mac/introdu ction-to-os-x-access-control-lists-acls/1048

Augmenting Abbreviated ACL's

AIX uses extended permissions to augment base permissions. ○ attributes: ---■ base permissions: owner (bishop): rw- ---■ group (sys): r-- ---■ others: --- ○ extended permissions enabled users to: ----■ specify rw- u:heberlei ---■ permit -w- u:nelson, g=sys ---■ permit rw- u:levitt ---■ deny -w- u:heberlei, g=faculty

Adv and Disadv of Unixi security

Advantages: Provides basic protection from unauthorized access by most users through file permissions and separation of users. Flexible enough to allow granting permissions when needed through setuid/setgid bits and superuser privileges. Makes necessary actions possible. Drawbacks: Very tempting for users to operate as root for convenience since root can do anything. But this diminishes security. No easy way to assume only some root privileges without being granted all root privileges. All-or-nothing superuser power. Setuid/setgid only grant privilege escalation to the file owner's permissions. No simple mechanism for gaining specific subsets of root privileges. In summary, Unix provides essential protections and flexibility but has limitations in its coarse-grained superuser model and inability to easily delegate subsets of root privileges. This motivates more advanced security models.

Umask and Default Permissions

The umask is a four-digit octal number that determines the default file permissions for newly created files. It specifies permissions that should NOT be granted by default when creating new files or directories. The umask works by bitwise complementing the desired default permissions. For example: --If umask is 0002, this means: ---Default permissions should be 0775 ---Complementing the umask bits gives the permissions to grant by default ---If umask is 0077: ---Desired default is 0700 ---Complement umask to get 0700 ---If umask is 0022: ---Desired default is 0755 ---Complement umask to get default permissions of 0755 So in summary, the umask specifies which permissions should be removed from the maximum defaults, complementing the bits to determine grants. It is set at login time via environment variables and controls default creation permissions for that session.

Setid Bits on Executable Unix File

There are three setid bits that can be set on executable files to alter privileges: ----Setuid: When executing a file with this bit set, the process's effective UID (EUID) is changed to the owner of the file. This allows assuming the file owner's privileges. ---Setgid: Similar to setuid, but changes the effective GID (EGID) to the group ID of the file. Assumes group privileges. ---Sticky bit: Only applies to directories. Changes file deletion behavior: ---If off - anyone with write permission can delete/rename files in that directory. ---If on - only the file owner, directory owner, or root can delete/rename files within the directory. Prevents accidental deletion. So in summary: ---Setuid and setgid allow temporary privilege escalation when executing files. ----Sticky bit changes delete/rename behavior in directories to prevent accidental deletion. The setid bits allow controlled access beyond the permissions of the executing user.

●If owner has fewer privileges than other or group users: ○ What happens? ■ Owner gets access? ■ Owner does not?

This slide is asking about a scenario where the owner of a file has fewer permissions than other users or groups. There are two possibilities in this case: The owner gets access anyway: Most operating systems grant the owner of a file special privileges, even if the permission bits suggest otherwise. For example, if the owner has r-- permissions but group has rwx, the owner can still access the file with rx privileges. --The owner overrides the permission bits. 2. The owner does not get access: ----Some operating systems enforce the permission bits strictly. ---f the owner sets r-- permissions for themselves, they cannot access the file with rx privileges. ----The permission bits override the special owner privileges. So in summary, either the owner privileges override the permission bits, granting access despite restrictive settings, or the OS enforces permissions strictly, denying the owner access if they have explicitly revoked their own permissions. The behavior depends on the s