You are on page 1of 23

CHAPTER 4

Designing Trusted Operating


Systems
Designing Trusted Operating Systems
An operating system is trusted if we have confidence that it provides these four
services consistently and effectively.
 Policy - every system can be described by its requirements: statements of what
the system should do and how it should do.
 Model - designers must be confident that the proposed system will meet its
requirements while protecting appropriate objects and relationships.
 Design - designers choose a means to implement it.
 Trust - trust in the system is rooted in two aspects:
o FEATURES - the operating system has all the necessary functionality needed to
enforce the expected security policy.
o ASSURANCE - the operating system has been implemented in such a way that we
have confidence it will enforce the security policy correctly and effectively.
What Is a Trusted System?
 Software is trusted software if we know that the code has been
rigorously developed and analysed, giving us reason to trust that
the code does what it is expected to do and nothing more.
Certain key characteristics:
o Functional correctness
o Enforcement of integrity
o Limited privilege
o Appropriate confidence level
Cont.…
Security professionals prefer to speak of trusted instead
of secure operating systems.
 Secure reflects a dichotomy: Something is either secure
or not secure.
 Trust is not a dichotomy; degrees of trust
Cont.….
Trusted System Design Elements
 Security considerations pervade the design and
structure of operating systems implies two things.
1. An operating system controls the interaction between subjects
and objects, so security must be considered in every aspect of
its design.
2. Because security appears in every part of an operating system,
its design and implementation cannot be left fuzzy or vague
until the rest of the system is working and being tested.
Cont.….
Several important design principles are quite particular to security and
essential for building a solid, trusted operating system.
 Least privilege: Each user and each program should operate by
using the fewest privileges possible.
 Economy of mechanism: The design of the protection system
should be small, simple, and straightforward. Such a protection
system can be carefully analyzed, exhaustively tested, perhaps
verified, and relied on.
 Open design: An open design is available for extensive public
scrutiny, thereby providing independent confirmation of the design
security.
Cont.….
 Complete mediation: Every access attempt must be
checked. Both direct access attempts (requests) and
attempts to circumvent the access checking mechanism
should be considered, and the mechanism should be
positioned so that it cannot be circumvented.
 Permission based: The default condition should be denial
of access. A conservative designer identifies the items
that should be accessible, rather than those that should
not.
Cont.…
Separation of privilege: Ideally, access to objects should
depend on more than one condition, such as user
authentication plus a cryptographic key. In this way, someone
who defeats one protection system will not have complete
access.
Least common mechanism: Shared objects provide potential
channels for information flow. Systems employing physical or
logical separation reduce the risk from sharing.
Ease of use: If a protection mechanism is easy to use, it is
unlikely to be avoided.
Security Features of Ordinary Operating Systems
Security Features of Ordinary Operating Systems
 User authentication.
 Memory protection.
 File and I/O device access control.
 Allocation and access control to general objects.
 Enforced sharing.
 Guaranteed fair service.
 Inter-process communication and synchronization.
 Protected operating system protection data.
Security Features of Trusted Operating Systems
Security Features of Trusted Operating Systems
 Identification and Authentication
o Trusted operating systems require secure identification of individuals,

and each individual must be uniquely identified.


 Mandatory and Discretionary Access Control
o Mandatory access control (MAC) means that access control policy

decisions are made beyond the control of the individual owner of an


object.
o Discretionary access control (DAC) leaves a certain amount of access

control to the discretion of the object's owner or to anyone else who is


authorized to control the object's access
Cont.…
 Object Reuse Protection
o To prevent object reuse leakage, operating systems clear
(that is, overwrite) all space to be reassigned before
allowing the next user to have access to it.
 Complete Mediation
o All accesses must be controlled.
 Trusted Path
o Want an unmistakable communication, called a trusted
path, to ensure that they are supplying protected
information only to a legitimate receiver.
Cont.…
 Accountability and Audit
o Accountability usually entails maintaining a log of security-
relevant events that have occurred, listing each event and
the person responsible for the addition, deletion, or change.
This audit log must obviously be protected from outsiders,
and every security-relevant event must be recorded.
 Intrusion Detection
o Intrusion detection software builds patterns of normal
system usage, triggering an alarm any time the usage seems
abnormal.
Kernelized Design
 A security kernel is responsible for enforcing the
security mechanisms of the entire operating system.
 The security kernel provides the security interfaces
among the hardware, operating system, and other
parts of the computing system.
 Typically, the operating system is designed so that the
security kernel is contained within the operating
system kernel.
Cont.…
Several good design reasons why security functions may be isolated
in a security kernel.
 Coverage. Every access to a protected object must pass through
the security kernel.
 Separation. Isolating security mechanisms both from the rest of
the operating system and from the user space makes it easier to
protect those mechanisms from penetration by the operating
system or the users.
 Unity. All security functions are performed by a single set of
code, so it is easier to trace the cause of any problems that arise
with these functions.
Cont.…
 Modifiability. Changes to the security mechanisms are
easier to make and easier to test.
 Compactness. Because it performs only security
functions, the security kernel is likely to be relatively
small.
 Verifiability. Being relatively small, the security kernel
can be analyzed rigorously. For example, formal methods
can be used to ensure that all security situations (such as states
and state changes) have been covered by the design.
Assurance in Trusted Operating Systems
Typical Operating System Flaws
o Known Vulnerabilities
 User interaction is the largest single source of operating system
vulnerabilities
 An ambiguity in access policy.
 Incomplete mediation
 Generality is a fourth protection weakness, especially among
commercial operating systems for large computing systems.
Cont.…
Assurance Methods
 Testing
 Testing is the most widely accepted assurance technique.
 However, conclusions based on testing are necessarily
limited, for the following reasons:
o Testing can demonstrate the existence of a problem, but
passing tests does not demonstrate the absence of
problems.
o Testing adequately within reasonable time or effort is
difficult because the combinatorial explosion of inputs and
internal states makes testing very complex.
Cont.…
o Testing based only on observable effects, not on the
internal structure of a product, does not ensure any
degree of completeness.
o Testing based on the internal structure of a product
involves modifying the product by adding code to
extract and display internal states. That extra
functionality affects the product's behavior and can
itself be a source of vulnerabilities or mask other
vulnerabilities.
Cont.…
 Penetration Testing
o A testing strategy often used in computer security is called
penetration testing, tiger team analysis, or ethical hacking.
o A team of experts in the use and design of operating systems
tries to crack the system being tested.
 Formal Verification
o The most rigorous method of analyzing security is through
formal verification
o Two principal difficulties with formal verification methods:
Cont.…
 Time. The methods of formal verification are time consuming
to perform.
o Stating the assertions at each step and verifying the
logical flow of the assertions are both slow processes.
 Complexity. Formal verification is a complex process.
o For some systems with large numbers of states and
transitions, it is hopeless to try to state and verify the
assertions.
o This situation is especially true for systems that have not
been designed with formal verification in mind.
Cont.…
 Validation
o Validation is the counterpart to verification, assuring that the
system developers have implemented all requirements.
o Validation makes sure that the developer is building the right
product (according to the specification)
o Verification checks the quality of the implementation
o Several different ways to validate an operating system
 Requirements checking.
 Design and code reviews.
 System testing.
Summary of Security in Operating Systems
 Developing secure operating systems involves four activities.
o The environment to be protected must be well understood.
o Policy statements and models
o The essential components of systems are identified
o The interactions among components can be studied.
 A system to implement it must be designed to provide the
desired protection.
 Assurance that the design and its implementation are correct

You might also like