Reference Article1st published in May 2015doi 10.1049etr.docx

Reference Article
1st published in May 2015
doi: 10.1049/etr.2014.0035
ISSN 2056-4007
www.ietdl.org
Operating System Security
Paul Hopkins Cyber Security Practice, CGI, UK
Abstract
This article focuses on the security of the operating system, a
fundamental component of ICT that enables many
different applications to be used in a variety of computing
hardware. While, the original operating systems for
large centralised computing focused their security efforts
primarily on separating users, operating systems secur-
ity has had to adapt to cater for a wider range of technology,
such as desktop computers, smartphones and
cloud platforms, and the different threats that have evolved as a
consequence. This article examines some of
the core security mechanisms that every operating system needs
and the gradual evolution towards offering
a more secure platform.
Introduction: What is the Operating
System?
All too frequently the words operating system conjure
up thoughts of Microsoft Windows made popular as
an operating system that enabled desktop computing.
However, there have been, and still continue to be a
large number of operating system types and versions
in operation [1] for all sorts of devices. These devices
range from those designed to work with mobile
phones, tablets and games consoles of the consumer

world, through to the servers/laptops, network
routers and switches of the IT industry, as well as em-
bedded devices and industrial controllers from indus-
trial engineering. [Dependent upon the hardware
architecture, the operating systems can be significantly
different to the fuller versions that this paper uses to
illustrate the key security mechanisms.]
In essence, the purpose of the operating system is to
provide a layer above the hardware execution environ-
ment, abstracting away low level details, such that it
appropriately shares and enables access to the mul-
tiple hardware components, such as processors,
memory, USB devices, network cards, monitors and
keyboards. It thus provides an environment in which
multiple applications (ranging from advanced
weather forecasting through to word processors,
games and industrial control processes) can all be po-
tentially executed and accessed by multiple users.
Operating systems have a history and timeline dating
back to the development of the first computers in
the early 50s, given that the users, then also needed
a way to execute their applications or programs.
Since that time operating systems have adapted to
Eng. Technol. Ref., pp. 1–8
doi: 10.1049/etr.2014.0035
take advantage of increases in speed and performance
of hardware and communications. The changes either
enable new functionality and applications or adapt to
optimise the performance of certain hardware, such as
in the case of telecommunications routers and
switches that can have additional networking func-
tions integrated into their operating system. So while
the UNIX and Microsoft Windows family of operating
systems have dominated the server and desktop envir-

onment of the past 20 years, the security problems
found, and subsequent solutions to these problems,
have also found their way into a variety of operating
systems for other hardware environments; ranging
from mobile phones (e.g. Apple iOS, Android,
Symbian), to embedded devices (e.g. WindowsCE,
Integrity RTOS), to networking products (e.g. Cisco
IOS, JunOS) [This article focuses on the most popular
operating systems found in the IT industry. A collec-
tion of known operating systems can be found at ref-
erence [1]].
Changing Threats
Having evolved from running on shared stand-alone
computers to being highly optimised and networked
computers it’s not surprising that operating systems
have had to evolve their security to mitigate different
threats.
30+ years ago, the shared stand-alone mainframes used
by large organisations and universities faced threats
from (predominately internal) users accessing data and
computing ‘time’ that they were not entitled to.
20+ years ago, the range of applications and network
connectivity that operating systems had to support
1
& The Institution of Engineering and Technology 2015
IET Engineering & Technology Reference Paul Hopkins
increased significantly. With increasing connectivity
threats arose around the exchange of malicious files
or network access to data by both internally connected
users as well as an increasing community of curious ex-

ternal individuals and groups of less altruistic ‘hackers’.
10+ years ago, the operating system was integrated
into and became dependent upon the networks of
often globally connected organisations. This integra-
tion and dependence brought about attention and
threats from serious criminals and activists who used
the computing resources and network reach of the
Internet to not only attack an increasing number of
online applications for confidential data, but also to
deny access to online services and applications.
Today, the potential threats that operating systems
have to protect against have been extended still
further.
† Miniaturisation has meant that the physical theft of
small scale devices, such as smartphones/tablets (now
containing potentially large quantities of sensitive data
or as access tokens for online and physical services)
needs to mitigated.
† Increased availability of wireless networks has
required devices to be ‘always connected’ to a
variety of public networks and other devices, thus in-
creasing the number of types and potential network
attacks against the platform.
† Operating systems (from different organisations) are
increasingly deployed onto shared public computation
and storage resources in cloud data centres, which
brings with it concerns about protecting the data
and availability of these services from attacks against
the collocated operating systems and its hosting
platform.
† Increasingly, highly capable and advanced threats
from governments and organised crime have
become a concern of many organisations. With oper-

