See this page as a slide show

Access Control and Root

CT320: Access

Original slides from Dr. James Walden at Northern Kentucky University.

Access Control

• 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.

https://en.wikipedia.org/wiki/Access_control

Control Mechanisms

• 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 Control 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.

System Access

• 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.

Shadow passwords

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.

Access Commands

• 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

Filesystem Protection

• 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

$ ls -l ~/bin
total 1748
lrwxrwxrwx 1 ct320 class      12 Nov 22  2016 checkin -> checkin_prog
-rwx------ 1 ct320 class    3915 Jun  1  2019 checkin-checker
-rwx------ 1 ct320 class     405 Oct 14  2017 checkin-file-checker
-rws--x--x 1 ct320 class   42040 Sep  6  2016 checkin_prog
-rwxr-xr-x 1 ct320 class    1339 Sep 23  2019 chit
-rwxr-xr-x 1 ct320 class     895 Sep 23  2019 cls
-rwx------ 1 ct320 class    2748 Dec 13  2019 code
-rwxr-xr-x 1 ct320 class     160 Jun 14  2014 cronedit
-rwxr-xr-x 1 ct320 class    3076 Oct 15  2019 curve
-rwxr-xr-x 1 ct320 class     666 Dec 27  2017 demo-script
-rwxr-xr-x 1 ct320 class    1306 Mar  7  2018 domoss
-rwxr-xr-x 1 ct320 class    1019 Dec 27  2017 e
lrwxrwxrwx 1 ct320 class      12 Nov 22  2016 grade -> checkin_prog
-rwxr-xr-x 1 ct320 class      59 May 30  2015 grade-busy
-rwx------ 1 ct320 class    3233 Sep 23  2017 grade-file-checker
-rwxr-xr-x 1 ct320 class     145 Dec 16  2015 grades
-rwxr-xr-x 1 ct320 class     834 Feb  8  2018 imv
-rwxr-xr-x 1 ct320 class      30 Sep 20  2015 l
-rwxr-xr-x 1 ct320 class      30 Sep 20  2015 ll
-rwxr-xr-x 1 ct320 class      30 Sep 20  2015 lsf
-rwx------ 1 ct320 class   10640 May 30  2015 moss
-rwxr-xr-x 1 ct320 class     112 Aug  4  2014 new
-rwxr-xr-x 1 ct320 class    1286 Jan 19  2020 note
-rwxr-xr-x 1 ct320 class     112 Aug  4  2014 old
-rwxr-xr-x 1 ct320 class      39 Apr 22  2013 p
lrwxrwxrwx 1 ct320 class      12 Nov 22  2016 peek -> checkin_prog
-rwxr-xr-x 1 ct320 class     789 Nov 17  2018 playpen
-rwxr-xr-x 1 ct320 class     276 Dec  4  2017 pwget
-rwxr-xr-x 1 ct320 class     166 Dec  4  2017 ruler
-rwxr-xr-x 1 ct320 class    1975 Jun 29  2018 run
-rwx------ 1 ct320 class      42 Jun 26  2018 runner
-rwxr-xr-x 1 ct320 class     114 Aug  4  2014 save
-rwxr--r-- 1 ct320 class    3150 Sep 29  2019 scores
-rwxr-xr-x 1 ct320 class    3404 Oct 15  2019 stats
drwx------ 2 ct320 class    4096 Aug 30  2015 tools
-rwxr-xr-x 1 ct320 class 1569660 Mar 10  2019 u
-rwxr-xr-x 1 ct320 class     294 Aug  4  2014 unold
-rwxrwxr-x 1 ct320 class    1036 Mar  7  2019 untar
-rwx------ 1 ct320 class    1078 Mar  7  2018 vman
-rwxr-xr-x 1 ct320 class    1078 Dec  9  2017 wikicat
-rwxr-xr-x 1 ct320 class     171 Dec 27  2017 wikidiff
-rwxr-xr-x 1 ct320 class     934 Jul 17  2019 wikiedit
-rwxr-xr-x 1 ct320 class    1004 Dec 30  2017 wikigrep
-rwxr-xr-x 1 ct320 class    2781 Dec  9  2017 wikiupdate
-rwxr-xr-x 1 ct320 class    1354 Dec 18  2017 wikiwhence

Access bits

• First column: d for a directory, l for a symbolic link, - for an ordinary file.
• Next three: permissions for the user (owner) of the file
• Next three: permissions for the group (similar people)
• Last three: permissions for others (everybody else)

The permissions can be different for user, group and other (everyone else). Typically, the user gets the most permissions, and others get very little.

Permissions: What do they mean?

• r: gives permission to read a a file or directory
• w: gives you permission to write a file or directory
• x: gives you permission to execute (run) a file or cd into a directory

Note that w for a directory means that you can change the directory, not the files it contains. Changing the files underneath it depends on their w bits.

Removing a file depends upon the w permission of containing directory, not any permissions of the file itself. Think of it as changing a relationship—you don’t need someone’s consent to unfriend them.

Protection Commands

• chown: change file owner

    chown applin Desktop

• chgrp: change file group

    chgrp fac Desktop

• chmod: change file privileges

    chmod 755 foo
    chmod ug+rw bar

Symbolic vs. octal

Some hackers consider it impressive to interpret the permission bits as an octal number. These are the same morons who think that memorizing the ASCII chart improves their dating prospects.

    chmod u=rw foo
    chmod go-w bar
    chmod g+r baz
    chmod g=r zip
    chmod a=rwx foo.*

That said, I will occasionally chmod 400 or chmod 666 a file, but I feel guilty when I do it.

Protection Commands

umask: set up default privileges:

• umask 077 — I trust nobody!
• umask u=rwx,go= — I trust nobody!
• umask u=rwx,g=r,o= — I trust my group, and nobody else.
• in ~/.bashrc

More on Permissions

• Must have execute to use a directory
• Permission bits stored in the parent’s directory
  • Delete and rename controlled by the parent’s permissions
• setuid and setgid
  • Bits with octal value 4000 and 2000
    • Only losers memorize octal values
• sticky bit
  • Bit with octal 1000
  • Directory: If set, cannot delete or rename unless you are directory owner
    • Think of /tmp.
  • Program: Used to mean “stuck” in memory — ignored these days

ACLS

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

$ date >now
$ chmod go= now
$ ls -l now
-rw------- 1 ct320 class 29 Nov 22 02:42 now
$ setfacl -m applin:r now
$ getfacl now
# file: now
# owner: ct320
# group: class
user::rw-
user:applin:r--
group::---
mask::r--
other::---

$ ls -l now
-rw-r-----+ 1 ct320 class 29 Nov 22 02:42 now

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

Process Ownership

• 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 33560 Apr 18  2022 /bin/passwd

Root Privileges

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

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)

Root

• 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!?)

Access Control Problems

• Root account represents a single point of failure. If compromised, the integrity of the whole system is violated, and there is no limit to the damage that can be inflicted.
  • It would be as if we’d elected an incompetent president!
• There’s no way to subdivide root privileges, e.g., allow one admin to manage accounts and another to mount devices.
  • OK, now there are capabilities.
• 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.

Common Extensions

• 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