Least privilege, access control, operating system security

1. Least Privilege, Access Control,
Operating System Security

2. Contents
• Principle of least privilege
• Access control concepts
• Operating system Mechanics
• Unix Security in brief
• Windows Security in brief
• Qmail
• Chromium
• Android Security in brief

3. Security
• Security, in information technology (IT), is the defense of digital
information and IT assets against internal and external, malicious and
accidental threats. This defense includes detection, prevention and
response to threats through the use of security policies, software tools
and IT service
• In short, it means the protection of assets

4. Security Goals (general)
• Confidentiality (Secrecy or Privacy) – Resources can be accessed only
by authorized parties
• Integrity – Resources can be modified only by authorized parties
• Availability – Resources should be accessible to authorized parties at
appropriate times.

5. CIA Triad
Confidentiality Integrity
Availability
Security

6. Principle of Least Privilege[1]
• An ideal security goal would be the ability to limit a process to only
the set of operations necessary for its execution
• The principle of least privilege is an important concept in computer
security, promoting minimal user profile privileges on computers,
based on user’s job necessities.
• It can also be applied to processes on the computer
• Each system component or process should have the least authority
necessary to perform its duties.

7. Benefits
• Better system stability. When code is limited in the scope of changes it
can make to a system, it is easier to test its possible actions and
interactions with other applications
• Better system security. When code is limited in the system-wide
actions it may perform, vulnerabilities in one application cannot be
used to exploit the rest of the machine
• Ease of deployment. In general, the fewer privileges an application
requires the easier it is to deploy within a larger environment

8. Access Control Concepts[2][3]
• Access control, in the context of information security, permits an
organization’s management to define and control which systems or
resources a user has access to, and what that user can do on that
system or resource.
• More formally, access control is the ability to permit or deny the use of
an object (a passive entity, such as a system or file) by a subject (an
active entity, such as an individual or process)
• Such use is normally defined through sets of rules or permissions
(such as Read, Write, Execute, List, Change, and Delete) and
combinations of various security mechanisms (such as administrative,
technical, and physical controls)

9. Control of Access to General Objects
• Examples of kinds of objects for which protection is desirable
• Memory
• File
• Process
• Directory of files
• Stack
• Instructions, especially privileged instructions
• Passwords and the user authentication mechanism

10. Control of Access to General Objects
• These are the complementary goals in protecting objects.
• Check every access
• A previously authorized user intends to access an object. It is not necessary that the user
should retain indefinite access to the object.
• Enforce least privilege
• A subject should have access to the smallest number of objects necessary to perform some
task

11. Access Control
• An access enforcement mechanism authorizes requests from multiple
subjects (e.g. users, processes, etc.) to perform operations (e.g., read,
write, etc.) on objects (e.g., files, sockets, etc.)
• Two fundamental concepts of access control:
• A protection system that defines the access control specification
• A reference monitor that is the system’s access enforcement mechanism that
enforces this specification

12. Protection Systems
• A protection system consists of a protection state, which describes the
operations that system subjects can perform on system objects, and a
set of protection state operations, which enable modification of that
state
• A protection system enables the definition and management of a
protection state.
• A protection state consists of the specific system subjects, the specific
system objects, and the operations that those subjects can perform on
those objects.
• A protection system also defines protection state operations that
enable a protection state to be modified.

13. Protection Systems
• The access matrix is used to define the protection domain of a process
• A protection domain specifies the set of resources (objects) that a
process can access and the operations that the process may use to
access such resources
• By examining the rows in the access matrix, one can see all the
operations that a subject is authorized to perform on system resources

14. Mandatory Protection Systems
• This access matrix model presents a problem for secure systems:
untrusted processes can tamper with the protection system
• Using protection state operations, untrusted user processes can modify
the access matrix by adding new subjects, objects, or operations
assigned to cells
• Suppose Process 1 has ownership over File 1. It can then grant any
other process read or write (or potentially even ownership) access over
File 1 (Please see figure in previous slide)
• A protection system that permits untrusted processes to modify the
protection state is called a discretionary access control (DAC) system

15. Mandatory Protection Systems
• A mandatory protection system is a protection system that can only be
modified by trusted administrators via trusted software, consisting of
the following state representations
• A mandatory protection state is a protection state where subjects and objects
are represented by labels where the state describes the operations that subject
labels may take upon object labels
• A labeling state for mapping processes and system resource objects to labels
• A transition state that describes the legal ways that processes and system
resource objects maybe relabeled.

16. Mandatory Protection Systems
• The protection state is defined in terms of labels and is immutable.
The immutable labeling state and transition state enable the
definition and management of labels for system subjects and
objects.