ating systems having to develop mitigations (alongside
other security controls) for advanced malware and the
potential interception of communications between
platforms and cloud data centres.
Why is it Hard to Secure?
It’s not surprising given this evolving threat landscape
that operating systems have had to change their se-
curity models, and also not surprising that they have
had significant challenges in responding.
One of the most significant changes was experienced
10+ years ago when Microsoft Windows [2], which
2
due to its ubiquity and market dominance, found
itself opened up to a multitude of network based
attacks as organisations moved many services and
communications online using its operating system.
The consequence of opening up this ‘network
surface’ of the operating system to the internet was
that the type and range of vulnerabilities (ranging
from buffer overflows to denial of service) being dis-
covered and exploited rapidly increased. That’s not
to say other popular operating systems, such as
UNIX did not find themselves similarly attacked and
exploited [3]. However, Microsoft found itself having
to significantly enhance the software development
and assurance process by which it secured its operat-
ing systems (and other software) [2].
Similarly, operating systems rely on and also provide
for increasing connectivity to not just networks but
also multiple peripherals either externally connected
through interfaces, such as USB or with integral
devices, such as graphics card. The software necessary

to interface these devices (e.g. device drivers) network
and peripheral devices may also operate in a privileged
mode within the operating system, potentially acces-
sing system resources, such as processor memory dir-
ectly. For example, vulnerabilities within the USB
device drivers within Linux [4] and Windows [5] have
been found to enable an attacker to gain full control
of the operating system, when armed with a
‘crafted’ USB device. While USB driver software
tends to be an integral part of the operating system
software, other software drivers for graphic and
network devices are developed by the hardware
manufacturer themselves, thus creating a challenge
when integrating and ‘assuring’ that this software is
free of similar vulnerabilities.
Over time, operating systems have also increased their
functionality to take advantage of the high network
connectivity and performance increases in hardware,
which has in itself bought about some challenges.
Firstly, this has meant that the operating systems
have significantly increased in size and complexity.
Hence examining the operating system software for
vulnerabilities and security issues has become difficult
and expensive (e.g. Windows XP has an estimated
code base of 50 million lines of source code).
Increases in complexity have also meant re-use of
code and with it the propagation of vulnerabilities
from one so believed trusted code base to another.
A classic and a relatively recent example of this is
the discovery of a previously known vulnerability in
Linux, that allowed, a ‘local’ user to escalate privileges
doi: 10.1049/etr.2014.0035

IET Engineering & Technology Reference Operating System
Security
(beyond their restricted user privileges to system privi-
leges) also replicated within Android [6], with the
re-use of that code base. Secondly, the operating
system is expected to provide a rich environment for
users where the user has control over the applications
running within the operating system (e.g. just look at
the multiple applications enabled for a desktop or
smartphone to realise that users like personal choice
and rich functionality). Hence the operating system
has had to increasingly protect itself, its resources
and all users from weaknesses (or malicious intent)
in the applications that users want to use.
How are They Being Secured?
So while there have been many security issues in oper-
ating systems, there have also been a number of
attempts to design, build and just generally strengthen
an operating system’s security over the years. In add-
ition to funding and developing operating systems,
such as SELinux (which was made open source by
NSA in 2000), governments have also attempted to
provide standards and incentives for operating
systems, with evaluation schemes, such as TCSEC
[Trusted Computer System Evaluation Criteria
(TCSEC).] and the Common Criteria [7] scheme.
In the 1980s the US government developed the TCSEC
scheme with the aim of evaluating the trustworthiness
of commercially available operating systems (applica-
tions and networking products are also evaluated)
and evaluated a number of operating systems
against that scheme. Overtaking and extending this
scheme in the 1990s a number of governments (UK,
Canada, France, Germany and the Netherlands) devel-

