Lecture 4

Week 4
 Operating system security is itself paramount if we
are to secure the information it controls.
 In order to have a secure operating system it must
be supported by a suitable computer architecture,
and the implementation of the computer
architecture must of course itself be appropriately
engineered.
 If the underlying technology from which the
operating system is built and on which it is
supported is not secure, then one can have no
confidence in the security of the operating system
and of the information it maintains for the users.

2
 The operating system can be considered in
various ways:
an intermediary between the user software and the
hardware
an abstraction layer providing an idealized view of
the computer hardware
a virtual machine
a set of services

3
 What kinds of security policies should be
supported?
 What security services are required?
 Where are the boundaries of the system?
 Is it a distributed system?
 Are users distributed across time and space?
 Is there any concurrency involved?

4
 Supporting hardware
Is virtualization needed?
Is there fine enough access control in H/W?
Is there adequate control at H/W level?
Can H/W ensure O/S cannot be bypassed?
Can the H/W support the required resources?
Is the H/W scalable adequately?
Is there support for multiple levels of privilege?

5
 Computer System Environment
Is the computer system in a secure environment?
Are there adequate power, cooling, etc.?
Is it networked?
If so, is the networking environment secure?
Are there backup or redundant H/W resources?

6
 Resource security
 Service security
 Communication security
 Authentication of users
 Authentication of resources
 Privacy
 Anonymity
 Other security services

7
 Multiprogramming introduced the
need for protection

 Protected items:
 Memory
 Sharable I/O devices (e.g. disks)
 Serially reusable I/O devices (e.g.
printers)
 Sharable programs and sub procedures
 Sharable data

8
 Separation
 Keeping one user’s object separate from
other users

 Can occur in several ways (Rushby &

Randell):
 Physical separation
 Temporal separation
 Logical separation
 Cryptographic separation

9
 No protection
 Isolation
 Share all or share nothing
 Share via access limitation
 Share by capabilities
 Limit use of an object
 Granularity of protection!

10
 A system that prevents one process from
corrupting the memory of another
process running on the same computer
at the same time

 usually employs hardware (i.e. a Memory

management unit) and system software
to allocate distinct memory to different
processes and to handle exceptions
arising when a process tries to access
memory outside its bounds

11
 Fence
 Relocation
 Base/bound registers
 Tagged architecture
 Segmentation
 Paging
 Paging combined with
segmentation

12
 Introduced in single-user operating systems
 To prevent a faulty user program from destroying part
of the resident portion of the OS
 Implementation of fence:
 Fixed fence (fence was predefined memory address)
 A method to confine users to one side of a
boundary
 Enabling the OS to reside on one side and the user
to stay on the other.
 Predefined memory address (fixed)

 Fence register (used a hardware register)

 Contain address of the end of the OS
 Provide means of code relocation (The location of
fence could be changed)
 If (address > fence address), instruction was
executed
 If (address < fence address), error
13
Note:
1. Implementation very restrictive
2. OS could not grow beyond the fence boundary

14
15
Note:
1. An OS can be
protected from a
single user but fence
cannot protect one
user from another user
2. Has the ability of
relocate

16
 Process of taking a program written as if it:
 Begin at address 0
 Changing all addresses to reflect the actual address
at which the program is located

 How?
 By adding the a constant relocation factor to each
address of the program
Relocation factor is the starting address of the
memory assigned for the program

 Important in a multi-user environment

17
 Base register also known as Variable
fence register.
 All addresses are offset from base register
 Provide a lower bound (a starting address)
but not an upper bound.
 Upper bound:
 useful in knowing how much space is allotted
 Useful in checking for overflows into prohibited
areas

 To overcome the problem because of

not provide a upper bound:
 Add second register called Bounds register
(an upper address limit)

18
 Note:
1. Protects a program’s
Addresses Memory addresses
0 2. from modification by
another user
Operating 3. Outside users are protected
Base Register System from errors in any other
n user’s program
n+1 n+1
4. Base/bounds checking
guarantees only that each
User A address is inside the user’s
Bound Register Program Space address space
p
p
p+1
User
User B Program
q Program Space Space
q+1
User C
High Program Space

19
 Memory
Operating
Note: System
1. Not prevent all User Program
program errors Data Base User A Program
Space And Data
2. Limit the effect of
data User B Data Space Space
manipulating
User A Data Space
instructions to the Data Bound
data space
3. Has ability to split
a program into 2 User C Data Space
pieces (can be
relocated
Program Base User C Data Space
separately)
User B Data Space

Program Bounds
20
 To solve problem in base/bounds register
 Problem on contiguous nature
 Problem on all-or-nothing situation for sharing

 Using Tag Architecture, every word of machine memory has

one or more extra bits to identify the access rights to that
word
 Access bits can be set only by privileged (OS) instructions
 Bits are tested every time an instructions accesses that
location

