CT 320: Network and System Administra8on Fall 2014

CT
320: Network and System Administra8on

Fall 2014*
Dr. Indrajit Ray
Email: indrajit@cs.colostate.edu

Department of Computer Science
Colorado State University
Fort Collins, CO 80528, USA
* Thanks to Dr. James Walden, NKU and Russ Wakeeld, CSU for contents of these slides
Access Control & Rootly Powers
Topics
1. Access control principles
2.
3.
4.
5.
6.
Authoriza8on, access control and authen8ca8on

Discre8onary vs. mandatory vs. role-based access
control
Ownership of les and processes

Superuser
Passwords
Becoming root
Pseudo-users
Dr. Indrajit Ray, Computer Science Department CT 320 Network and Systems Administra8on, Fall 2014
Authoriza/on, Access Control & Authen/ca/on

who is trying to access a
protected resource?
Authentication
Access Control Models
Authorization
who should be allowed to
access which protected
resources?
Access Control
Architectures
Enforcement
how does the system
enforce the specied
authorization?
who should be allowed to

change the access?
Modern Access Control

Discre8onary access control
Tradi8onal UNIX le system model
Mandatory access control

Military and SELinux model
Role-based access control

Latest industry standard
Solaris & OpenSolaris, HP-UX, AIX
Discre/onary Access Control

Owner of an object decides which other users
are allowed to access the object
Users iden8ty, objects iden8ty and permissions
comprise the DAC policy
Users can be placed in groups and permission
assigned to groups
Mandatory Access Control

When a system mechanism controls access to
an object and an individual user cannot alter
that access, the control is mandatory access
control
Why Mandatory Access Control?
File A
X : r, w
Y:
File B
X:w
Y : r, w
read
Program
Goodies
Trojan Horse
write
Why Mandatory Access Control
High
Two security levels
High, Low
Low < High
L(X) = High
L(Y) = Low
L(A) = High
L(B) = Low
File A
read
X : r, w
Y:
Program
Goodies
Trojan Horse
X
write
Low
File B
X:w
Y : r, w
Role-based Access Control

Role
Hierarchies
USERS
User-Role
Assignment
User-Session
Assignment
ROLES
PermissionRole
Assignment
Objects
Actions
Session-Role
Assignment
.....
SESSIONS
CONSTRAINTS
Tradi/onal UNIX Access Control

Non access control lists (ACL) based
Rudimentary DAC policies but messy
implementa8on
Existence of root or super-user
No single process / mechanism responsible for
access control
Certain system calls restricted to root
Other system calls involve both ownership
evalua8on and special provisions for root
File system has separate access control based on
access control bits
Ownership of Files
Files have an owner
Owner is a single user
Iden8ed by the UID
Files also have a group owner

Iden8ed by the GID
Found in /etc/group tradi8onally
More commonly in NIS or LDAP these days
UID (GID)
Every user (group) has unique UID
Mapped to user (group) in /etc/passwd (/etc/
group) le
Specic to the system dened
Text names not used by system
Process Ownership
Processes are les in execu8on
Processes can be executed by the owner of the
le or can run as another user
real UID (used for accoun8ng purposes)
eec8ve UID (used for determina8on of access
permissions)
setUID (setGID) bit for le
If set, allows le to be executed with elevated
permissions typically that of another user or the
the root
setUID (setGID) bit

If set on a (executable) le and a user who is
not the owner of the le executes it
Then kernel changes the eec8ve UID (GID) of
process to that of the owner during execu8on
The executor of the le gets privileges of the owner
for the execu8on period
Best example passwd program
Superuser or Root
A special root account exists that represents
the omnipotent administra8ve user, oien
called the superuser account, that has all rights
or permissions to all les and programs
Superuser or Root
UID of zero (0)
Performs privileged opera8ons
Crea8ng device les
Sejng system clock
Raising resource levels
Sejng systems hostname
Conguring network interfaces
Opening privileged network ports (below 1024)
Shujng down the system
Change its own UID/GID
Root vs. Admin User

Root is an actual user with user-id 0. Admin is a
collec8on of privileges assigned to one or more
users that allow them to perform tasks reserved
for the root
Root can do anything, without further
authen8ca8on
Source of concern
An admin user does not necessarily have all the

privileges that the root user has
The admin user has the ability to ask for privilege
escala8on in order to perform some of the tasks that
normally only the root user can
The admin user needs to authen8cate before they can
perform such tasks
Passwords
Commonly used method for authen8ca8on
For each user, system stores in a password le
the tuple <User name, F(password)>
F is some one-way transforma8on
F(password) is easy to compute
From F(password), password is dicult to
compute
When a user enters the password, system