oped the Common Criteria scheme, with a wider
variety and type of operating systems, such as
Windows, HP-UX, AIX, Linux [8], evaluated against
the more flexible ‘protection profiles’ that defined
the threats and thus security goals of the operating
system under evaluation.
The industry has also both developed dedicated high
security operating systems (often aimed at the govern-
ment market and thus had their products put through
evaluation schemes) and also felt the need to improve
its security, generally in response to increasing security
threats and vulnerabilities discovery [2]. As previously
highlighted, Microsoft, for example, needed to
rapidly re-engineer its security and assurance approach
for its Window operating systems to take account of
the emerging security threats facing its products and
the growing complexity and size of the code.
doi: 10.1049/etr.2014.0035
Similarly, the open source and academic communities
have focused on developing either specific security
features/extensions for an operating system or on
developing a full secure operating system. While the
more well-known initiatives, such as TrustedBSD [9]
provide the full functionality needed of a desktop or
server environment, others, such as seL4 [10] are
highly assured minimal operating systems (microker-
nels) that have been developed for mobile and em-
bedded devices.
While the approach and focus of these different com-
munities have been different, the central goals for a
secure operating system have always been fairly
consistent:

† Ensuring that the operating system can enforce the
separation of users and access to resources, such as
files, memory, I/O and processes through a defined
policy.
† Ensuring that execution is through a trusted execu-
tion path, which is free from vulnerabilities and flaws
that would reduce the effectiveness of that separation.
However, as operating systems have developed for
mobile and embedded devices, it has become neces-
sary to mitigate for other threats, such as securing
the data on the device in the event of theft or loss,
or validating that the software has not been tampered
given physical access to the device. The following
diagram (Fig. 1) and sections outline some of the key
security features and how they mitigate the threats.
Key Security Features
Access control
At the centre of all operating system security is the
ability to enforce control over access to system
resources and information, either to mitigate malicious
actions or accidental damage by users. While control-
ling access to confidential patient or financial files
from multiple users on a shared system may seem
like an obvious security feature, just as important is
the need to prevent the inadvertent download of
malware from within a browser from executing and
installing unwanted spying software; as is the need
to prevent a badly implemented application access-
ing other users’ private data held within the
memory as demonstrated recently by the Heartbleed
vulnerability [11].
Access control lies at the heart of many operating
systems, ensuring that legitimate users and processes

3
Fig. 1 Key threats and operating system security controls
are only allowed to access the resources that they are
entitled to do so. Unfortunately, it’s not necessarily as
simple as it may seem, as the examples above illus-
trate. It is not just access by users to files we need
to worry about, but also the need to control the
access by processes or machines to resources that
includes not just data files, but memory, peripherals,
networks and so on.
Access is also a term that can be used to describe quite
a number of operations; at the simplest it could be the
ability to write to, read from or execute a file. This is
the case within many commercial UNIX systems
where ‘files’ represent all resources, such as memory,
I/O and network connections. However, in other oper-
ating systems (such as Microsoft Windows) the access
operations are richer and include the capability to
‘delete’ or ‘take ownership’ of a data type (rather
than just a file type), for example.
The fact that we need to store a range of permitted
operations with a large number of users and with
access to a large number resources, can cause prac-
tical difficulties (having to store and check each time
an individual user needs to access a particular resource
that they have permission to). Hence a popular strat-
egy is to either group users into groups (with
defined group access permissions) or to store individ-

ual lists of users and access permissions for each
resource.
However, the principles that operating systems need
to achieve in order to control access securely are
well known (even if the practical implementation is
more challenging). Firstly, they need to ensure that
4
they have a trusted mechanism for deciding and en-
forcing the rights of the requesting process/user with
the designated rights of the object (e.g. file), a capabil-
ity often referred to as the reference monitor.
Secondly, that enforcement capability needs to be
free from tampering, modification and vulnerabilities,
a concept often referred to within the operating
system as the Trusted Computing Base. Finally, the
path by which that enforcement happens also needs
to also be trusted, such that there can be no oppor-
tunity for malicious processes or users to interrupt
that execution path, a concept known as the trusted
path.
In reality, there are few operating systems that imple-
ment these capabilities and concepts perfectly, al-
though a number of the capabilities can be seen in
many. For example, Microsoft Windows contains a se-
curity reference monitor that mediates the requests for
access to resources or files (including generating audit
messages based on the operations attempted). In add-
ition, it also provides a trusted and prioritised execu-
tion path for the console logon (ctrl-alt-del) such
that other installed applications (including malware)
cannot intercept the password and user credentials.
Similarly a number of UNIX versions, such as SELinux
or TrustedBSD [9] have added support for a reference

