Chapter 3, 4 PDF

Chapter 3 By Dr. Mohammad Zunnun Khan exertino over who can Interact with a resource  i Access control refers to exerting control over who can interact with a resource.  Often but not always, this involves an authority, wh...

Chapter 3 By Dr. Mohammad Zunnun Khan exertino over who can Interact with a resource  i Access control refers to exerting control over who can interact with a resource.  Often but not always, this involves an authority, who does the controlling  Access control is, in reality, an everyday phenomenon.  A lock on a car door is a form of access control.  A PIN on an ATM system at a bank is another means of access control.  Access control is of prime importance when persons seek to secure important, confidential, or sensitive information and equipment. Access Control and Root  System Access is implemented through password protection.  The resources associated with a user are accessible only after logging in with the correct password.  Filesystem Access is implemented by every file having an owner and a group.  The owner can have a different set of privileges from group members and other users. Control Mechanisms  Process Ownership also depends on ownership.  Only the owner of a process can send it signals or change its scheduling priority.  Root Privileges gives broad privileges to certain classes of users so that administrative functions such as shutdown and reboot are restricted from ordinary users. dives broad Privitedes certain classes Control Mechanisms  The most basic form of system access is the management of users accounts by administrative users.  Only users with valid usernames and passwords can login to a system.  Linux implements system access through the /etc/passwd file that stores passwords and maps usernames to user identification numbers (UIDs).  Linux allows shared access to certain resources through the /etc/group file that maps group names to group identification numbers (GIDs).  Users can belong to an arbitrary number of groups, but root privileges are required to add or remove users from groups.  Similarly, only root can change passwords for other users. System Access  Instead of keeping the encrypted passwords in the world- readable /etc/passwd, they can be kept in /etc/shadow.  pwconv, punconv, grpconv, grpunconv: convert password/group files to & from shadow. Shadow passwords  Every file has an owner and a owner group  The owner can set the permissions of a file  A owner group allows a file to be shared among members of the same project ◦ Groups are tradi$onally defined in /etc/group, now in an NIS or LDAP server on the network ◦ The file owner specifies what the members of the group can do with the file Filesystem access control  $ls –l filename -rw------- 1 yliu csstaff 4529 Jul 15 2010 todo  the file todo is owned by the user yliu and the group csstaff  Leeers and dashes in the first column symbolize file permissions ◦ There are 9 permission bits ◦ Control who can read, write, and execute the file content ◦ Also 3 other bits for executable programs (ignored for now) Determining file ownerships  The 12 bits are called ―mode bits‖. Can be changed using ―chmod‖ command  3 sets of permissions ◦ Owner of the file ◦ Group owners of the file ◦ Everyone else  Each set has three bits: – A read bit, a write bit, and an execute bit The permission bits  Each user fits into only one permission set ◦ Owner, group owner, or other, the most specific one  Permissions for a file ◦ Read: allow file open and read ◦ Write: allow file content modifica$on/trunca$on ◦ Execute: allow file to be executed  Permission for a directory ◦ Read: allow content lis$ng ◦ Write: allow file crea$on, dele$on, renaming ◦ Execute: allow to enter the directory but not lis$ng The permission bits------  Tradi$onal one ◦ simple, predictable, capable for most access control needs at the average site ◦ Supported by all variants, remains the default  Modern access control mechanisms ◦ Role-based access control (RBAC) ◦ SELinux: security-enhanced Linux ◦ POSIX capabili$es ◦ Access control lists (ACLs) Modern access control  useradd: add new user, associate with group, create home directory, set default shell, set initial password  userdel: remove existing user, delete home directory and files, edit associated groups, assuming no processes!  usermod: modify existing users, including initial group, home directory, user identification number  groupadd/groupdel/groupmod: functions for groups instead of users, assigns group identification numbers  passwd: modify or delete a password, users can modify their own password, root can modify any password  login: authenticate a username and password before allowing user access Access Commands  Every file has an owner and group. File access varies depending on whether you are the owner, belong to the group, or are neither.  Read, write, and execute privileges for each file are distinct for owner, group, and world. The latter defines privileges for users that are not owners and are not in the group.  A listing command shows the each of these protections, which can only be modified by the owner or the root user, as shown on the next page.  Also Linux stores a sticky bit for each directory, that tells who can rename or delete files. In addition there are SUID and SGID, which will be explained later.  Access bits via ls  ls -l: listing directory in long format  lrwxrwxrwx 1 applin fac 22 Sep 22 2014 Cheating -> CSU/Cheating drwxr-xr-x 13 applin fac 4096 Aug 21 16:57 Documents -rw------- 1 applin fac 395 Aug 30 15:47 monster Filesystem Protection  setuid and setgid ◦ Bits with octal value 4000 and 2000  Only losers memorize octal values  sticky bit ◦ If set, cannot delete or rename unless you are directory owner  Historical for regular files – ignored these days ◦ Bit with octal 1000  Features of an access control list (ACL)  Defines a list of permissions per object  Permission specifications for multiple users or groups  More complex systems have inheritance  More complex to administer and develop for  Can also apply to network file access  Linux ACL support  Linux can support ACL mode  Sits on top of the 9-bit (rwxrwxrwx) model  Not required for many administrative situations  ACL is disabled in most Linux systes by default  Turn on using mount –o acl option  Use the setfacl command to define permissions ACLS Chapter 4  Linux assigns user identifiers (UIDs) and group identifiers (GIDs) to processes.  When a child process is created, by default it inherits the identifiers from the parent process.  The login process launches the initial shell process with the UID and GID of the user that logged on, so commands launched by that user will have the same identifiers.  An exception is made if the setuid and setgid flags are set on the process.  In this case ownership of the process follows the ownership of the executable instead of the user.  $ ls –l /bin/passwd -rwsr—xr—x 1 root root 25000 Feb 8 2011 passwd Process Ownership  A special root account exists that represents the omnipotent administrative user, often called the superuser account, that can perform tasks that are restricted to other users:  Shutting down or rebooting the system (shutdown, reboot)  Setting the system or domain name  Changing the system date and time  Creating or deleting device files  Configuring network interfaces  Raising resource usage limits  Raising process priorities  Root Privileges Root Privileges  Several ways exist in which root privileges can be accessed, and a number of concerns should be taken into account when deciding which method to use:  Logging in to the root account (worst of all)  The su (switch user/substitute user/super user) command (bad)  The sudo command (best)  Operating from the root account gives unfettered access, but leaves no record of which operations are performed. Also can be extremely dangerous to always be root!  The su command is of limited duration, but doesn’t do any logging. ◦ Can be used to switch to a non-root user: su ct320  The sudo command is of limited duration, and does logging, thus making it easy to monitor system administration activities. (OK, who broke the C compiler!?) Root  Root account represents a single point of failure.  If compromised, the integrity of the whole system is violated, and there is not limit to the damage that can be inflicted.  There is no way to subdivide the special privileges of the root account, i.e. allow one administrator to manage accounts and another to mount devices.  Access control rules must be embedded in the code of individual commands and daemons, so modifying access behavior requires significant source code modification.  The security model is not strong enough for use on a network, since user and group identifiers can be hacked on systems to which an unprivileged user has access. Access Control Problems  Role Based Access Control (RBAC) ◦ Users are associated with roles, which in turn define access  Security-Enhanced Linux (SELinux) ◦ National Security Agency project  POSIX Capabilities ◦ Subdivides privileges of the root account  Access Control Lists (ACLs) ◦ A generalization of the user/group/other model  Pluggable Authentication Modules (PAM) ◦ Authentication framework  Kerberos: Cryptographic Authentication ◦ Authentication method Common Extensions