See this page as a slide show
Access Control and Root
Original slides from Dr. James Walden at Northern Kentucky University.
- 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
- 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.
- 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.
- 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
file that stores passwords and maps usernames to user
identification numbers (UIDs).
- Linux allows shared access to certain resources through
/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.
Instead of keeping the encrypted passwords in the world-readable
/etc/passwd, they can be kept in
convert password/group files to & from shadow.
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
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
- 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
lrwxrwxrwx 1 ct320 class 12 Nov 22 2016 checkin -> checkin_prog
-rwx------ 1 ct320 class 405 Oct 14 19:58 checkin-file-checker
-rws--x--x 1 ct320 class 42040 Sep 6 2016 checkin_prog
-rwxr-xr-x 1 ct320 class 900 Dec 17 16:47 cls
-rwxr-xr-x 1 ct320 class 666 Dec 27 14:28 demo-script
-rwxr-xr-x 1 ct320 class 1019 Dec 27 14:30 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 10:50 grade-file-checker
-rwxr-xr-x 1 ct320 class 145 Dec 16 2015 grades
-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 585 Dec 26 13:41 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 979 Dec 27 14:41 playpen
-rwxr-xr-x 1 ct320 class 166 Dec 4 12:48 ruler
-rwxr-xr-x 1 ct320 class 1923 Dec 28 21:08 run
lrwxrwxrwx 1 ct320 class 34 Nov 22 2016 runner -> /s/parsons/d/fac/applin/bin/runner
-rwxr-xr-x 1 ct320 class 114 Aug 4 2014 save
drwx------ 2 ct320 class 4096 Aug 30 2015 tools
-rwxr-xr-x 1 ct320 class 1507228 Mar 4 2017 u
-rwxr-xr-x 1 ct320 class 294 Aug 4 2014 unold
-rwxr-xr-x 1 ct320 class 1078 Dec 9 17:40 wikicat
-rwxr-xr-x 1 ct320 class 171 Dec 27 14:30 wikidiff
-rwxr-xr-x 1 ct320 class 900 Dec 11 20:01 wikiedit
-rwxr-xr-x 1 ct320 class 1004 Dec 30 11:29 wikigrep
-rwxr-xr-x 1 ct320 class 2781 Dec 9 17:18 wikiupdate
-rwxr-xr-x 1 ct320 class 1354 Dec 18 12:52 wikiwhence
|d or l or -||rwx||rwx||rwx|
|directory or file||user||group||other|
- 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
cd into a directory
w for a directory means that you can change the directory,
not the files it contains. Changing the files underneath it depends
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.
chown applin Desktop
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.
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.
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
- Program: Used to mean “stuck” in memory — ignored these days
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 Jan 19 22:12 now
$ setfacl -m applin:r now
$ getfacl now
# file: now
# owner: ct320
# group: class
$ ls -l now
-rw-r-----+ 1 ct320 class 29 Jan 19 22:12 now
Linux can support ACL mode
- Sits on top of the 9-bit (
- 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
- 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 27832 Jan 29 2014 /bin/passwd
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
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)
su (switch user/substitute user/super user) command (bad)
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!
su command is of limited duration, but doesn’t do any logging.
- Can be used to switch to a non-root user:
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.
- 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.
- 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)
- Kerberos: Cryptographic Authentication