monitor as well as the capability for Mandatory Access
Control (MAC). In the majority of our description so
far, and probably in the experience of many readers,
most ‘files’ are under the ownership of the user who
can grant or deny access to others a scheme known
as Discretionary Access Control. By contrast for many
secure operating systems and those implementing a
reference monitor it’s necessary to protect the files
for a variety of other reasons, such as policy, using
MAC. For example, the integrity of the files could be
critical in which case modification of files needs to
be avoided to stop them either being corrupted or
misused by malware or a careless user. Similarly, on
some systems despite a user being granted access to
a file by another user (perhaps sharing the latest clas-
sified intelligence) because that user does not have the
necessary ‘security clearance’ and therefore privileges
to view files of that sensitivity, an access policy needs
to enforce that denial until such time as their clearance
is enhanced or the file sensitivity is downgraded.
Building on the TrustedBSD [9] MAC framework the
Apple iOS [12, 13] operating system has embedded
the capability to limit the access to objects within its
operating systems against a couple of policies for en-
suring file integrity and also process (or application)
doi: 10.1049/etr.2014.0035
Security
control. In the latter case, applications can only access
other system resources for which they have been
enabled. Thus, for example, if they are not allowed

to access the Internet then this is enforced by the op-
erating system, irrespective of the running application
requests.
Network protection
Today, many operating systems are deployed in highly
networked environments, with communications es-
sential for most users to access applications, data
and communicate with each other. In the early devel-
opment of operating systems just as the files were
believed to be trustworthy from users, so too were
the networks to which they were connected often
connecting organisations on trusted or in-house net-
works, rather than the highly mobile devices now con-
necting over untrusted and public networks, such as
the Internet. Hence operating systems have had to
adapt to embed a number of security features into
their systems to mitigate this including network en-
cryption, firewalls and network access protection.
The connectivity of operating systems to the
Internet also signalled the start of a rapid increase in
reported vulnerabilities with many Internet facing ser-
vices for UNIX and Windows Systems found to have
either vulnerability in the services themselves or funda-
mental flaws in the protocols used by the operating
systems to move data around. In the former case, un-
expected or malformed messages are used to overflow
the memory and execute malicious instructions, as
used by the Slammer worm [14] or simply access sen-
sitive memory and return it to an attacker, as was the
case in the recent high profile Heartbleed [11] vulner-
ability. In the latter case, vulnerabilities were found in
the implementation of network protocols themselves,
such as in the classic TCP SYN flood attack [15]
example, where constant requests to open a

network connection on a system from an attacker
without them subsequently closing that connection
caused the operating systems to consume too many
resources and stop communicating.
As a consequence of these threats many operating
systems have built firewalls into their operating
systems to reduce the ability of attackers to access net-
works services and applications that they should not.
As well as limit the number of external connections
that can be made to only those that are trusted, espe-
cially important with many operating systems outside
of an organisational network and directly on the
Internet. The Internet Storm Centre [16] has
doi: 10.1049/etr.2014.0035
attempted to track the time before which an un-
patched operating system directly connected to the
Internet, is compromised. Varying from ∼20 min in
2003, through to 4 min in 2008 and back to 40+
min in 2012, the statistics mirror the addition of pro-
tection to the network and operating systems security
rather than a change in threat levels.
Similarly, operating systems have also increased their
support over time for more secure protocols (e.g.
IPSEC, TLS/SSL and WPA2) to enable trusted connec-
tions either to organisational networks remotely
across the internet or direct to other individual
systems and networks using encryption and mutual
authentication based upon Public Key Cryptography
(PKI). That mutual authentication often needs to be
used to help identify the operating system itself and
its general security health (e.g. that it has not been
compromised and will not help propagate malware
or a worm) before it is given access to a corporate