17. Discretionary Access Control (DAC)
• In discretionary access control (DAC), the owner of the object
specifies which subjects can access the object. This model is called
discretionary because the control of access is based on the discretion
of the owner.
• Most operating systems such as all Windows, Linux, and Macintosh
and most flavors of Unix are based on DAC models
• In these operating systems, when you create a file, you decide what
access privileges you want to give to other users; when they access
your file, the operating system will make the access control decision
based on the access privileges you created

18. Mandatory Access Control (MAC)
• In mandatory access control (MAC), the system (and not the users)
specifies which subjects can access specific data objects
• The MAC model is based on security labels. Subjects are given a
security clearance (secret, top secret, confidential, etc.), and data
objects are given a security classification (secret, top secret,
confidential, etc.). The clearance and classification data are stored in
the security labels, which are bound to the specific subjects and
objects
• The MAC model is usually used in environments where
confidentiality is of utmost importance, such as a military institution

19. Role Based Access Control (RBAC)
• Role-based access control (RBAC) is a method of regulating based on
the roles of individual users within a system
• Roles are defined according to job competency, authority, and
responsibility within the system
• When properly implemented, RBAC enables users to carry out a wide
range of authorized tasks by dynamically regulating their actions
according to flexible functions, relationships, and constraints
• In RBAC, roles can be easily created, changed, or discontinued as the
needs of the system evolve, without having to individually update the
privileges for every user.

20. Reference Monitors
• A reference monitor is the classical access enforcement mechanism.
• We identify three distinct components of a reference monitor:
• (1) its interface
• (2) its authorization module
• (3) its policy store
• A reference monitor is a component that authorizes access requests at
the reference monitor interface defined by individual hooks that
invoke the reference monitor’s authorization module to submit an
authorization query to the policy store. The policy store answers
authorization queries, labeling queries, and label transition queries
using the corresponding states

21. Reference Monitors
• The following presents a
generalized view of a
reference monitor. It takes a
request as input, and returns
a binary response indicating
whether the request is
authorized by the reference
monitor’s access control
policy.

22. Reference Monitor Interface
• The reference monitor interface defines where protection system
queries are made to the reference monitor.
• In particular, it ensures that all security-sensitive operations are
authorized by the access enforcement mechanism.
• A security-sensitive operation means an operation on a particular
object (e.g.,file,socket, etc.) whose execution may violate the system’s
security requirements.
• For example, an operating system implements file access operations
that would allow one user to read another’s secret data (e.g., private
key) if not controlled by the operating system

23. Authorization Module
• The core of the reference monitor is its authorization module. The
authorization module takes interface’s inputs (e.g., process identity,
object references, and system call name), and converts these to a query
for the reference monitor’s policy store
• The challenge for the authorization module is to map the process
identity to a subject label, the object references to an object label, and
determine the actual operations to authorize (e.g., there may be
multiple operations per interface)
• The protection system determines the choices of labels and operations,
but the authorization module must develop a means for performing the
mapping to execute the “right” query

24. The Policy Store
• The policy store is a database for the protection state, labeling state,
and transition state. An authorization query from the authorization
module is answered by the policy store.
• These queries are of the form {subject_label, object_label,
operation_set} and return a binary authorization reply. Labeling
queries are of the form {subject_label, resource} where the
combination of the subject and, optionally, some system resource
attributes determine the resultant resource label returned by the query.
• The resource may be either be an active entity (e.g., a process) or a
passive object (e.g., a file). Some systems also execute queries to
authorize transitions as well.

25. File System Security
• A file system is a method for storing and organizing computer files
and the data they contain to make it easy to find and access them.
• File systems exist on hard drives, pen drives, cds, dvds and any other
form of data storage medium
• Most data storage devices have an array of fixed-size blocks,
sometimes called sectors, and the file system is in charge of organizing
these sectors into files and directories.
• It is also in charge of indexing the media so it knows where and what
each file is

26. Types of File Systems
• Disk file systems – FAT (File Allocation Table), NTFS, HFS
(Hierarchical File System), ext2, ext3, ISO9660 and UDF
• FAT(FAT12, FAT16, FAT32), and especially NTFS are primarily used
on Windows operating systems.
• FAT is also the standard file system for floppy drives and is still used today
• HFS is used by Mac OS, and ext2, ext3 are used on various Linux
operating systems
• ISO9660 and UDF are used on optical media

27. How does the file system handle security?
• The file system is crucial to data integrity. Main method of protection
is through access control
• Accessing file system operations (ex. modifying or deleting a file) are
controlled through access control lists or capabilities
• Capabilities are more secure so they tend to be used by operating systems on
file systems like NTFS or ext3.
• Secondary method of protection is through the use of backup and
recovery systems