21
 Problems with tagged architecture:
Code compatibility

Locked into convention despite low cost of

memory

22
 Tag Memory Word
R 0001
RW 0137
R 0099
X
Code: X
R = Read
RW = Read/Write R 4091
X = Execute-only RW 0002

23
 Two approaches that can be implemented
on top of a conventional machine structure
Segmentation
Paging

 Segmentation:
Involves the simple notion of dividing a
program into separate pieces
Each piece has a logical unity, showing a
relationship among all of its code or data
values

24
 Developed as a feasible means to produce the effect
of the equivalent of an unbounded number of
base/bounds registers.
Allows a program to be divided into many pieces
having different access rights

 Segment properties:
Each segment has a unique name
A code or data item within a segment is addressed
as the pair <name, offset>
The <,name, offset> pair is adequate to access to
any data or instruction to which program should
have access
 Segment can be separately relocated
 OS maintains table mapping logical address to
physical

25
 The OS must maintain a table of segment
names and their true addresses in memory

 Processes:
1. A program generates an address of a form
<name, offset> (hiding of addresses)
2. The OS looks up name in the segment directory
and determines its real beginning memory
address
3. OS will add offset by giving the true memory
address of the code or data item to that
address
– This process called translation

26
 The hiding of addresses has 3 advantages for the
OS
 The OS can place any segment at any location or
move any segment to any location even after
the program begins to execute (move any
segment to any location)

 A segment can be removed from main memory

if it is not being used currently

 Every address reference passes through the OS

 Can check each one for protection
 A process can access a segment only if that segment
appears in that process’s segment-translation table

27
28
 Each address reference is checked for
protection

 Many different classes of data items can be

assigned different levels of protection

 Two or more users can share access to a

segment with potentially different access
rights

 A user cannot generate an address or access

to an unpermitted segment

29
 Segment names are inconvenient to encode in instructions

 The operating system’s lookup of the name in the table

can be slow

 Segments cause fragmentation of main memory because

they are varying sizes.

 Each memory access must be checked to ensure that

segment offset does not extend beyond end of segment
(cure - include segment size in table).

 If swapping is used then additional memory management

techniques must be employed

30
 The program is divided into equal-sized pieces called
pages and memory is divide into equal-sized units called
frames

 Each address in paging scheme is two-part object

<page, offset>

 Each address is translated:

The OS maintains a table of user page numbers and
their true addresses in memory
The page portion of every <page, offset> reference is
converted to a page frame address by a table lookup
The offset portion is added to the page frame address
to produce the real memory address of the object
referred to as <page, offset>

31
32
 Advantages of paging:
Each page is the same size thus
fragmentation is reduced
Addressing beyond a page is not a real
problem since a carry just refers to the next
page.

 Disadvantage of paging:
Loss of individual access rights since there is
not necessarily a relationship between lines of
code in a page (unlike program segmentation)

33
 To solve problems by paging method

 Break each segment into equal sized pages

 Gain advantage of segment permissions

coupled with reduction in fragmentation
offered by paging.

34
 IBM 390 family of mainframe systems - used
paged segmentation

 Multics OS – applied paging on top of

segmentation

 As the result:
Programmer could divide a program into logical
segments
Each segment was broken into fixed-size pages

 In Multics:
Segment name portion of an address was an
18-bit number with a 16-bit offset
The addresses broken into 1024-byte pages

35
36
 Retained the logical unity of the segment

 Permitted
differentiated protection for
the segments

 Disadvantage:
Added an additional layer of translation for
each address

37
 Memory
 File or data set on an auxiliary storage
device
 Program executing in the memory
 A directory of files
 A hardware device
 A data structure or an an operating
system table
 Instructions
 Passwords and user authentication
mechanism
 The protection mechanism itself
38
 Check every access

 Allow least privilege

 Verify acceptable usage

39
40
 Good structure
◦ able to express access control policies
◦ Able to check policy has been captured correctly
 Consists of
◦ Access control matrix (ACM)
◦ Capabilities
SUBJECT
OBJECT
◦ Permission mechanism
◦ Access control lists (ACL)
Bill.doc Edit.exe Fun.com
Alice - execute (execute, ACCESS
read) CONTROL
Bob (read, write) Execute (execute, MATRIX
read and
write)

Dr Rabiah Ahmad CASE UTM

INTERNATIONAL CAMPUS 3/7/2016 41
 An object
What about X (execution) right? And
R(emoval), U(pdate) etc.?

42
Object1: {{A: OWR}, {B: R}, {C: R}, {D: R}}
Object2: {{A: R}, {B: OWR}, {C: R}, {E: R}}
Object3: {{A: OWR}}
Object4: {{B: OWR}, {*: WR}}
Object5: {{B: OWR}, {E: R}}

 In most systems, subjects are grouped