network, a scheme known as Network Access
Protection.
Malware protection
Malware has become an increasing issue for operating
systems to deal with as users need and want to access
and exchange files and applications through a variety
of means, such as web portals, messaging/chat
systems and social media. Indeed, many of the
recent cyber security attacks have been as a conse-
quence of the receipt of a malicious file from a web
site or email rather than direct attack via the network.
This leaves the platform designers with a conundrum.
How to secure the platform against the potential ma-
licious execution of applications, yet also provide an
open environment for legitimate execution of applica-
tions? As a consequence a number of strategies have
been adopted.
Application Verification and Control: An important
principle in ensuring security in most operating
systems is that of maintaining the user’s privileges to
run and access resources as being very distinct and
separate from that of the administrator as this limits
the potential damage a malware can do to the core
operating system code and other users or application
data.
Whereas most operating systems have historically
identified the code that was acceptable to be executed
based purely upon the user identity or the group that
they belonged to, operating systems (such as Apple
5

iOS and Microsoft Windows) use methods that check
that the code within the application has not been
modified and is from a trusted source. This is done
by checking that the ‘hash’ (or fingerprint) of the ap-
plication (that is about to be executed) matches the
cryptographically signed hash that is extracted from
a certificate (from a trusted authority) accompanying
the application. For example, Apple iOS implements
this mechanism, by enforcing all applications
through the app store. These are signed by Apple
after being checked, although there is anecdotal evi-
dence that the checking is not always that specific
from a security perspective.
Similarly, operating systems have extended the mechan-
ism by which they assess and control the execution of
files so that other attributes, such as its location in the
file system; its version number date or type and so on
all can be combined with the user or group identity to
decide on the access permission. An example of which
can be found in Microsoft Windows with Applocker.
Even though an application may be permitted to
execute, sometimes the application (and the process
that executes it) may become compromised. For
example, the browser or mail reader starts executing
malware from the downloaded content. For this
reason operating systems (such as Apple iOS/OSX)
have used cryptographic mechanisms (PKI certificates)
to protect the rest of the operating system using two
methods. Firstly, by protecting the list of capabilities
that an application may require (such as network,
GPS) so that the operating system knows that no add-

itional capabilities have been requested since it started
running (e.g. some malware may attempt to turn on
the microphone and camera). Secondly, by using the
code signing mechanism, the signed application
code is checked by the operating system as the
process is loaded into memory for execution to
ensure that it has not been compromised or hijacked
during its general execution.
Application Separation: Sandboxing: Sandboxing is
a popular method of ensuring that an application’s
functionality is contained and thus limits the ability of
the application either to access other applications
running at the same time or their memory, I/O and
network interfaces/resources, by providing a form of
isolation. There are a number of different approaches
to this, firstly the whole operating system can be
virtualised and run on a hypervisor. (A hypervisor
abstracts the hardware environment for a platform,
and provides a method or container for separating out
6
and executing a number of operating systems on one
platform.) Although this approach does not protect
other applications in the same operating system, it
does protect applications in other operating systems
on the same hardware. Alternatively, some particular
vulnerable applications, such as the browser may
themselves have sandbox protection (e.g. Google
Chrome) built into them and therefore tries to limit
the ability of code to execute on the operating
system. Or lastly, as is the case in operating systems,
such as Apple iOS/OSX and Android [17], an
application is constrained to a single process space
and it is executed within its own context. Access to
shared system resources (ranging from file systems to

cameras and GPS receivers) are defined and need to
be accepted by users prior to installation and
execution and controlled and logged by the operating
system.
Application Execution
Attackers have exploited (and will probably continue
to exploit) applications through the user supplied
input. One of the most common and oldest form of
attacks has been the ‘buffer overrun’ where the user
supplied input goes unchecked and ends up writing
directly to the operating systems and applications
memory that is normally used to store the application
execution code, temporary and global data. Instead an
attacker supplies sufficient data to take control of the
application execution (by manipulating the stack
pointer) and execute within the application context
the data and code they have written to the memory
rather than continue to execute the application. In
order to mitigate this attack, a number of platforms
and operating systems, such as Windows XP
onwards, Apple iOS, Android, SELinux, all mark the
application data as non-executable so that even if
the attacker manages to write data to the memory
they will struggle to execute that data.
To mitigate the non-execution of the overwritten data
or where the space available is too small to contain all
of the malicious instructions attackers attempt to use
another technique ‘return to-lib-c/return orientated
programming’. In this case, they attempt to use
already pre-loaded and existing libraries and code of
the operating system, which they reference in a se-
quence to try to execute their desired functions. To
mitigate this attack, a number of operating systems
have also adopted the technique of address space

layout randomisation. By randomising the memory
locations in which they load executable code and li-
braries the ability of an attacker to readily guess and
doi: 10.1049/etr.2014.0035
Security
access the predictable software codes they need is sig-
nificantly reduced.
Physical Theft
With widespread Internet connectivity and a prolifer-
ation of mobile and smart devices, operating system
security has had to turn its attention to the simplest
and oldest of threats, that of theft and physical
access to the device. Operating systems now have
the capacity to access online services and store
locally on the devices increasing volumes of informa-
tion, such that access to the device could provide
access to significant online resources and local data.
This was a significant departure from the original plat-
forms of 20 years ago that would have required a
crane to take the systems from the building, yet now
they are in the reach of a pickpocket.
Fortunately, many operating systems have developed
protection in two ways. Firstly, they have developed
the capability to encrypt individual data files and in
some cases data within the memory. This is done in
order to protect access to applications and data from
other users and processes during a short period of
physical access to the device (e.g. where a USB stick
or drive is plugged into the system). Secondly, all of