28. Access Control in Files
• Access Control plays a huge part in file system security
• System should only allow access to files that the user is permitted to access
• Almost all major file systems support ACLs or capabilities in order to
prevent malicious activity on the file system
• Depending on the users rights they can be allowed to read, write and/or
execute and object.
• In some file systems schemes only certain users are allowed to alter
the ACL on a file or see if a file even exists.
• Ultimately less the user has access to less can go wrong and the integrity can
be more guaranteed

29. Access Lists (ACL)
• There is one ACL for each object
• ACL shows all subjects who should have access to the object and what
their access is.
• One access control list per object; a directory is created for each subject.
• ACL of a file is a representation of its access control information
• Contains the non-null entries that the file’s column would have contained in
the ACM

30. Access Lists (ACL)

31. Access Control Matrix
• An access control matrix is a protection structure that provides
efficient access to:
• Access privileges of users to various files
• Access control information for files
• It is a table in which each row represents a subject, each column
represents an object, and each entry is the set of access rights for that
subject to that object.

32. Access Control Matrix

33. Operating System Mechanisms[3][4]
• An operating system (OS) is the program that, after being initially
loaded into the computer by a boot program, manages all the other
programs in a computer. The other programs are called applications or
application programs.
• Protection and security problem - ensure that each object is accessed
correctly and only by those processes of authorized users that are
allowed to do
• OS designer faces challenge of creating a protection scheme that
cannot be bypassed by any software that may be created in the future

34. Secure Operating System Definition
• A secure operating system is an operating system where its access
enforcement satisfies the reference monitor concept. The reference
monitor concept defines the necessary and sufficient properties of any
system that securely enforces a mandatory protection system,
consisting of three guarantees:
• Complete Mediation: The system ensures that its access enforcement
mechanism mediates all security-sensitive operations.
• Tamperproof: The system ensures that its access enforcement mechanism,
including its protection system, cannot be modified by untrusted processes.
• Verifiable: The access enforcement mechanism, including its protection
system, “must be small enough to be subject to analysis and tests, the
completeness of which can be assured” That is, we must be able to prove that
the system enforces its security goals correctly.

35. Security methods of OS - Classification
• Separation between the different modules of the same system is a key
aspect
• It can be done in the following ways:
• Physical Separation: Each module / process is given a separate physical
terminal or device
• Temporal Separation: The processes may be executed at different times
without any overlap
• Logical Separation: The operating system abstracts the inner working of the
system where the end user is given only a separate logical workspace to
execute
• Cryptographic Separation: Cryptographic techniques are applied to conceal
data

36. Security Kernel
• Responsible for implementing the security mechanisms of the entire
operating system
• Provides the security interfaces among the hardware, the operating
system, and the other parts of the computing system.
• It may degrade system performance or may increase the size of the
file.
• A security kernel is defined as the hardware and software necessary to
realize the reference monitor abstraction
• The first security kernel was prototyped by MITRE in 1974

37. Security Kernel
• Responsible for implementing the security mechanisms of the entire
operating system
• Provides the security interfaces among the hardware, the operating
system, and the other parts of the computing system.
• It may degrade system performance or may increase the size of the
file.
• A security kernel is defined as the hardware and software necessary to
realize the reference monitor abstraction
• The first security kernel was prototyped by MITRE in 1974

38. UNIX Security in brief[4]
• UNIX is a multiuser operating system developed by Dennis Ritchie
and Ken Thompson at AT&T Bell Labs
• UNIX adopted several of the Multics security features, such as
password storage, protection ring usage, access control lists, etc.
• A running UNIX system consists of an operating system kernel and
many processes each running a program
• A protection ring boundary isolates the UNIX kernel from the
processes.
• Each process has its own address space, that defines the memory
addresses that it can access.

39. UNIX Security in brief
• Modern UNIX systems define address spaces primarily in terms of the
set of memory pages that they can access
• UNIX uses the concept of a file for all persistent system objects, such
as secondary storage, I/O devices, network, and interprocess
communication.
• A UNIX process is associated with an identity, based on the user
associated with the process, and access to files is limited by the
process’s identity.
• UNIX security aims to protect users from each other and the system’s
trusted computing base (TCB) from all users.

40. UNIX Security in brief
• Informally, the UNIX TCB consists of the kernel and several
processes that run with the identity of the privileged user,root or
superuser.
• These root processes provide a variety of services, including system
boot, user authentication, administration, network services, etc.
• Both the kernel and root processes have full system access.
• All other processes have limited access based on their associated
user’s identity.

41. Windows Security in brief[4]
• The history of the Microsoft Windows operating system goes back to
the introduction of MS-DOS, which was the original operating system
for IBM personal computers introduced in 1981
• The Windows 2000 protection system, like the UNIX protection
system, provides a discretionary access control model for managing
protection state, object labeling, and protection domain transitions.
The two protection systems manly differ in terms of flexibility (e.g.,
the Windows system is extensible) and expressive power (e.g., the
Windows system enables the description of a wider variety of
policies).