computes F(password). A match provides proof
of iden8ty
Simple Password Scheme
Choice of Passwords
Suppose passwords can be from 1 to 8
characters in length
Lower case English alphabets used
Possible choices for passwords = 261 + 262 +

+ 268 = 1.5 x 1012
At the rate of 1 password per millisecond it will
take 150 years to test all passwords
Probable Passwords
In a Bell Labs study (Morris & Thompson 1979),
3,289 passwords were examined
15 single ASCII characters

72 two ASCII characters
464 three ASCII characters
477 four alphanumeric characters
706 ve lesers (all lower or all upper case)
605 six lesers all lower case
492 weak passwords (dic8onary words spelled
backwards, rst names, last names etc)
Summary: 2831 passwords (86%) were weak, that

is they were too easily predictable, or were too
short
Simple AOack on Passwords

Create a dic8onary of common words and
names and their simple transforma8ons
For example: indrajit jndaitr
Use these to guess the password
Another Simple AOack (F is known)
Unix Password Model

Designed by Bob Morris and Ken Thomson to
encrypt passwords in Unix
Uses an extended version of the DES
cryptographic algorithm for the password
func8on F
User password and a random value called salt
is used as encryp8on key
Process is repeated 25 8mes
The ith encrypted block is used as input for the (i
+ 1)th round
Unix Crypt Algorithm
Password Salt
Salt is used to make the previous asacks a lisle
bit more dicult
Salt is a 12 bit number between 0 and 4095
It is derived form the system clock and the process
iden8er
Rather than compu8ng f(password), system
computes f(password + salt) which is stored in
password le
With salt, the same password can result in 4096
dierent stored password values
Linux Passwords
Linux uses more secure cryptographic
techniques to encrypt the users password
MD5, Blowsh, Eksblowsh, SHA-256, SHA-512
Linux uses larger salt values
Shadow Password File

Password le /etc/passwd contains many
important informa8on not just encrypted
password
Needs to be world readable not just by root
Security concern
Do not keep encrypted password in /etc/

passwd but in /etc/shadow
Shadow le is readable only by root
Password Management
Educate users to make beser choices
Dicult if user popula8on is large or novice
Dene rules for good password selec8on and

ask users to follow them
Rules may serve as guidelines for asackers
Ask or force users to change their passwords

periodically
People do not like rules
Password Management
Force users to use machine generated random
passwords
Random passwords are dicult to memorize
Password generator may become known to the
asacker through analysis
Ac8vely asempt to break users password;

force users to change those that are broken
Screen password choices; if a choice is weak,
force user to make a dierent choice.
Root password
Choose wisely (imagine drinking from the
wrong chalice).
Guidelines:
At least eight characters in length
Not easily guessed
Boil down a phrase of shocking nonsense
Transform a phrase
Change regularly 8me and circumstances
Becoming root
su command
Subs8tute User iden8ty
sudo executes a single command

Creates log entry
Consults /etc/sudoers for authoriza8on
sudo asks for the users own password
Pseudo-users
bin owner of system commands
daemon owner of unprivileged system
soiware
nobody generic NFS user

CT 320: Network and System Administra8on Fall 2014

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CT 320: Network and System Administra8on Fall 2014

Încărcat de

Drepturi de autor:

Formate disponibile

CT

320: Network and System Administra8on

Access Control & Rootly Powers

Authoriza8on, access control and authen8ca8on

Ownership of les and processes

Authoriza/on, Access Control & Authen/ca/on

Access Control Models

who should be allowed to

Modern Access Control

Mandatory access control

Role-based access control

Discre/onary Access Control

Mandatory Access Control

Why Mandatory Access Control?

Why Mandatory Access Control

Role-based Access Control

Tradi/onal UNIX Access Control

Files also have a group owner

setUID (setGID) bit

Best example passwd program

Root vs. Admin User

An admin user does not necessarily have all the

When a user enters the password, system

Simple Password Scheme

Possible choices for passwords = 261 + 262 +

15 single ASCII characters

Summary: 2831 passwords (86%) were weak, that

Simple AOack on Passwords

Another Simple AOack (F is known)

Unix Password Model

Unix Crypt Algorithm

Linux uses larger salt values

Shadow Password File

Do not keep encrypted password in /etc/

Dene rules for good password selec8on and

Ask or force users to change their passwords

Ac8vely asempt to break users password;

Change regularly 8me and circumstances

sudo executes a single command

S-ar putea să vă placă și