the data is encrypted on the device and thus protects
against subsequent copying if physically stolen. Both
approaches may take advantage of hardware encryp-
tion facilities that are increasingly built into many pro-
cessors/chips (as cryptographic operations can be
expensive and power consuming). However, the oper-
ating systems have also taken advantage of the hard-
ware capabilities that are increasingly built into some
computing platforms to also store the cryptographic
material securely. For instance, Bitlocker within the
Microsoft Windows operating system is designed to
use the Trusted Platform Module, a tamper proof hard-
ware chip to store the encryption key material. Similarly
the application processor used by many Apple iOS
devices will store a unique cryptographic key for each
individual device. The key, embedded during manufac-
ture into the application processor, is never accessed or
disclosed, but used in other encryption routines to sign
and encrypt other keys and data, and never accessed by
the operating system directly. It provides a unique key
that the operating system can rely on to check that
its hardware and code have not been tampered with.
Operating System Security – Good
Implementation Practice
While for a number of different operating systems the
overall trend appears to be one of enhancing security
doi: 10.1049/etr.2014.0035
within their core, very often organisations (and indivi-
duals given the increase in products, such as smart-
phones) need to configure them to adapt to their
business and personal requirements. If the security is
to be maintained and balanced with the usability of
the devices, then an understanding of the options
needs to be available to make those compromises.

Just as the threat landscape to operating systems has
changed, so too has the environment for guidance
for secure configuration and deployment of these
platforms, with an increase in guidance and tools
(albeit primarily for an organisation and its IT opera-
tions rather than the end user).
Many operating system (and platform) vendors, such
as Microsoft Windows, VMware and Cisco etc, have
now produced both ‘hardening’ guides and tools to
assist with their secure configuration. Prior to these
vendors issuing guidance the information gap was
filled by independent security associations, such as
CIS [18] who provide ‘hardening’ guides for multiple
platforms based on community feedback. Similarly,
government agencies (such as the UK CESG and US
NSA) have published guidance with ‘hardening’ and
configuration information (and in some instances con-
figuration tools). Although in the latter case, such
guidance has only recently become more widely avail-
able to communities other than government, probably
as a result of recognising the interdependence of
these platforms for much of society rather than a
select few.
Overall, this guidance very often focuses ensuring that
any configuration maintains the principles and con-
cepts we have introduced within this article, namely:
† Least privilege: Restricting users and processes
(acting on their behalf) to the minimal privileges ne-
cessary to execute their operations.
† Separation: Isolating processes, data and users ap-
propriately, so that there is minimal interference pos-
sible either maliciously or accidentally.

† Minimal: Limiting access to only the essential users
and services from a trusted and authenticated source.
† Updates: Being able to update software on the dis-
covery of vulnerabilities or configuration weaknesses
to maintain security.
† Assurance: Designing and managing subsequent
development (on top of the operating system) using
secure development methodologies and the security
features that the operating systems have embedded
into them.
7
† Audit: Enabling a trusted and secure path to gener-
ate appropriate information log and audit information.
Future Directions for Operating System
and Platform Security
Within this article, we have examined the key security
features of operating systems and how they have
adapted to changes in technology and the threats
that have emerged. So while it is apparent that
many operating systems are increasingly having the
core security concepts built into their operating
systems to meet the changing threats, it is also clear
that they will continue to have to evolve.
In particular, operating systems will continue to have
to adapt, to the increasing distribution of functions
to the cloud, the increasingly rich functionality
required within embedded systems/devices, the avail-
ability of hardware for assisting with secure functions
or the changes in attitudes to privacy and different

threats.
† From a user perspective, the cloud will undoubtedly
be viewed as an operating platform of the future, with
dedicated applications or access to sub-operating
systems, all of the key security mechanisms from the
federation of authorisation and access control to en-
cryption of data remains challenging.
† Just as was originally the case with mobile phones
evolving from feature phones to smartphones, the in-
creasing functionality and connectivity will result in
embedded systems facing similar challenges to secur-
ing their (increasingly functional) operating systems.
Either as consequence of the limited space and
power constraints, or as consequence of the difficul-
ties with integrating real-time safety related opera-
tions with security concepts, such as encryption.
† The availability of dedicated hardware for encrypt-
ing data or holding key encryption material has
already had a significant benefit on the security of
some platforms, as highlighted earlier. Increasing
access to such dedicated hardware or the use of hard-
ware virtualisation for process separation and protec-
tion against threats, such as malware will help
strengthen protection of single device operating
systems, and create a more secure platform.
† The increasing concerns of an individual’s privacy
and the emergence of powerful security threats from
governments appears also to be having an effect on
the security features within operating systems. While
some concerns have led to changes in encryption
methods (such that the master keys always reside
8
with the user rather than the operator/provider) re-
search work has also focused on developing access