42. Windows Security in brief
• When we compare the Windows protection system to the definition of
a secure protection system, it is found that improvements in flexibility
and expressive power actually make the system more difficult to
secure
• Specifically, the Windows protection system differs from UNIX
mainly in the variety of its objects and operations and the additional
flexibility it provides for assigning them to subjects
• Subjects in Windows are similar to subjects in UNIX. In Windows,
each process is assigned a token that describes the process’s identity.
• A Windows identity is still associated with a single user identity, but a
process token for that user may contain any combination of rights.

43. Windows Security in brief
• Unlike UNIX, Windows objects can belong to a number of different
data types besides files
• Applications may define new data types, and add them to the active
directory, the hierarchical name space for all objects known to the
system
• From an access control perspective, object types are defined by their
set of operations
• The other major difference between a Windows and UNIX protection
state is that Windows supports arbitrary access control lists (ACLs)
rather than the limited mode bits approach of UNIX

44. Qmail
• qmail is a mail transfer agent (MTA) that runs on Unix. It was written,
starting December 1995, by Daniel J. Bernstein as a more secure
replacement for the popular Sendmail program
• When first published, qmail was the first security-aware mail transport
agent; since then, other security-aware MTAs have been published.
• When it was released, qmail was significantly faster than Sendmail,
particularly for bulk mail tasks such as mailing list servers
• At the time of qmail's introduction, Sendmail configuration was
notoriously complex, while qmail was simple to configure and deploy.

45. Chromium
• Chromium is an open-source Web browser project started by Google,
to provide the source code for the proprietary Google Chrome browse
• The two browsers share the majority of code and features, though
there are some minor differences in features and logos, and they have
different licensing
• It is possible to download the source code and build it manually on
many platforms
• The Google-authored portion of Chromium is released under the BSD
license

46. Android
• Android is a mobile operating system developed by Google, based on
a modified version of the Linux kernel and other open source software
and designed primarily for touchscreen mobile devices such as
smartphones and tablets
• Android's default user interface is mainly based on direct
manipulation, using touch inputs that loosely correspond to real-world
actions, like swiping, tapping, pinching, and reverse pinching to
manipulate on-screen objects, along with a virtual keyboard

47. Android Security in brief[5]
• Android applications run in a sandbox, an isolated area of the system
that does not have access to the rest of the system's resources, unless
access permissions are explicitly granted by the user when the
application is installed
• Android uses Security-Enhanced Linux (SELinux) to apply access
control policies and establish mandatory access control (mac) on
processes
• Android 2.2 and later provide the Android Device Administration API,
which provides device administration features at the system level

48. Android Security in brief
• As the base for a mobile computing environment, the Linux kernel
provides Android with several key security features, including:
• A user-based permissions model
• Process isolation
• Extensible mechanism for secure IPC
• The ability to remove unnecessary and potentially insecure parts of the kernel

49. Android Security in brief
• As a multiuser operating system, a fundamental security objective of
the Linux kernel is to isolate user resources from one another. The
Linux security philosophy is to protect user resources from one
another. Thus, Linux:
• Prevents user A from reading user B's files
• Ensures that user A does not exhaust user B's memory
• Ensures that user A does not exhaust user B's CPU resources
• Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
Bluetooth)

50. Android Security in brief
• System Partition and Safe Mode
• The system partition contains Android's kernel as well as the operating system
libraries, application runtime, application framework, and applications. This
partition is set to read-only. When a user boots the device into Safe Mode,
third-party applications may be launched manually by the device owner but are
not launched by default
• Filesystem Permissions
• In a UNIX-style environment, filesystem permissions ensure that one user
cannot alter or read another user's files. In the case of Android, each
application runs as its own user. Unless the developer explicitly shares files
with other applications, files created by one application cannot be read or
altered by another application

51. Android Security in brief
• Security-Enhanced Linux
• Android uses Security-Enhanced Linux (SELinux) to apply access control
policies and establish mandatory access control (mac) on processes
• Verified boot
• Android 6.0 and later supports verified boot and device-mapper-verity.
Verified boot guarantees the integrity of the device software starting from a
hardware root of trust up to the system partition. During boot, each stage
cryptographically verifies the integrity and authenticity of the next stage
before executing it
• Android 7.0 and later supports strictly enforced verified boot, which means
compromised devices cannot boot

52. References
[1] https://kb.iu.edu/d/amsv
[2] Charles P. Pfleeger, Shari Lawrence Pfleeger, Analysing Computer
Security, 4th Edition, ISBN: 9780132390774, Prentice Hall
[3] http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch2.pdf
[4] http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch4.pdf
[5] https://source.android.com/security/overview/kernel-security