according to certain criteria to reduce the
size of ACL presentation
Owner, group others in UNIX
User, group, compartment in Multics

43
Access control: sample coding

Coding of
access
control matrix

Command creates
files and gives the
creating subjects
ownership
privilege
 Access control: Relationship between access control
matrix, Access control lists and capabilities

Authorization table and access

control matrix capabilities

Access control lists

 A capability is a token which:
Gives the possessor certain rights to an
object
Must be unforgeable therefore the OS
holds all capabilities.
May grant transfer rights - something like
delegation of authority.
Each process executes in a given domain
which defines objects that are accessible to
that process.

46
Subject A:
{{1:OWR},{2:R},{3:OWR},{4:WR}}
Subject B:
{{1:R},{2:OWR},{4:OWR},{5:OWR}}
Subject C: {{1:R},{2:R},{4:WR}}
Subject D: {{1:D},{4:WR}}
Subject E: {{2:R},{4:WR},{5:R}}

 Issues:
 Unforgeability of capabilities
 Propagation of rights
 Domains
 Revocation

47
 ACL may be likened to a guard at the door
to an object/resource
 He checks whether the subject/user is on
the authorized list, and only then lets them
in
 Capabilities may be likened to door keys
 Objects/resources are protected by locks,
and only those with keys can get in
 Possession of a key that works is all that is
required

48
 ACLs and Capabilities appear to be
equivalent ways of expressing the
permissions described by the access matrix
 There are dynamic and operational
differences especially when considering
role-based security policies or when there
are dynamic changes in authorizations
 Capabilities have extra flexibility
 Hybrid schemes are possible

49
 Basic forms
All-none protection
Assumption - all users can be trusted
You have the password - you have complete
access
Group protection

 Single permissions
Password or other token
Temporary acquired permission

50
 Group Protection
 All authorized users are separated into groups.
 Group may consist of multiple users or single user.
 All members of the group can share.
 No user belongs to more than one group.
 User defines access to files he/she creates.
 Read/Write access to the group.
 Read/Write/execute/delete to his/herself.
 Read access to the rest of the world.

 Difficulties
 Group affiliation - Cannot belong to two groups.
 Multiple personalities - one user has multiple accounts.
 Limited sharing - can only share files within the group.

51
 Password
 A single password for every file.

 Shortfalls
 Loss - forgotten.
 Disclosure - loose lips; requires reprotecting the file.
 Revocation - password must be changed and all
legitimate users must be notified.

 Temporary Acquired Permission

 When executing a file you temporarily acquire the
rights of the file's owner.
 Accomplished by the Set userid (suid) in UNIX.
 Password programs - access to sensitive files are
carefully monitored by the executing program.

52
 Authentication is a process used to verify
transmitted data in a computing environment

 In authentication, the claimants should present

some kind of principal identity to prove
themselves

 Can be divided into two contexts:

Entity authentication (EA)
Data origin authentication (OA)

53
 Canbe based on a number of different
characteristics:
 Something the user knows (e.g. password)
 Something the user possesses (e.g. smart card)
 Something the user is (e.g. biometric
authentication)

A combination of the above

54
 Spoofing
 Swindling of information by crackers or hackers.

 Eavesdropping
 Tapping into the communication line to grab
information transferred between two computers.

 Modification
 Altering or changing information

 Masquerading
 Having a fake interface of the system to get
information from user input such as passwords
and user name

55
 Definition:
Password is a character of strings used to
authenticate an identity or a user

 Process:
When a user submits a valid password, the
system will perform a password verification
process, and when the password has been
approved, a degree of trust between the
system and the user can be achieved
Get-and-compare concept

56
 Conventional encryption.
Enter password.
Decrypt stored password from table.
Compare passwords.

 One way cipher.

Enter password.
Encrypt password.
Compare to encrypted password.

 Salted passwords (UNIX).

Salt is added to the password.
Used with one-way cipher.
Avoids possible duplicate passwords in table.

57
 Display
standard prompt and capture
password.

 Leaveterminal unattended and wait for

victim.

 Replace OS's standard program.

 Challenge and Response Systems
Uses static mathematical function.
System provides argument to function.
User provides result of function.

58
 The first security models were designed to meet
the needs of multi-level security.
 Prior to 1960s, the regulations did not allow
classified information on a system that also
allowed uncleared users.
 The underlying security policy for the U.S. DoD is
commonly referred to as a military security policy.

59
 Rules
◦ Simple security policy
 A process running at level k can read only objects that
are at its level or a lower level of security.
 Read-down
 A commander can see the documents his lieutenant
wrote.
◦ The * property
 A process running at level k can only write objects at
its level or higher
 Write-up
 A lieutenant can modify or update the information
that his superiors can see.

60
 Operating system basic security is closely
integrated to general OS design

 Beforeany fine grained access control is

possible, users must be reliably
authenticated

A number of schemes are available for user

authentication

61