control mechanisms that allow users to be more ex-
pressive about the situations when, where and how
they want their information to be accessed, rather
than giving complete rights all of the time to particular
groups and users.
REFERENCES
[1] List of operating systems:
http://www.en.wikipedia.org/wiki/
List_of_operating_systems, accessed October 2014
[2] At 10-Year Milestone, Microsoft’s Trustworthy Computing
Initiative More Important than Ever, http://www.news.
microsoft.com/2012/01/12/at-10-year-milestone-microsofts-
trustworthy-computing-initiative-more-important-than-ever/,
accessed October 2014
[3] Sourcefire Vulnerability Research Team (VRTTM): 25
Years of
Vulnerabilities: 1988–2012, Research Report, Yves Younan
[4] Linux Kernel caiaq USB Drivers Buffer Overflow
Vulnerability:
https://www.labs.mwrinfosecurity.com/system/assets/153/
original/mwri_caiaq-usb-drivers-buffer-overflow_2011-03-07
.pdf, accessed April 2015
[5] MS13-027 Vulnerabilities in Kernel-Mode Drivers Could
Allow Elevation of Privilege, https://www.technet.microsoft.
com/library/security/ms13-027, accessed April 2015
[6] Linux vendors rush to patch privilege escalation flaw after
root exploits emerge, http://www.computerworld.com/
article/2500325/malware-vulnerabilities/linux-vendors-rush-
to-patch-privilege-escalation-flaw-after-root-exploits-em.

html, accessed April 2015
[7] Common Criteria: https://www.commoncriteriaportal.org/,
[8] Certified Products: http://www.commoncriteriaportal.org/
products/, accessed October 2014
[9] The Trusted BSD Project: http://www.trustedbsd.org/docs.
html, accessed October 2014
[10] seL4 Operating System Kernel Home Page:
http://www.sel4.
systems/, accessed October 2014
[11] Heartbleed Vulnerability: http://www.heartbleed.com/,
[12] iOS Security: https://www.apple.com/privacy/docs/
iOS_Security_Guide_Oct_2014.pdf, accessed November
2014
[13] Miller, C., Blazakis, D., Zovi, D.D., Esser, S., Iozzo, V.,
Weinmann, R.-P.: ‘iOS Hackers Handbook’ (John Wiley &
Sons Inc.) ISBN 978-1-118-20412-2
[14] The Spread of the Sapphire/Slammer Worm: http://www.
caida.org/publications/papers/2003/sapphire/, accessed
October 2014
[15] TCP SYN Flooding and IP Spoofing Attacks:
http://www.cert.
org/historical/advisories/CA-1996-21.cfm, accessed October
2014
[16] Survival Time: https://www.isc.sans.edu/survivaltime.html,

[17] Android Security Overview: https://www.source.android.
com/devices/tech/security/, accessed October 2014
[18] CIS Security Benchmarks:
http://www.benchmarks.cisecurity.
org/, accessed October 2014
doi: 10.1049/etr.2014.0035
http://www.en.wikipedia.org/wiki/List_of_operating_systems
http://www.news.microsoft.com/2012/01/12/at-10-year-
milestone-microsofts-trustworthy-computing-initiative-more-
important-than-ever/

https://www.labs.mwrinfosecurity.com/system/assets/153/origin
al/mwri_caiaq-usb-drivers-buffer-overflow_2011-03-07.pdf
https://www.technet.microsoft.com/library/security/ms13-027
http://www.computerworld.com/article/2500325/malware-
vulnerabilities/linux-vendors-rush-to-patch-privilege-
escalation-flaw-after-root-exploits-em.html

https://www.commoncriteriaportal.org/
http://www.commoncriteriaportal.org/products/
http://www.trustedbsd.org/docs.html

http://www.sel4.systems/
http://www.heartbleed.com/
https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_
2014.pdf
2014.pdf
2014.pdf
2014.pdf
2014.pdf
2014.pdf
2014.pdf
http://www.caida.org/publications/papers/2003/sapphire/
http://www.cert.org/historical/advisories/CA-1996-21.cfm

