Linux can support thousands of users on a single system
Each user has their own home directory, their password and configuration files for e.g. their desktop
Files belong to users, so that a user has access to their own files
Users can also belong to groups, which may give them access to additional resources
A special user is "root" or "system supervisor" who has access
to
Each user has a password, which is stored in encrypted form only - never stored in plain text
Users have to login using their password
The password can be set to time-out after a period
Some user accounts can be set to "no login" so that you can never login as them
A user can create, write, read, delete or execute files
A file can be read, written or executed, depending on permissions
A directory can allow creation or deletion of filenames (refer back to filesystems: data is manipulated by the inodes, file names by directories)
Any file has an owner, a group and "anyone else"
For each of these is the set of three read, write, execute permissions
A long listing ls -l will show permissions
Example: -rw-r--r-x means read+write by user, read by group, read+execute by all
Use chmod permission files
The mode can be absolute e.g. chmod u=rwx,o=r tmp
The mode can be given in octal (4=read, 2=write, 1=execute)
chmod 711 tmp
The mode can be relative, to add or subtract permissions
chmod u+rx,g-rw tmp
umask is an internal bash command
It sets the mask for all files you create with that shell or its children
If it is given a symbolic argument, it sets the mode for
new files e.g. umask u=rwx,g=rx,o=rx
sets rx for all, w for user
If is given an octal argument it umask 022
Directories are files, and so can have read, write and execute permissions set for user, group and other
They are also
A directory is a special file containing names and inodes of the files "in" the directory. So
If read permission is set, you can read the names
in the directory. So ls can work okay
If write permission is set, then you can write changes to the directory i.e. you can remove files, add files or change their names
(Special case) If execute is set, then you can
cd to the directory, or access a file
in the directory if you know its name
So drwxr-x--x means the user can do anything,
group can do ls and access a file,
others cannot ls but can access the file
if they know its name
The command chown new-owner files...
will change the ownership of a file
Only root can change ownership!
To change all files in a directory chown -R new-owner dir
It can also change the group of a file
Each shell has a real and an effective user id, which are usually equal
You can change your effective user id to that of another user
su fred starts a new shell with user id fred.
ctrl-D terminates the shell and drops
you back to yourself
su with no arguments makes you root
If you are root, you don't need a password to use su; if you are not root, you need the other user's password
Ubuntu etc don't allow you to su to root
su changes user id for a session
sudo changes user id for one command e.g.
sudo rm -rf / will attempt to become root
and remove all files from the file system
What you can do by sudo depends on permissions set in
/etc/sudoers
You don't need to know the other person's password to use sudo - the sudoers file controls possible actions
By default, Fedora doesn't allow an ordinary uer to
sudo
to root as they will not be in the sudoers file
if you have an executable file that you own, you can let
others run your command
e.g. the command at runs commands at a later time,
so has access to the scheduler.
To run this, you have to become root in order to access the
scheduler
If a file has the setuid bit set, then when you execute the command, your user id becomes that of the owner of the file
Typically, you make a file setuid by chmod 4711 file
A typical long listing for e.g. the password command is
-rwsr-xr-x 1 root root 32988 2008-12-08 20:17 passwd
The file /etc/passwd contains information
about each user in the form
login-name:password:user-id:group-id:user-name:home-dir:shell
e.g.
newmarch:x:1000:1000:Jan Newmarch:/home/newmarch:/bin/bash
This file is world-readable
Any user can find out the login names of all other users
The shell is usually /bin/bash or
/bin/sh.
If the shell is /bin/false
or /usr/sbin/nologin then that user cannot
log in
As system supervisor, you can set any command you want as
someone's shell e.g.
/bin/rbash is a restricted shell that limits
what user can do
The password file used to contain the actual passwords, in encrypted form
This allowed other users to try encrypting dictionary words and testing them against the encrypted password
Programs like crack made it even easier
Passwords are now kept in /etc/shadow
which can only be read by root
Use the passwd command
Root can change other people's passwords
Tasks are
Choose a new user id, and create an entry in the password file
Create an entry in the shadow password file, with their new password
Create a home directory for the user, and change its ownership
Copy configuration files for a typical user to their home, and change ownership
...or use a command like adduser or
useradd which does all that for you
Block them from logging in by changing their login
shell to /bin/false
Remove them entirely from the system by removing them from the password and shadow files, and deleting their home directory
You also need to clean places like the mail and print queue
directories (/var/mail and /var/spool
... ir use a command like userdel
Root is too powerful: the root user has access to
if an application (especially a server) can be broken into then it can read all public files and read/write all its own files
One way of reducing risk is to run server processes under special user ids (e.g. Apache runs as user www-data)
This is crude, and anyway isn't used by all server processes: sshd, cupsd and bluetoothd all run under user root
Users can do anything to their own files, including deleting files that act as audit trails for possibly illegal activities
The command chroot can limit a command
to a view of a subtree of the filesystem
Containers such as Docker can run an application in a totally isolated framework - lightweight virtualisation
Actors (users) can play roles (called protection domains) and perform actions on objects (files)
Ideally, the action of any actor on any object can be specified
You specify which domains an actor belongs to: e.g. Jan belongs to domain with user "j.newmarch" and group "audio" (so he can access the audio device)
Each protection domain can do certain things to each object e.g. file 1 can be read by domain 1, read or written by domain 2, etc:
The Unix file permission system is a special simple case which doesn't use a fraction of the space of a general system
From http://searchenterpriselinux.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid39_gci1213434,00.html
Discretionary Access Controls (DAC) define basic access control policies to objects. These are set at the discretion of the owner of the objects. For example, user and group ownership or file and directory permissions.
Mandatory Access Controls (MAC) are system-controlled access control policies where the system dictates and controls the level of access to an object, even a user created one. The administrator doesn't allow a user to grant less restrictive access controls to that object.
Mandatory Access Controls are considerably 'safer' than discretionary controls, but they are harder to implement and often require considerable tweaking to ensure all applications function correctly.
The NSA (US National Security Agency) produced SE Linux, which has Mandatory Access Controls (MAC)
The SE Linux mechanisms are standard in Fedora
For individual users, SE Linux is extreme overkill
For business organisations, SE Linux offers safeguards needed to protect business activities
SE Linux adds "labels" to everything: files, processes, users
Labels are e.g.
"this file is of type Apache-file" (so that Apache-process will have rights to it)
"this process is of type Apache-process" (so that it will have rights to access Apache-file,
"this role is Apache-start" so that users in this role can start an Apache server having access to its files!
"this user can be in the Apache-start role" so that these users can start an Apache server
Most current Linux filesystems (ext2, ext3, ext4, etc) support labelling, except ResierFS
If you have the appropriate rights, then you can control whether SE Linux is in control
To turn SE Linux into enforcing mode
setenforce 1
To turn SE Linux into permissive mode
setenforce 0
Edit /etc/selinux/config and set "SELINUX=disabled"
See articles such as http://www.crypt.gen.nz/selinux/disable_selinux.html for why you shouldn't do this
SE Linux is difficult to set up and manage
Alternatives include AppArmor and Grsecurity
See Linux Kernel Security (SELinux vs AppArmor vs Grsecurity)
Linux can support multiple users
Users have access to files based on their roles as user, group or other
Access rights are read, write and execute
There are commands to change access rights, change user role
SE Linux takes these to a much more secure level