https://www.isc.sans.edu/survivaltime.html
https://www.source.android.com/devices/tech/security/
http://www.benchmarks.cisecurity.org/
http://www.benchmarks.cisecurity.org/Introduction: What is the
Operating System?Changing ThreatsWhy is it Hard to
Secure?How are They Being Secured?Key Security
FeaturesApplication ExecutionPhysical TheftOperating System
Security -- Good Implementation PracticeFuture Directions for
Operating System and Platform SecurityREFERENCES
Be sure to follow all directions here.
Choose any 6 (only) to respond to in writing. Half a page

double-spaced at most
should suffice, for most answers, though some answers require a
shorter
response. Save your document as a .pdf file and submit it
through the
assignment here on Canvas by no later than 11:59 p.m. Tuesday
May 14. Any
exams submitted after this deadline will not be accepted, no
exceptions.
Number and separate your responses in the document clearly.
Do not include the
questions in your response. Be sure to proofread your writing.
You have 24 hours to complete this final. You are welcome to
make use of your
notes, any of the text documents or articles Iʼve posted, and the
internet.
However, you should work individually. Submitting the same
response as another
student will result in a failing grade for both parties.
Failure to complete the exam on time will result in a 0 for 20%
of your total grade.

Music in Film Final Exam
• Create your own PDF response document.
• Do not include questions, only the numbers you are
responding to.
• Number your responses clearly with the number and a) b) and
c) where
appropriate.
• Attach .pdf to Canvas before 11:59 p.m. on 5/14/2019
Respond to ANY six (6) questions only:
1) Koyaanisqatsi (1982) "The Grand Illusion"
https://www.youtube.com/watch?v=i4MXPIpj5sA&
a) How does the music function in this clip? Who composed this
music and

what style or genre is it?
b) More generally, how does this composerʼs film score
function throughout the
entire film?
c) Is this film music diegetic? Why or why not?
2) Untitled (2009)
a) Which two types/styles of music composition are shown in
this film?
b) Which type of composition is the main character writing?
3) Persepolis (2007)
Give 2 examples of contrasting uses of music from this film (in
words, don't
attach a link), and describe the overall role music plays in this
animation.
4) How is Ligetiʼs music used in 2001: A Space Odyssey, in
contrast to that of the
compositions by Richard or Johann Strauss? Why did Kubrick
choose to use
these pieces in this film?
5)
a) What is the significance of the musical theme in the opening
credits of The
Shining (1980), and who composed this iteration of this ancient
melody?
https://www.youtube.com/watch?v=kiV3J_e977Q&
-and-
b) Describe the sound of the music by Pendereckiʼs that is used
in The Shining

(1980). How does Pendereckiʼs music function throughout the
film/ why was it
chosen?
6) Compare and contrast the styles and uses of the musics of
both Carl Stalling
and Hoyt Curtin. Discuss differences in instrumentation and the
functions of each
music, in each cartoon studio.
https://www.youtube.com/watch?v=TtSukSkIq4s&list=PLeC2W
eKvjXcVEfpYlF6z
05GLxtU50ovND
Jonny Quest theme
https://www.youtube.com/watch?v=8TNWSGCiBzg
7) Who was Hitchcockʼs principal composer? How does the
music function in any
one of these three scenes; a, b, or c?
a) Vertigo clip (1958)
https://www.youtube.com/watch?v=P-sWReV2DDQ
b) North by Northwest plane scene
https://www.youtube.com/watch?v=Kh8Zv6j-utk
c) North by Northwest Mount Rushmore Chase
https://www.youtube.com/watch?v=4zr_zL_T3g8
8) In Paul Thomas Andersonʼs There will be Blood (2007)
Jonny Greenwood
uses what kind of ensemble? How does his music contrast with
the music of Arvo
Pärt from the same film?

9) Miles Ahead (2016)
a) What was Milesʼ problem?
b) How does this Miles Davis tune “So What” function in Miles
Ahead (2016)?
Miles Davis - “So What”
https://www.youtube.com/watch?v=zqNTltOGh5c
10) Discuss one piece of music or art from Sorry to Bother You
(2018). How does
the message of the film relate to the message of the art or
music?

Reference Article1st published in May 2015doi 10.1049etr.docx

More Related Content

Similar to Reference Article1st published in May 2015doi 10.1049etr.docx (20)

More from lorent8 (20)

Recently uploaded (20)

Reference Article1st published in May 2015doi 10.1049etr.docx