Applied Cyber Security and the Smart Grid:

Implementing Security Controls Into the Modern

Power Infrastructure 1st Edition by Eric Knapp,
Raj Samani ISBN 1597499989 9781597499989
download
https://ebookball.com/product/applied-cyber-security-and-the-
smart-grid-implementing-security-controls-into-the-modern-power-
infrastructure-1st-edition-by-eric-knapp-raj-samani-
isbn-1597499989-9781597499989-17060/

Download more ebook instantly today - Get yours now at ebookball.com

 Get Your Digital Files Instantly: PDF, ePub, MOBI and More
Quick Digital Downloads: PDF, ePub, MOBI and Other Formats

Applied Cyber Security and the Smart Grid Implementing Security

Controls Into the Modern Power Infrastructure 1st Edition by Eric
Knapp, Raj Samani ISBN 1597499989 9781597499989

https://ebookball.com/product/applied-cyber-security-and-the-
smart-grid-implementing-security-controls-into-the-modern-power-
infrastructure-1st-edition-by-eric-knapp-raj-samani-
isbn-1597499989-9781597499989-17070/

Applied Cyber Security and the Smart Grid: Implementing Security

Controls Into the Modern Power Infrastructure 1st Edition by Eric
Knapp, Raj Samani ISBN 1597499989 9781597499989

https://ebookball.com/product/applied-cyber-security-and-the-
smart-grid-implementing-security-controls-into-the-modern-power-
infrastructure-1st-edition-by-eric-knapp-raj-samani-
isbn-1597499989-9781597499989-17038/

Cyber security and Global Information Assurance 1st edition by Kenneth

Knapp 1605663271 9781605663272

https://ebookball.com/product/cyber-security-and-global-
information-assurance-1st-edition-by-kenneth-
knapp-1605663271-9781605663272-20184/

Cyber Physical Security Protecting Critical Infrastructure at the

State and Local Level 1st Edition by Robert Clark, Simon Hakim ISBN
9783319328249 3319328247

https://ebookball.com/product/cyber-physical-security-protecting-
critical-infrastructure-at-the-state-and-local-level-1st-edition-
by-robert-clark-simon-hakim-isbn-9783319328249-3319328247-15774/
Cyber Physical Security Protecting Critical Infrastructure at the
State and Local Level 1st edition by Robert Clark, Simon Hakim ISBN
3319328247 9783319328249

https://ebookball.com/product/cyber-physical-security-protecting-
critical-infrastructure-at-the-state-and-local-level-1st-edition-
by-robert-clark-simon-hakim-isbn-3319328247-9783319328249-17008/

The NICE Cyber Security Framework Cyber Security Intelligence and

Analytics 1st Edition by Izzat Alsmadi ISBN 3030023605 9783030023607

https://ebookball.com/product/the-nice-cyber-security-framework-
cyber-security-intelligence-and-analytics-1st-edition-by-izzat-
alsmadi-isbn-3030023605-9783030023607-15840/

Cyber Physical Security Protecting Critical Infrastructure at the

State and Local Level 1st Edition by Robert M Clark, Simon Hakim ISBN
3319328247 9783319328249

https://ebookball.com/product/cyber-physical-security-protecting-
critical-infrastructure-at-the-state-and-local-level-1st-edition-
by-robert-m-clark-simon-hakim-
isbn-3319328247-9783319328249-15836/

Auditing Information and Cyber Security Governance A Controls Based

Approach 1st edition by Robert Davis 1000416127 9781000416121

https://ebookball.com/product/auditing-information-and-cyber-
security-governance-a-controls-based-approach-1st-edition-by-
robert-davis-1000416127-9781000416121-20148/

Cyber Security and Critical Infrastructure 1st edition by Leandros

Maglaras, Helge Janicke, Mohamed Amine Ferrag 9783036548463

https://ebookball.com/product/cyber-security-and-critical-
infrastructure-1st-edition-by-leandros-maglaras-helge-janicke-
mohamed-amine-ferrag-9783036548463-20056/
Kristin Haltinner · Dilshani Sarathchandra
Jim Alves-Foss · Kevin Chang
Daniel Conte de Leon · Jia Song (Eds.)

Communications in Computer and Information Science 589

Cyber Security
Second International Symposium, CSS 2015
Coeur d'Alene, ID, USA, April 7–8, 2015
Revised Selected Papers

123
Communications
in Computer and Information Science 589
Commenced Publication in 2007
Founding and Former Series Editors:
Alfredo Cuzzocrea, Dominik Ślęzak, and Xiaokang Yang

Editorial Board
Simone Diniz Junqueira Barbosa
Pontifical Catholic University of Rio de Janeiro (PUC-Rio),
Rio de Janeiro, Brazil
Phoebe Chen
La Trobe University, Melbourne, Australia
Xiaoyong Du
Renmin University of China, Beijing, China
Joaquim Filipe
Polytechnic Institute of Setúbal, Setúbal, Portugal
Orhun Kara
TÜBİTAK BİLGEM and Middle East Technical University, Ankara, Turkey
Igor Kotenko
St. Petersburg Institute for Informatics and Automation of the Russian
Academy of Sciences, St. Petersburg, Russia
Ting Liu
Harbin Institute of Technology (HIT), Harbin, China
Krishna M. Sivalingam
Indian Institute of Technology Madras, Chennai, India
Takashi Washio
Osaka University, Osaka, Japan
More information about this series at http://www.springer.com/series/7899
Kristin Haltinner Dilshani Sarathchandra
•

Jim Alves-Foss Kevin Chang

•

Daniel Conte de Leon Jia Song (Eds.)

•

Cyber Security
Second International Symposium, CSS 2015
Coeur d’Alene, ID, USA, April 7–8, 2015
Revised Selected Papers

123
Editors
Kristin Haltinner Kevin Chang
University of Idaho University of Idaho
Moscow, ID Moscow, ID
USA USA
Dilshani Sarathchandra Daniel Conte de Leon
University of Idaho University of Idaho
Moscow, ID Moscow, ID
USA USA
Jim Alves-Foss Jia Song
University of Idaho University of Idaho
Moscow, ID Moscow, ID
USA USA

ISSN 1865-0929 ISSN 1865-0937 (electronic)

Communications in Computer and Information Science
ISBN 978-3-319-28312-8 ISBN 978-3-319-28313-5 (eBook)
DOI 10.1007/978-3-319-28313-5

Library of Congress Control Number: 2015958547

© Springer International Publishing Switzerland 2016

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, express or implied, with respect to the material contained herein or for any errors or
omissions that may have been made.

Printed on acid-free paper

This Springer imprint is published by SpringerNature

The registered company is Springer International Publishing AG Switzerland
 Preface

The 2015 Cybersecurity Symposium: Your Security, Your Future was the second in a
series of conferences hosted by the Center for Secure and Dependable Systems
(CSDS). The symposium offered a key opportunity for academic researchers and
system stakeholders from industry and government organizations to meet and discuss
state-of-the-art and state-of-the-practice techniques and processes related to cyberse-
curity. The objective of the symposium was to provide a platform for stakeholders to
collaborate and exchange ideas and processes to help improve the security of today’s
critical systems. The 2015 Cybersecurity Symposium was partially funded by the State
of Idaho and CSDS.
Since its inception in 2014, the symposium has attracted national and international
stakeholders, including engineers, practitioners, researchers, and learners from indus-
try, government, and academia. The 2015 conference brought together approximately
50 attendees from diverse locations such as the US East and West Coast and Europe.
Hence, the opportunities created by this symposium to bring world-class knowledge
and state and nationwide interest to the ongoing efforts in cybersecurity by the
University of Idaho and the State of Idaho are significant.
The 2015 conference received 20 extended abstracts and 11 full-paper submissions.
The peer-review process for extended abstracts and research papers included two
stages. In the first stage, all potential participants submitted extended abstracts. These
abstracts were reviewed by the Organizing Committee. Authors of extended abstracts
deemed suitable for the conference goals were invited to present their research at the
symposium and to submit full papers for consideration for the conference proceedings.
In the second stage, full-paper submissions went through a series of anonymous
peer-reviews. The resulting detailed reviews were given to all draft authors. Decisions
about final paper acceptance were reviewed and approved by the Organizing Com-
mittee. The committee accepted nine papers to be included in the 2015 proceedings.
The collection of papers in these proceedings reflect four areas of scholarly work:
(1) permissions and trust evaluation, implementation, and management; (2) cloud and
device security and privacy; (3) social implications of networked and mobile appli-
cations, and (4) system and process assessments for improved cybersecurity. These
areas demonstrate a maturity in the fields of cybersecurity and privacy by providing
novel examples of secure computer systems and associated theoretical advances.
The results and case studies presented in these proceedings capture the scope of
current knowledge as well as potential future applications. Previous books on cyber-
security and privacy have been largely divided by discipline. Industry has discovered
the limitations to current security measures, social scientists have investigated public
attitudes and behavior toward privacy and security, engineers have investigated risks of
cybersecurity breaches in critical infrastructures, and computer scientists have explored
practical measures that can be taken to maximize online security while maintaining
some level of privacy for users. Until recently, these fields have operated in a
VI Preface

non-collaborative fashion resulting in a limited understanding of how technology

development and adoption are affected by broader societal needs.
The present proceeding are an attempt at merging the knowledge and strengths of a
number of different fields. Because we have included scholarly and professional work
from the social sciences, computer science, engineering, and infrastructure, this volume
provides a comprehensive and practical information source for graduate students,
faculty, industry, governmental organizations, and other stakeholders who are inter-
ested cybersecurity and privacy.
The careful selection and organization of the papers in this volume extends the fields
of cybersecurity and privacy in several important ways. The Cybersecurity Symposium
and resulting conference proceedings:
• Provide a platform for industry and academia to merge their knowledge and
experience
• Present a clear analysis of the challenges faced by the public and private sector
while simultaneously connecting these issues with current, cutting-edge, computer
science research
• Bring human factors into the analysis of cybersecurity and privacy concerns
• Present an avenue for social scientists and computer scientists to deepen their
understanding of security needs and privacy demands
• Include an analysis of the problems and opportunities in cybersecurity as it applies
to critical infrastructures
• Present an analysis of the economic impacts of cybersecurity
We look forward to this publication bridging cybersecurity advances in academia,
industry, and governmental organizations and providing a foundation to future
developments in the fields of cybersecurity and privacy.

October 2015 Kristin Haltinner

Dilshani Sarathchandra
Jim Alves-Foss
Kevin Chang
Daniel Conte de Leon
Jia Song
 Organization

The 2015 Cybersecurity Symposium was organized by the Center for Secure and
Dependable Systems of the University of Idaho. The center is partly sponsored by the
Idaho Global Entrepreneurial Mission. The conference was held at the Coeur d’Alene
Resort.

Programme Committee and Local Organizing Committee

Jim Alves-Foss University of Idaho, Secure and Dependable Systems, USA
Kevin Chang University of Idaho, Department of Civil Engineering, USA
Daniel Conte de University of Idaho, Secure and Dependable Systems, USA
Leon
Arvilla Daffin University of Idaho, Secure and Dependable Systems, USA
Kristin Haltinner University of Idaho, Department of Sociology and
Anthropology, USA
Jia Song University of Idaho, Secure and Dependable Systems, USA
 Contents

Permissions and Trust Evaluation, Implementation, and Management

Expanding RTEMS to a Multiuser System by Using Security Tags . . . . . . . . 3

Jia Song and Jim Alves-Foss

UI Tags: Confidentiality in Office Open XML . . . . . . . . . . . . . . . . . . . . . . 19

Lawrence Kerr

The Search for Trust Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

David E. Ott, Claire Vishik, David Grawrock, and Anand Rajan

Cloud and Device Security and Privacy

Surrender Your Devices or Be Turned Away: Privacy Rights at the Border. . . 49

Elizabeth J. Etherington

Comparing Encrypted Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Jim Buffenbarger

Social Implications of Networked and Mobile Applications

Can I Live? College Student Perceptions of Risks, Security, and Privacy in

Online Spaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Kristin Haltinner, Dilshani Sarathchandra, and Nicole Lichtenberg

How the Secure Use of Technology Could Influence Travel to and from
School for Elementary School-Aged Children . . . . . . . . . . . . . . . . . . . . . . . 82
Kevin Chang, Kristin Haltinner, and Reilly Scott

System and Process Assessments for Improved Cybersecurity

An Assessment Model and Methodology for National Security Systems. . . . . 107

Jennifer Guild

Security in Agile Development: Pedagogic Lessons from an Undergraduate

Software Engineering Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
J. Todd McDonald, Tyler H. Trigg, Clifton E. Roberts,
and Blake J. Darden

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Permissions and Trust Evaluation,
Implementation, and Management
 Expanding RTEMS to a Multiuser System
by Using Security Tags

Jia Song(B) and Jim Alves-Foss

University of Idaho, Moscow, ID 83844, USA

{jsong,jimaf}@uidaho.edu

Abstract. This paper discusses a research project that develops

enhanced security protections for operating systems running on secu-
rity enhanced microprocessors. Security tagging schemes are promising
mechanisms for enhancing the security of computer systems. The idea
of tagging schemes is to attach metadata tags to memory and registers
to carry information about the data being tagged. This paper summa-
rizes the features of these new microprocessors and discusses the use of
these features in the design of enhanced operating system security for an
exemplary real time operating system.

1 Security Tagging Schemes

Computers play an increasingly important role in modern life and it is now
widely recognized that people need to pay more attention to computer security
issues. Over the years, researchers and developers have devised various tech-
niques including encryption, firewalls, and virus scanners to provide secure com-
puting environments. The idea of enhancing these mechanisms by using hardware
to provide security features for operating systems and user applications is not
new. Decades ago researchers proposed techniques to add security labels (tags)
at the hardware level to help with the enforcement of system security proper-
ties [1,3]. Unfortunately, these techniques required more computing resources
and memory than was feasible at the time. As hardware speeds have improved,
the idea of security tagging has resurfaced as a promising mechanism for enhanc-
ing security.
Security tagging schemes attach labels to memory and/or registers to carry
information about data during program execution. These labels are also called
tags. They have been used by researchers to ensure that the semantics of com-
putations are correctly implemented; to isolate code and data, users and system;
and to enforce security policies at the hardware level. The implementation of
tagging in hardware provides developers with enhanced security mechanisms
without a penalty on performance, as compared to traditional microprocessors.
Therefore, tagging schemes are seen as promising mechanisms to help processors
and OSs (Operating Systems) implement security properly.
Security tagging schemes are known as promising mechanisms for enhancing
the security of computer systems. Security tagging was first designed and imple-
mented to protect against some low-level attacks, such as buffer overflow and

c Springer International Publishing Switzerland 2016
K. Haltinner et al. (Eds.): CSS 2015, CCIS 589, pp. 3–18, 2016.
DOI: 10.1007/978-3-319-28313-5 1
4 J. Song and J. Alves-Foss

format string attacks [6,7,12,14]. Recently, security tagging schemes have been
improved to prevent high-level attacks, which include SQL (Structured Query
Language) injection and cross-site scripting [2,4]. Tags are also implemented in
some specific architectures to support memory access control [8,9,13,15]. The
details of the comparison of these tagging schemes can be found in another paper
of the authors [11].
As part of the University of Idaho’s (UI) UITags research project, a tagging
scheme has been developed to secure RTEMS (Real-Time Executive for Multi-
processor Systems). In the UI tagging scheme, a 32-bit tag is associated with
every 32-bit memory and registers. The tag consists of three fields: Owner field,
Code-space field and Control-bits field. These fields provide information about
who owns the data, who can manipulate the data and other information for
further control the tagged data. During system execution, tags are checked and
propagated appropriately. Different from traditional operating systems, RTEMS
can be decomposed into many smaller components. Each component provides a
set of unique services to support the running of the system. Based on the func-
tionality and importance of the component, tags are associated with the code to
represent security levels. Furthermore, tagging rules were implemented to help
control the information flows in the RTEMS.
The original version of RTEMS implements a single-user multi-threaded model
of execution. To expand it to a multiuser system, the concepts of “superuser”
and “non-privileged user” were used. A superuser is a user who has authority to
create, delete, and control non-privileged users. Non-privileged users are isolated
from each other and can only control themselves, but have no abilities to create,
delete or control other users. By assigning different user tags to the data/code of
the system and user application, the data and code can be seen as belonging to
a specific user. Based on the tag, the system knows the specific permissions that
the code/data have, and therefore protects its resources from being accessed by
non-authority users. We expanded RTEMS from a single user system to multiuser
system, implementing a user manager module to handle the multiuser issues. This
paper briefly reviews the overall UI security tagging scheme, provides details of the
implementation of tags for multiple users and how the system code was changed
to support the advanced security tagging scheme for multiuser RTEMS system.
Future work is also proposed at the end of the paper.

2 RTEMS
RTEMS [5] consists of a super core (SCORE) and 18 managers. The 18 managers
provide different services and the SCORE provides kernel functions that support
the managers. After examining the code of RTEMS, we found that it has very
little security built in. Therefore, the UI tagging scheme has been developed with
the purpose to secure the RTEMS.

2.1 RTEMS Architecture

The original 18 managers of RTEMS provide services to user code in support
of concepts such as tasks, memory, timers, and communications. Each manager
 Expanding RTEMS to a Multiuser System by Using Security Tags 5

provides a well-defined set of services through directives that take the place of
traditional system calls. Each manager also has internal functions that it uses to
support implementation, some of these are private to the specific manager, and
some are intended to be used by other managers. In either case, these manager
internal functions are not intended to be used by user code.
In addition to each manager, RTEMS has a set of modules that make up
the SCORE subsystem. The SCORE provides services for all managers, and all
managers interact with the SCORE via directives. Some major SCORE modules
are: object, thread, chain, interrupt service routine (ISR), error handler, heap
and protected heap, workspace, initialization, message, time, watch dog, and
user extension. These modules are key to the internal working of RTEMS, but
are not intended for use by user code.
Conceptually the APIs are meant to be externally accessible, internally
restricted to other RTEMS modules or internal to specific modules. However,
RTEMS currently does not restrict access to any of these functions or their pri-
vate data structures. The following sections outline the major security concerns
that need to be addressed to secure RTEMS.

2.2 Security Concerns in RTEMS

The examination of RTEMS’s source code reveals several major security

concerns.

No Separation Between User and System. In RTEMS, there is no sep-

aration between user resources and system resources. In traditional operating
systems, the system has ultimate privileges while the user has limited privileges.
In RTEMS, both the user and system have ultimate privileges. Currently user
code can use all of the SCORE code, internal functions, and directives. This
means that the user can do everything that the RTEMS system can. For exam-
ple, the user has privileges to change the system configuration, delete system
tasks, etc. This is a design decision since RTEMS is intended for embedded
systems and is built for high performance. Unfortunately, this limits the use of
RTEMS in secure environments or from safely running untrusted code.

System has no Protection from Users. RTEMS has no protection from

users and no concept of multiple users. Take the directive, rtems task delete,
as an example. There is no check of the identity of the caller of this directive.
This means that other system managers can use this directive, other system code
can use it, and even users can delete any task by calling this directive. There is
no restriction on who can delete which task, which means that users could even
delete system threads.

No Separation of RTEMS Code. There is no isolation among RTEMS man-

agers, directives and SCORE. In RTEMS, SCORE works as the micro kernel of
6 J. Song and J. Alves-Foss

the system. If the SCORE code is misused by a user or attacked by a mali-

cious user, critical security problems may occur. Therefore it is important that
SCORE code be separated from other system code and user code.
RTEMS has 18 managers and each manager has its own functionality. Each
manager has specific directives that support the manager. RTEMS has internal
functions that help RTEMS managers function correctly, inline routines that
speed up the running of RTEMS, and library functions supporting some of the
functionalities. In the current version of RTEMS, every directive of a RTEMS
module can call any function, including internal functions of other RTEMS mod-
ules. This may cause security problems if any application in user code is modified
by an attacker, because the attacked code can use any other RTEMS code that
the attacker wants. With a Security Tagged Architecture (STA), mechanisms
can be implemented in RTEMS to prevent unintended or malicious usage of
manager and SCORE code.

No Separation of Different Users. Although RTEMS has a single user multi-

threaded model of execution, it can be expanded to be a multiuser system. To
be extended to a multiuser system, the system must have a method to identify
the owner of user data and keep it separated from other users’ data. However,
RTEMS cannot tell which user is the owner of specific user data. For a thread, it
might be a thread generated by user 1, a thread generated by user 2, or a system
thread. Since the owner of the thread is unknown, who has the permission to
change or delete it can not be specified. Currently RTEMS is a single user system
that contains no rules to specify who can do what. This becomes a problem when
RTEMS is extended to allow more than one user.

3 UI Security Tagging Scheme

3.1 Tag Format and Its Composition

As shown in Fig. 1, the tag is a 32-bit tag which consists of three fields:
Owner, Code-space, and Control-bits. The tag can be written as (Owner,
Code − space, Control − bits). In a tag, each of the Owner and Code-space
fields is represented with 12 bits, with the remaining 8 bits for the Control-bits.

Owner Field. In the implemented tagging scheme, the first field, the Owner
field, helps separate system code/data and user code/data. It indicates the
identity of the owner of the data or code. The values of the Owner field
can be classified into six major classes: SCORE internal, SCORE, Manager
internal, Manager, Startup and User. The SCORE internal class can be
further divided into three groups: SCORE internal init, SCORE internal
private and SCORE internal. The Manager internal class is also broken
into three groups: Manager internal init, Manager internal private and
Manager internal.
 Expanding RTEMS to a Multiuser System by Using Security Tags 7

Fig. 1. Tag format

By using the Owner field, the owner of data or code can be easily
identified. For example, the first field in the tag (object, Code − space,
Control − bits) indicates that the data or code associated with this tag is
object code or object data; where object is one of the SCORE modules. A
tag (task manager, Code − space, Control − bits) shows that the data
or code is owned by the task manager. In the remaining sections, SCORE in
the tag means this field could be one of the possible values in the SCORE class,
and the same holds for the Startup class, SCORE internal class, Manager class,
Manager internal class and User class. Although RTEMS currently only sup-
ports a single user, it is expanded to a multiuser system as part of this paper
(see Sect. 4). Therefore, multiple users are listed in the possible values of the
User class. Having different users for the Owner field ensures that a user can
only access its own data and code, but not other users’ resources.

Code-Space Field. The second field of the tag is the Code-space field. This
field shows which code space should manage the data or code. In addition to
this, the Code-space field is also critical for information flow control and mem-
ory access control. The possible values of the Code-space field are the same as
the Owner field. The Code-space can be User, Manager, Manager internal,
SCORE, SCORE internal and Startup. For example, the tag (User1,
Manager1, Control − bits) means the data are created in manager1’s code
for user1. Manager1 is used as a place holder for a specific manager name, such
as task manager, partition manager, etc.
Code-space is used to show the class of the code or data and helps con-
trol function calls. Users in the system should only use the manager directives,
and not directly use SCORE, SCORE internal, and Manager internal functions.
Therefore, firstly, Code-space is used to indicate which class the code belongs to,
and then rules can be provided to control which classes of code can use which
other classes of code.

Control-Bits Field. The Control-bits field is used for further control. It starts
with a single copy bit (bit 7) which indicates whether a return value has been
modified. The copy bit allows user code to have a copy of a trusted data value
8 J. Song and J. Alves-Foss

Table 1. Possible values of the memory type

Memory type Read or read/write

Data memory (x00) 000 read-only
100 - read/write
Stack memory (x01) 001 read-only
101 - read/write
Code memory (executable) 010 read-only
not entry point (x10) 110 - read/write
Code memory (executable) 011 read-only
entry point (x11) 111 - read/write

(i.e., a task ID) as long as it is not changed. The notation cp means the copy bit
is not set while cp indicates the copy bit is set. The return value to a user will
be tagged with the security class of the directive and will have the copy bit set.
If the copy bit remains set, this means that the user has not made any change
to the value. If the copy bit is not set, the data is treated as modified data and
will not be accepted when used as a parameter to a directive. This allows user
programs to store copies of system IDs and handles while maintaining security
of the values. For example, if user1 uses directive code from the task manager
to get a tag identifier, the directive returns an identifier tagged (user1, task
manager, cp). If the user modifies this returned ID, the tag will be changed to
(user1, user1, cp) to indicate this ID has been changed; and the OS will no
longer trust the ID. This allows the system to trust IDs that come from users
without having to keep an internal table of indirect identifiers or separate tables
for each user, and thereby improve performance and simplify system code.
Three of the control bits (bits 6 to 4) are allocated for memory type. To
further protect data in memory, memory is divided into three classes: stack
memory, code memory, and data memory. These three bits specify the memory
type, such as readable, writable, read-only, executable, entry point, data memory,
and stack memory.
– Stack Memory. Stack memory is readable and writable, and is treated using
register expression rules for stores, instead of assignment rules.
– Code Memory. Code memory stores the executable and readable code. The
“entry point” of a function has a special tag with it to indicate the correct
starting address for executing a function.
– Data Memory. All other memory is data memory which is readable and
writable, and it is treated using assignment rules.
The possible values of the memory type are shown in Table 1.
A world-readable bit (bit 3) is used to indicate that the tagged data can be
read by all entities; It can be used when the system (higher level) wants to give
the user (lower level) permission to access some data, such as configuration data.
The other 3 bits (bits 2 to 0) are reserved for future use.
 Expanding RTEMS to a Multiuser System by Using Security Tags 9

3.2 Tag Representation

In a tag, each of the Owner and Code-space fields is represented with 12 bits,
with the remaining 8 bits for the Control-bits. For Owner field and Code-space
field, the higher 4 of the 12 bits are used to indicate if the tagged data or code
is a system resource or not. If the higher 4 bits are 1111, this means that the
tagged data or code is from the system, otherwise it is from users. For system
code (tags that start with 1111), the lower eight bits are used to divide the code
into smaller classes. Among the 8 lower bits, the higher 3 bits indicate the level of
the class, and the lower 5 bits represent which component. For example, the level
of class includes SCORE internal class, SCORE private internal class, SCORE
internal init class, SCORE external class, manager internal class, manager pri-
vate internal class, manager internal init class, manager external class. The 5
bits which represent the component of the RTEMS can be a specific manager
or SCORE, such as task manager, partition manager, SCORE thread, SCORE
interrupt service routine and etc.
For the user code and data, all of 12 bits of the Owner field or Code-space
field are used to represent a user. When expanding the system to a multiuser
system, the 12 bits are further divided to support multiple users (see Sect. 4).

3.3 Lattice
Since the Owner field and Code-space field are used to define the security class
of the data, the ideas similar to those of the Data Mark Machine (DMM) [3]
can be implemented to control the information flows within RTEMS. The solu-
tion is a bit different from DMM since a hierarchy is defined for confidentiality
and integrity controls, and it is not for traditional multi-level security. However,
accesses still can be controlled to prevent “lower-level” entities from unautho-
rized access to higher level entities.
The lattice model of information flow deals with channels of information flow
and policies. For the lattice model of information flow, there exists a lattice with
a finite set of security classes and a partial ordering between the classes. The
nodes of the lattice represent the individual security classes. The notation ≤
denotes the partial ordering relation between two classes of information. For
example, A ≤ B means class A is at a lower or equal level than class B. The
notation ⊕ denotes the least upper bound (LUB) operation.
In a lattice, there exists a unique class C = A ⊕ B such that:

A ≤ C and B ≤ C, and
A ≤ D and B ≤ D implies C ≤ D for all D in the lattice.

The security class of an entity in the model, a, will be denoted as a, and it can
be written as a = (Owner(a), Code − space(a)). The Control-bits are ignored in
this discussion since they are used separately from the lattice-based controls
and formulas. Owner(a) refers to just the Owner field of a’s tag, Code-space(a)
refers to the Code-space field of the tag of a.
The definition of the LUB, ⊕, of the security classes of two tags is:
10 J. Song and J. Alves-Foss

If a = (Owner(a), Code-space(a)), and b = (Owner(b), Code-space(b)),

then a ⊕ b = (Owner(a) ⊕ Owner(b), Code − space(a) ⊕ Code − space(b)).

The definition of the equality of the security classes of two tags is:

If a = (Owner(a), Code-space(a)), and b = (Owner(b), Code-space(b)),

then if Owner(a) = Owner(b) and Code − space(a) = Code − space(b), then
the security class of a and b are the same.

The definition of the domination of the security classes of two tags is:

If a = (Owner(a), Code-space(a)), and b = (Owner(b), Code-space(b)),

then if Owner(a) ⊆ Owner(b) and Code − space(a) ⊆ Code − space(b), then
the security class of a dominates the security class of b.

The similar rules for ≤, <, ≥ and > operations can be defined similarly and
are not shown here.

3.4 Tagging Rules for the Basic Values in C

At the start of the system, and as each subroutine is called, data and code tags
are initialized with the correct security classification and memory types. This
section discusses how those classifications can be used, in the context of the C
programming language, to define tagging rules needed to satisfy the security
concerns based on the partial ordering and lattice concepts.
This section introduces the basic concepts of using tags at the C language
level. The full details can be found in the corresponding literature [10].

– During execution of a program, the tag of the current running thread is the
same as the security class of the program counter, denoted as PC.
– The tag of the variable a is the tag of the memory location of a and its security
class is denoted a.
– The tag of a literal, or constant, n, is the same as the tag of the PC. This is
because the use of the literal is controlled by the current thread.
– The security class of the tag of an array item, a[i] is the least upper bound
of the security class of the index to the array and the security class of the
memory location referenced by the array: a[i] = i ⊕ [[a + i]] where [[a+i]]
denotes the memory address referenced by a[i]. In cases where the copy bit
of the memory location is set, the tag of that memory location is used instead
of the LUB.
– The tag of a value referenced by a pointer, *p or structure p->fld or p.fld
is the tag of the memory location referenced. For example, ∗p = [[p]] where
[[p]] denotes the memory address referenced by the pointer p.
– All code will be tagged as read-only, executable memory, and all entry points
to functions will be tagged as function entry points (to avoid problems with
the misuse of function pointers).
– All data memory will be tagged as read-write data memory.
 Expanding RTEMS to a Multiuser System by Using Security Tags 11

3.5 Tag Manager and Tag Engine

To support the UI tagging scheme, a tag manager has been added to RTEMS to
allow the OS to handle the tagging issue, for example checking if the copy bit is
set or not in some specific functions and take or release the ownership of some
data. These tag checking and propagation can not be done at the hardware level
easily. Some tagging functions have been inserted into special RTEMS functions
to satisfy special requirements of the tagging scheme, such as setting the copy
bit of the ID’s tag that is going to be returned from some RTEMS functions.
The tag engine has been implemented at the hardware level to support the
tagging scheme. The tag engine can be turned on and off to test the whole
tagging system. Tag engine rules have been applied to different instructions.
Therefore when executing an instruction, the tag engine rules for the specific
instruction will be checked to ensure the instruction is allowed to be executed
based on the tagging rules. If that is not the case, the tag engine will generate
an error message and terminate the program.

4 Security Tagging Scheme for Multiuser System

To expand RTEMS to support multiple users, a new “user” construct has been
added to RTEMS, similar to the task construct. To manage the users, the con-
cepts of “superuser” and “non-privileged user” have been defined. All control is
managed through a new user manager.

4.1 Implementation of the Multiple User System

Before our work, RTEMS implemented a single-user multi-threaded model of

execution. To expand it to a multiuser system, the concepts of “non-privileged
user” and “superuser” have to be supported. A superuser is a user who has
authority to create, delete, and control non-privileged users. Non-privileged users
are isolated from each other and can only control themselves, but have no abilities
to create, delete or control other users.
The new RTEMS user model allows for 117 non-privileged user IDs and one
superuser. Each user can have up to 32 separated task IDs. To have more control
over users and their tasks, a set of task IDs is provided to each user. This allows
additional secure isolation between the tasks within a single user. To implement
this, the user levels’ Owner field of the tag is divided into two parts – users
and tasks. The higher 7 bits among the 12 bits are used to represent separate
user IDs and the lower 5 bits are used to indicate task IDs for those users. For
example, the 12 bits for the superuser are 1110 110 XXXXX, where the 1110
110 indicates superuser ID and the XXXXX represents task IDs. Since only 7
bits are used to represent different users, this limits the number of users in the
system to be user1 to user117 (0000 001 XXXXX to 1110 101 XXXXX), recalling
that 1111 XXX XXXXX is reserved for RTEMS code. Including the superuser,
there are 118 possible users in the system. For an embedded system, 118 users
12 J. Song and J. Alves-Foss

Table 2. New bit representation for Owner field of USER and LOW levels

USER 1110 111 11111

Superuser 1110 110 XXXXX
user117 1110 101 XXXXX
... ...
user2 0000 010 XXXXX
user1 0000 001 XXXXX
LOW 0000 000 00000

each with 32 possible subtasks should be sufficient. The implementation of 118

users does not influence the levels above the general user (USER) level, because
separate controls are made for users and their tasks. The new bit representation
for Owner field of tags are shown in Table 2.

4.2 User Manager

To change RTEMS to a multiuser system, system code needs to be modified
to support multiple users. This includes adding a user manager to RTEMS to
handle the superuser and its abilities to create, delete and control non-privileged
users and corresponding changes to the tag manager. In addition, the simulator
needed modification of the tag engine code to support the user hierarchy rules.
The user manager is supported by several user manager directives, such as
rtems user create directive, rtems user manager initialization directive
and rtems user delete directive, etc.
Take the rtems user create directive as an example, this directive checks
the caller of the directive and creates a non-privileged user. It first checks
that the calling user is the superuser, because only the superuser is autho-
rized to create, control and delete the non-privileged users. If this is the case,
rtems user allocate gets the next available user id, starting at 1, and updates
its internal data structures. After getting the user number, the get user tag
is called to get a specific tag associated with the task ids and task names for
that user. For example, if user number is 1, then a tag (USER1, USER1, true |
READWRITE | DATA MEMORY | WORLD NOT READABLE) is returned. If user num-
ber is 2, the function get user tag will return a tag, (USER2, USER2, true |
READWRITE | DATA MEMORY | WORLD NOT READABLE). Further in the function,
rtems tag word is used to tag the task ids and task names. (Although tags
are associated with pointers, they are actually being attached to the memory
location referenced by the pointer.)
In multiuser RTEMS, a user program is assigned a primary application with
task id 0. This is the first application to execute for the user. The primary
application for a user first declares an array of task id and another array of
task name. When creating a task, the user application passes two pointers to the
rtems task create directive which point to the task id and task name. Then
the directive creates the task for the user application and returns a system-wide
 Expanding RTEMS to a Multiuser System by Using Security Tags 13

unique task id back. By using the system task id, the user application is able
to start, suspend, resume, or delete the task.

4.3 Multiuser Example

The multiuser example starts from an Init function. The Init function first
uses the rtems user create function twice to create two non-privileged users.
In this example the PC’s tag is manually set to the SUPERUSER. Normally
this will happen in the kernel prior to calling Init. The result of calling the
rtems user create function is shown in Fig. 2. The Task id[1] to Task id[4]
are tagged with user1’s tag, and Task id[5] to Task id[7] are tagged with
user2’s tag.
Then the user application sends Task id[1] to Task id[4] to the direc-
tive, rtems task create, to create four new tasks separately. The directive
then creates four tasks and stores the RTEMS task ids into the Task id[1] to
Task id[4] respectively. The copy bit of the tags associated with Task id[1]
to Task id[4] will be set. Similarly, another three tasks will be created by user2
for Task id[5] to Task id[7].
The four tasks created for user1 are different from the three tasks for user2.
User1’s tasks keep printing out the time every five seconds. After starting user2’s
tasks, the tasks are suspended for 15 s and then wake up to attempt to delete
user1’s tasks.
The seven tasks run concurrently. Figure 3 shows output of the tasks running
without the tag engine turned on. At the first 15 s, tasks 1 to 4 are running and
printing time information every five seconds. After 15 s, task 5 starts to delete
task 1, task 6 deletes task 3 and task 7 deletes task 4. After successful deletion
of these tasks, only task 2 is still alive and running.
The output of running the seven tasks is displayed in Fig. 4. With tag engine
turned on, when user2’s task (task 5) wants to delete user1’s task (task 1), the
tag engine generates an exception, prints an error message and stops the system.

Fig. 2. Result of a successful call of user create function

14 J. Song and J. Alves-Foss

Fig. 3. User2 delete user1’s task without tag engine turned on

Fig. 4. User2 delete user1’s task with tag engine turned on

 Expanding RTEMS to a Multiuser System by Using Security Tags 15

From the information given by the tag engine, the call is successfully made and
the new PC’s tag is generated correctly ((USER2, TASK EXTERNAL, false |
READWRITE | DATA MEMORY | WORLD NOT READABLE)). However the exception is
raised on a LD instruction that the Owner field of the PC’s tag (USER2) does not
dominate the Owner field of the address’s tag (USER1). This is because when
task 5 tries to delete task 1, it uses the rtems task delete directive and passes
Task id[1] to it. Then, rtems task delete directive tries to get the specific
thread by using Task id[1], which is tagged with user1’s tag, and therefore
generates a LD error message.
Although RTEMS is not fully tagged and the tag engine has to be turned
on manually in the code, the test case shows that the UI tagging scheme for
multiple users is working and can be used to help isolate tasks of different users.

5 Conclusion and Future Work

This paper introduces a design of a new security tagging scheme that enhances
access control through least privilege while enabling good system performance.
The UI tagging scheme focused on securing RTEMS, a single user, multi-thread
model runtime executive. An evaluation of the RTEMS architecture provided a
better understanding of what tags can and cannot do. According to the security
enhancements that were needed, the tag was designed with three fields: Owner
field, Code-space field, and Control-bits field. By using these tags, the system
is able to separate RTEMS (i.e., code and data) and user (i.e., code and data),
divide RTEMS code into different levels, prevent users from using critical system
functions, and protect return values. The combination of Owner field and Code-
space field tags represents the security class of the tagged data. With the security
classes, lattice, and security rules, the information flow can be controlled in
RTEMS.
Modifications of RTEMS source code have also been made to support the tag-
ging scheme. This includes addition of a tag manager which provides tag checking
and propagation that can not be done in hardware. Some tagging functions have
been inserted into specific RTEMS functions to satisfy special requirements of
the tagging scheme, such as setting the copy bit of the ID’s tag that is going to
be returned from some RTEMS functions. RTEMS has also been expanded from
a single user multi-threaded model of execution to a multiuser system. RTEMS
now supports the concepts of non-privileged user and superuser, where the supe-
ruser has the authority to create, delete, and control non-privileged users. A user
manager has been added into RTEMS to support the tagging scheme for multiple
users.

5.1 Future Work

This section summarizes the future work that could be conducted as an extension
of the security tagging project.
16 J. Song and J. Alves-Foss

Fully Tag RTEMS Code to Enable RTEMS to Always use Tagging.

Currently, all of the test cases work by enabling and disabling tagging as needed.
Therefore only some of the RTEMS code is tagged. For future work, all of the
RTEMS functions have to be tagged, including libraries. The goal is to have a
tagged RTEMS running from the beginning of system initialization. In addition
to the RTEMS functions, global variables need to be tagged with care. This
is especially true when RTEMS is modified to a multiuser system. Some global
variables can be shared among different users while other global variables cannot,
due to the possibility that they may affect other users or the system. Therefore
these global variables need to be made usable only by a specific user manager.
In addition, the C library functions need to be considered and properly
tagged. Because of time restrictions, not all of the C library functions that are
used by RTEMS can be tagged manually. Therefore software tools will have to
be used to generate a list of the C library functions that are used in the RTEMS
benchmarks. These functions will be given special tags. By doing this, additional
checks will be applied when using these functions, to prevent malicious usage of
the important functions.
The process of tagging the complete RTEMS may be time consuming,
because RTEMS requires a fresh build and installation even with a small change
of the code, which takes around 20 min.

Reduce the Overhead of the Tagging System. Since almost every instruc-
tion execution requires tag checking of the source or destination operands’ tag,
it increases the overhead of the system. For example, normally, the LD instruc-
tion loads values from memory space to registers, but in the UI tagging scheme,
the LD instruction has to check the value’s tag and store it as the register’s tag
additionally. To minimize the overhead, tags can be cached as many as possible
to speed up the tag checking operations. Another way that could reduce the
overhead of the tagging system is to use a tag compression scheme, and data
and code spatial locality information to reduce the overhead.

Persistent Tags and User-Defined Tagging Rules. The current tagging

model focuses on the protection of code and data from unauthorized access
and modification. It is a first step toward enhanced security tagging, such as
user-defined tags. The support of user-defined tags may require the support
of persistent tags (tags that are maintained between system resets), that may
also be used for multi-processor (or multi-core) execution models and storage of
objects in file systems or other permanent storage.
In addition, the UI tagging scheme only supports fixed tagging rules. In the
future, it would be desirable to have user-defined tagging rules. Another manager
could be implemented to support user-defined tagging rules. However, to be able
to support user-defined tagging rules, the system should provide not only the
interface for users, but protections for the system in case a user tries to do
something that could violate the security of the system.
 Expanding RTEMS to a Multiuser System by Using Security Tags 17

Port Sample Applications to Evaluate the Performance of the Tag-

ging Scheme. Some sample applications could be ported to RTEMS. These
benchmark applications could help evaluate the performance of the UI tagging
scheme. This may require additional changes in RTEMS code. For example, the
portions of RTEMS and C libraries that are needed by the benchmark applica-
tions would need to be tagged. What’s more, RTEMS is only compatible with a
few applications and none of them are usable for evaluation purposes. Additional
efforts are needed to port applications to RTEMS. Based on evaluation results,
new methods for improving performance, may be proposed.

References
1. Burroughs Corporation, Detroit 32, Michigan. The Operational Characteristics of
the Processors for the Burroughs B5000, revision a, 5000–21005 edn. (1962)
2. Dalton, M., Kannan, H., Kozyrakis, C.: Raksha: a flexible information flow archi-
tecture for software security. In: Proceedings of the 34th Annual International
Symposium on Computer Architecture, vol. 35, pp. 482–493, May 2007
3. Fenton, J.S.: Memoryless subsystems. Comput. J. 17(2), 143–147 (1974)
4. Kannan, H., Dalton, M., Kozyrakis, C.: Decoupling dynamic information flow
tracking with a dedicated coprocessor. In: Proceedings of the 2009 IEEE/IFIP
International Conference on Dependable Systems and Networks, pp. 105–114.
IEEE, Estoril, Lisbon, Portugal (2009)
5. On-Line Applications Research Corporation. RTEMS C User’s Guide, edition
4.10.1, for rtems 4.10.1 edn., July 2011
6. Qin, F., Wang, C., Li, Z., Kim, H.-S., Zhou, Y., Wu, Y.: LIFT: a low-overhead
practical information flow tracking system for detecting security attacks. In: Pro-
ceedings of the 39th Annual IEEE/ACM International Symposium on Microarchi-
tecture (MICRO-39 2006), pp. 135–148. IEEE Computer Society (2006)
7. Shioya, R., Kim, D., Horio, K., Goshima, M., Sakai, S.: Low-overhead architecture
for security tag. In: Proceedings of the 15th IEEE Pacific Rim International Sympo-
sium on Dependable Computing, pp. 135–142. IEEE Computer Society, Shanghai,
China (2009)
8. Shriraman, A., Dwarkadas, S.: Sentry: light-weight auxiliary memory access con-
trol. In: Proceedings of the 37th International Symposium on Computer Archi-
tecture (37th ISCA’10), pp. 407–418. ACM SIGARCH, Saint-Malo, France, June
2010
9. Shrobe, H., DeHon, A., Knight, T.: Trust-management, intrusion tolerance,
accountability, and reconstitution architecture (TIARA). Technical report, AFRL
Technical Report AFRL-RI-RS-TR-2009-271, December 2009
10. Song, J.: Development and evaluation of a security tagging scheme for a real-time
zero operating system kernel. Master thesis, University of Idaho, May 2012
11. Song, J., Alves-Foss, J.: Security tagging for a zero-kernel operating system. In:
Proceedings of the 46th Hawaii International Conference on System Sciences
(HICSS), pp. 5049–5058, Wailea, HI, USA, January 2013
12. Suh, G.E., Lee, J.W., Zhang, D., Devadas, S.: Secure program execution via
dynamic information flow tracking. In: Proceedings of the 11th International Con-
ference on Architectural Support for Programming Languages and Operating Sys-
tems, pp. 85–96, Boston, MA, USA, November 2004
18 J. Song and J. Alves-Foss

13. Witchel, E., Cates, J., Asanovic, K.: Mondrian memory protection. In: Proceedings
of the 10th International Conference on Architectural Support for Programming
Languages and Operating Systems, pp. 304–316 (2002)
14. Yong, S.H., Horwitz, S.: Protecting C programs from attacks via invalid pointer
dereferences. In: Proceedings of the 11th ACM SIGSOFT Symposium on Foun-
dations of Software Engineering 2003 held jointly with 9th European Software
Engineering Conference. ACM, pp. 307–316, Helsinki, Finland, September 2003
15. Zeldovich, N., Kannan, H., Dalton, M., Kozyrakis, C.: Hardware enforcement of
application security policies using tagged memory. In: Draves, R., van Renesse, R.
(eds.) Proceedings of the 8th USENIX Symposium on Operating Systems Design
and Implementation, pp. 225–240. USENIX Association, San Diego (2008)
 UI Tags: Confidentiality in Office Open XML

Lawrence Kerr ✉
( )

University of Idaho, Moscow, ID, USA

[email protected]

Abstract. Maintaining confidentiality of data is critical, particularly in need-to-

know environments. Dissemination of classified data must be controlled
according to user clearance, and rests on the proper tagging of data to ensure
appropriate access. The eXtensible Markup Language (XML) provides opportu‐
nity for tagging through its extensibility, and as a standard format for data storage,
processing, and transmission. Its widespread usage covers a broad range of appli‐
cations, especially in productivity software such as the Microsoft Office suite.
This paper describes the UI Tags Project which presents a strategy for imposing
security tags within Office Open XML (OOXML) format documents used with
productivity suites. Leveraging the underlying XML of these document types
enforces mandatory and attribute-based access control policies. Project develop‐
ment goals include a comprehensive system based on a native XML database
which allows users to upload new documents as well as read, edit, or delete
existing documents, and controls for derivative classification.

Keywords: Mandatory access control · Attribute based access control · MAC ·

ABAC · XML · OOXML · Confidentiality · Security tagging

1 Introduction

XML, a markup language for describing a wide variety of data, has become a common
means of storing and transmitting information. XML consists of a series of nested
elements, each with an associated set of attributes. The elements, attributes, and structure
of an XML document is typically defined in a schema that describes each element and
attribute, along with data types and legal values for each. Many common document
formats are based on XML [1, 2]. The flexibility of XML makes it suitable for many of
these applications, as well as many others.
Extending these formats becomes a matter of augmenting underlying XML and
schemas. Extension allows insertion of further information. One particular use of this
extended information might be the inclusion of security information within a document.
This security information is leveraged to determine which users have specific accesses
to specific parts of a document, while continuing to allow users to utilize familiar tools
for creation and editing of content.
This is the high-level goal of the UI Tags document management project. This
project strives to create a means of adding paragraph level tagging to Microsoft
Word.docx format documents to enforce mandatory and attribute based access

© Springer International Publishing Switzerland 2016

K. Haltinner et al. (Eds.): CSS 2015, CCIS 589, pp. 19–33, 2016.
DOI: 10.1007/978-3-319-28313-5_2
20 L. Kerr

controls by manipulating the underlying XML directly in an automated fashion. This

allows a user to create, edit, and delete document content under security constraints
contained within the document itself. UI Tags leverages a native-XML database to
facilitate storage and retrieval of tagged documents.
The remainder of this document is organized as follows. Section 2 discusses back‐
ground research in mandatory access control (MAC), attribute based access control
(ABAC), Office Open XML (OOXML), and XML change tracking. Section 3 provides
an overview of UI Tags with a number of goals. Sections 4 and 5 describe development
stages of UI Tags. Finally, a conclusion with future work is included.

2 Background

One high level goal of UI Tags is to provide a system that supports not only MAC tagging
of documents, but also a wider set of ABAC tagging. Tagging builds on Office Open
XML standards, with initial targets being the individual paragraphs within tagged docu‐
ments, while change tracking looks at general approaches for detecting and incorpo‐
rating changes within a general XML tree.

2.1 Mandatory Access Control

The typical model of an multilevel secure (MLS) environment follows much of the
mandatory considerations of the Bell La Padula model [3]. Under this model, system
entities are grouped as either objects or subjects. Objects are resources to be accessed.
Each object is assigned a security level which conveys its relative sensitivity, represented
by the object’s security classification. Subjects are users or processes that require access
to the objects. Each subject is given a security label as well, referred to here as the
clearance level of the subject, or simply level. Both subjects and objects can be addi‐
tionally associated with some number of compartments. Based on the relationship
between the level of an object and the level of a subject, as well as their respective sets
of compartments, the policy determines whether to grant or deny a particular access.
The fundamental comparison of levels and compartments is known as the “dominates
relationship.” Comparison is possible among classifications and clearances as each
represents a totally ordered set. A typical set might include a number of possible levels
such as:

Here U (unclassified) is the lowest level. All other levels are higher, or more sensi‐
tive, up to TS (top secret) which is the most sensitive. Compartments are not ordered as
no individual comparison exists from one compartment to another. Taken together, the
level and compartments form a partially ordered set. The dominates relationship uses
this partially ordered set to determine if one entity dominates another. To dominate an
object, a subject must have a clearance at least as high as the object, while also belong
to a superset of the object’s compartments. A stronger comparison, strict dominance,
requires this same relationship with the additional constraint that the dominating subject
 UI Tags: Confidentiality in Office Open XML 21

has either a higher clearance than the object’s classification or at least one additional
compartment that the object does not belong to.
Two guiding properties form the basis of access decisions. First, the simple security
property states that only subjects which dominate an object are granted read access. Any
subjects which do not dominate an object are denied access as this would represent a
leak of information to lower levels. In a read only environment this single property
suffices, but in dynamic environments where objects are not only read, but created,
edited, and removed, a further rule is necessary. The *-property deals with this instance.
It states that a subject is only granted write access to dominating objects. This ensures
the subject only writes to objects which are at the subject’s level or higher. A strong *-
property takes this further limiting a user to write only to objects with the same level
and compartment set.
One artifact of MAC environments is the potential for polyinstantiation. Polyin‐
stantiation occurs when some object is necessarily described differently at different
sensitivity levels [4]. A user may only see one instance, matching his or her level, or a
user at a higher level might be able to see one or many lower level representations of
the same object. Some have described this as a necessary side effect of maintaining
multilevel data, even exploiting it to maintain cover stories for various entities [4], while
others have sought to limit or eliminate the presence of polyinstantiation [5].

2.2 Attribute Based Access Control

While a number of different approaches have been proposed in the literature, there does
not yet seem to be a clear consensus as to an exact definition or model of ABAC
([6, 7]). A common theme in existing work is the advantage of ABAC in context-aware
or pervasive computing, where the identity of a service consumer is not necessarily
needed or perhaps even known ([6, 8–11], etc.). ABAC is easily configured and presents
the flexibility necessary to handle dynamic environments, though this flexibility comes
at increased costs as changing or analyzing permissions can become a complex task as
the number of attributes increases [7].
For an attribute-based messaging system, Bobba et al. construct policies from
attribute name:value pairs [9]. Access control policies here consist of conditions that
when satisfied, grant access to message recipients or recipient groups. A condition is a
check on values associated with one or more attributes in disjunctive normal form. These
conditions form the policy that in this case governs if a user with a particular set of
attributes can send a message based on the attributes of the recipient.
Cirio et al. extend a role based access control (RBAC) model with ABAC [11]. They
present the difficulties with a RBAC system such as the static nature of role assignments.
ABAC supplements RBAC here, adding flexibility through use of attributes for role
determination as opposed to user identity. Attributes are associated with both users and
resources, allowing dynamic specification of privileges for resources and association of
users with privileges.
Kuhn et al. [7] present a combined role-centric model RBAC-A, where attributes are
used to supplement and further constrain an RBAC model. Roles and attributes are
distinguished from one another based on whether they are static or dynamic. Attributes
22 L. Kerr

that are static, or reasonably static, are used as the basis for roles. These include things
such as office location, position, or nationality. They are not likely to change frequently
if at all. More dynamic attributes such as time of day are leveraged in the ABAC portion
of the combined model. Using static roles and dynamic attributes together can signifi‐
cantly cut down on the number of possible roles and rules. An example system with 4
static attributes and 6 dynamic results in at most 24 roles and 26 rules, whereas a strictly
RBAC or ABAC approach results in as many as 210 roles or rules, respectively.
Jin et al. [6] state the necessity of more clearly and mathematically defining ABAC,
while providing a model for ABAC that is capable of expressing other, more traditional
models such as mandatory, discretionary, or role based access control. Under this model,
each attribute is a function with a specific range that returns a value or set of values for
some entity. Entities include users, subjects acting on behalf of users, and objects repre‐
senting the resources available in the system. Each entity is associated with a finite set
of attribute functions which return properties of the associated entity. Policies are
constructed using constraints on the values of these attribute functions.
Once the basic entities and attribute sets are defined, four configuration points are
defined: (1) authorization policies (2) subject attribute constraints, (3) object attribute
creation time constraints, and (4) object attribute modification constraints [6]. Author‐
ization policies return true or false as access is granted or denied. Using this framework,
the authors are able to create ABAC policies that adhere to DAC, MAC, and RBAC
policies.

2.3 Office Open XML

Office Open XML, or simply Open XML, is a standard that seeks to provide a stable
document format while providing all features offered by pre-existing productivity appli‐
cations [12]. The standard originally appeared as Ecma-376 in 2006, and has subse‐
quently progressed to a fourth edition [13] as well as an International Organization for
Standardization (ISO) standard [2]. These standards provide schemas for the markup
used in various document types including word processing (WordprocessingML),
spreadsheet (SpreadsheetML), and presentation (PresentationML), in addition to a
number of features shared between file types including the organization of and rela‐
tionship between various document components.
Each Open XML file consists of a number of different parts, all collected in a single
package. The contents and layout of the package are defined in the Open Packaging
Conventions (OPC) section of Ecma-376 [13]. An Open XML file is a package that
contains a number of individual XML files referred to as parts that specify document
content, markup, features, and relationships between different parts. It relies on ZIP
technology to combine the various parts into a single object.
Contents of the package are organized in a hierarchy, with each part having a unique
name that includes both the location in the hierarchy and the content name. The name
represents a pack URI used for addressing specific parts within the package [2, 13].
Common parts of interest are document.xml, [Content_Types].xml, app.xml, and
core.xml.
 UI Tags: Confidentiality in Office Open XML 23

For Open XML word processing documents, the document.xml part contains the
main body of text for the document. The metadata associated with an Open XML docu‐
ment is stored in either core.xml or app.xml, depending on the nature of the metadata.
Open XML standards ([2, 13]) define a metadata schema for the core properties common
to all file types in core.xml, but app.xml is reserved for extended properties - application
specific items. The schema for the core properties defines fifteen pieces of information
that can be used, including such items as creator, creation date, last modifier, last date
modified, subject, title, and keywords. None of the metadata elements is required, and
if no data is present, the part as a whole can be omitted. Repetition of elements is not
allowed – for example, a document with two creator elements results in an error. Any
deviation from what the schema allows in the core properties also results in an error.
The extended properties are application dependent, and allow the incorporation of
information beyond the core properties. The same rules apply here – adherence to the
schema, non-repeating elements, etc. The schema governing extended properties defines
nearly twice as many types as the core properties, including such items as application and
version; character, word, paragraph, and page counts; template used; and total editing time.

2.4 XML Change Tracking

In order to support document altering operations, the system must detect changes to both
the document content and the underlying XML structure. Changes can then be collected
in a delta script, essentially a list of all changes necessary to derive a new version of a
document from an original. Traditionally, a “diff” between two files consists of a line-
by-line comparison of different files. This works well for many file types, but misses
structural information when dealing with XML tree based data [14, 15]. Thus, a number
of algorithms deal specifically with the tree structure of XML in detecting and charac‐
terizing changes.
Many of these algorithms tend towards the hashing of elements or subtrees of an
XML document for the purpose of fast comparisons between documents. In many
instances, only leaf nodes of the XML tree are hashed, with interior nodes aggregating
the hashes of their descendants, with the hope of providing a means of pruning subtrees
from the possible search space.
Khan et al. present an algorithm for change detection that generates signatures for
each node in the XML tree [14]. For a leaf node, the signature is computed as a hash of
the contents of the node. All other nodes will have a signature that combines the signa‐
tures of all the child nodes (in this case using XOR). Comparisons between trees are
then only needed if the root nodes differ. Cobena et al. match as large a proportion of
the original tree in the edited tree by leveraging unique node IDs [16]. Lindholm
proposes a three-way merge algorithm for XML documents [17]. A three-way merge
involves an original document, and two replicas of the original that are edited inde‐
pendently. The merge occurs in two stages: (1) each replica is compared to the original,
changes are detected, and two deltas are obtained; (2) the deltas are applied to the orig‐
inal, generating a new document that incorporates changes found in each replica. The
changes that appear in the delta script are based on changing content of a node, or some
structural change (structure here is based on the parent-child relationship in the XML
24 L. Kerr

tree). Conflicts are identified as ambiguous conditions where different changes are
detected in the same node in both replicas. For example, a node in the original document
might contain the text “Hello,” where in the replicas it may contain “Hi” and “Bye”,
respectively. To resolve such conflicts, Lindholm includes the options to either defer
resolving conflicts until post-processing, or to allow for some level of “speculative
merging” – taking a best guess.
The example provided is a date field in a document’s metadata. If two edited replicas
of an original have different dates associated with them, which date should be used for
the merge? This question is left unanswered.
Rönnau, Pauli, and Borghoff use hashes of individual elements, as opposed to
subtrees, to construct a fingerprint [18]. This fingerprint represents the context of an
element and consists of the hash of the element and hashes of other elements within a
specified radius. The hope here is that an edit operation on a specific element is possible
in the presence of other changes – matching some of the fingerprint or context allows
determining where an operation takes place. This allows for delta scripts that do not rely
on absolute addressing of changes, as well as commutative deltas, where the ordering
of operations does not change the end result.
In further work seeking an efficient change detection strategy, Rönnau, Philipp and
Borghoff [19] frame the change detection problem in terms of the longest common
subsequence (LCS), that is the sequence of leaf nodes of maximum length at a specific
depth that appears in both original and edited documents. This algorithm, called
DocTreeDiff, consists of three steps. First, hash values of all leaf nodes and their respec‐
tive depths are computed, from which a LCS is determined. The second step involves
inspecting the ancestors of leaf nodes found to be matching. Differences along the path
to the root element from the leaf indicate structure preserving changes as opposed to
content changes which only occur at the leaves. Finally, the third step investigates nodes
for which no match exists in the opposing document – each of these represents an insert
or delete operation.

3 UI Tags Overview

The UI Tags project seeks to develop an end-to-end solution which enforces tagging of
specific elements within a document, while enforcing MAC and ABAC policies
involving read, insert, update, and delete operations on document content. Challenges
include management of the document metadata, merging document changes across
security levels, and the capacity for queries over a collection of documents to produce
new derivative documents.
The UI Tags Project (or simply UI Tags) encompasses a number of objectives, many
of which have been addressed in prior studies including work in document-level and
hardware-level tagging. Kerr [20] provided early work enforcing tagging in XML docu‐
ments, using custom schemas to define tags to be used as attributes of various elements.
The secure document portion of UI Tags (henceforth referred to as simply UI Tags in
this proposal) extends this work to focus on word processing documents based on Office
Open XML ([1, 2]), a standard format used by recent editions of Microsoft Word.
 UI Tags: Confidentiality in Office Open XML 25

The objectives of the secure document portion of UI Tags include:

1. Enforcement of element level tagging within Office Open XML documents. The
elements tagged depend on the type of Office Open XML document (e.g., word
processing, presentation, or spreadsheet) containing the tagged elements. Current
focus is on MS Word documents, with paragraph level tagging.
2. Utilize an XML database for storage and retrieval of tagged documents. As work
moves to utilize OOXML data, a native XML database seems appropriate, as it
allows for the individual processing and storage of individual OOXML parts that
make up the document.
3. Richer set of tags. While mechanisms are in place to support tagging of documents
with ABAC tags beyond the necessary MAC tags, these ABAC tags are not yet fully
incorporated into the access control decisions.
4. Tools for original classification. Original classification is the initial process of clas‐
sifying information, which is typically limited to specific entities [21]. Having a set
of tools that integrates with Microsoft Word (or any other application the original
classifier might employ when creating documents) will help greatly with the creation
of multilevel documents, specifically limiting the burden of tag creation and appli‐
cation on the user, while ensuring tagging occurs in an appropriate manner.
5. Derivative classification. In a Master’s thesis at the University of Idaho, Amack [22]
extended continuing work on UI Tags adding controls for derivative classification.
Derivative classification can occur when information is derived or combined from
other sources. Information derived from a classified source needs to bear a like
classification, while combining particular low sensitivity items might result in a
combination that requires a higher classification.
6. Read, insert, update and delete operations. A further objective is the support of a
variety of operations on security tagged Office Open XML documents, while
adhering to a defined MAC and ABAC security policy. Possible operations include
read, insert (a new element), update (the content of an existing element), and delete
(removing an element from the document). Read operations are currently supported
through eXist-db.
7. Document change detection and merge. In support of document-changing opera‐
tions, the system must be able to merge changes back into the original document,
while conforming to the constraints of the security policy.
8. Document metadata. One rather interesting observation of Lindholm [17] that
required more work was that the document metadata tends to change inconsistently.
In our MAC environment, document metadata presents a possible leak of higher-
level information to lower levels. The document metadata typically contains infor‐
mation about the document – time created, number of words, creator or last editor
– which could be used to infer more sensitive information. This is also critical in the
presence of document-changing operations.
9. Queries and reporting over document content. The proposed system provides the
capacity to dynamically create documents based on user-supplied queries over a
collection of documents, while adhering to the security policy and providing prov‐
enance for the retrieved data. The documents returned by these queries will essen‐
tially be derived documents, and thus subject to derivative classification constraints.
26 L. Kerr

Also desirable here is the ability to specify the provenance information returned from
the query.
UI Tags is primarily envisioned as a tool for government environments where an
established MAC policy exists, though it could be implemented in any environment
where need-to-know determines access. In a government setting, MAC aspects of UI
Tags enforce the existing MAC control requirements (users with specific clearances and
need-to-know), while ABAC lends a more dynamic access control mechanism (access
based on date or time, nationality of user, etc.). Outside government, medical facilities
could also benefit from such a system. Here need-to-know relates to care for a patient.
Admission or billing staff needs access to patient demographics, but likely does not
require the level of detail into a patient’s care that a physician requires.

4 UI Tags Phase 1

The initial phase of UI Tags began with mandatory access control for XML documents.
Document here are based on a custom XML schema. The schema defines not only the
structure of the elements within the document, but also a series of XML attributes repre‐
senting the security tags. These XML attributes apply to specific XML elements of
interest throughout the document. In this case, the user of the system is the subject, and
the objects are specific elements within an XML document. Each labeled element bears
three attributes. The first two attributes represent the classification and compartments
associated with the containing element. To mitigate some editing issues arising in this
multilevel environment, a preserve attribute is also used to indicate a need to partially
delete an element. This early effort mitigates a number of issues specific to XML while
allowing for four basic database operations. The work culminated in a prototype client/
server system that allowed a user to perform any of the four basic operations on an XML
database while adhering to a MAC security policy.

C, {}
preserve=
"PRESENT"

C, {} S, {}
preserve= preserve=
"PRESENT" "PRESENT"

C, {RED} C, {} S, {} S, {}
preserve= preserve= preserve= preserve=
"PRESENT" "PRESENT" "PRESENT" "PRESENT"

Fig. 1. Example tagged XML tree

 UI Tags: Confidentiality in Office Open XML 27

Kerr [20] defines four basic operations for security tagged XML documents: (1) read,
(2) insert, (3) update, and (4) delete. Each of these operates at the element level within
the constraints imposed by both the simple security property and the *- property. For
each operation, the path from the root element of the XML tree to the target of the
operation is critical – if the path is not fully dominated by the user, there exists the
possibility that the element exists as a child of a more sensitive element, essentially
orphaning the element in the eyes of the user.
Read access is similar to a Bell La Padula style read, wherein the user must dominate
the object. One added attribute, the present attribute, is used here as some editing oper‐
ations my cause undesirable situations as discussed below. If this flag is present with a
value of “REMOVED,” any user with a level matching the level of the element flagged
as “REMOVED” will not be granted access to the element as it is considered deleted as
far as a user of that level is concerned. Consider a user with a confidential clearance,
with membership in no compartments. If this user were to request read access to the
example XML tree in Fig. 1, only three elements would be allowed: the root element,
the left child of the root, and the right child of that child – only those elements bearing
at least a C classification with no compartments and a preserve attribute of PRESENT.
All data of the higher S classification or any elements with compartment membership
are removed from the user’s read view.

C, {}
preserve=
"PRESENT"

C, {} S, {}
preserve= preserve=
"REMOVED" "PRESENT"

C, {RED, BLUE} S, {} S, {}
C, {RED, GREEN}
preserve= preserve= preserve=
preserve=
"PRESENT" "PRESENT" "PRESENT"
"PRESENT"

Fig. 2. XML tree with deletion

An insertion operation, where a user adds a new element, has similar concerns. The
user’s classification must dominate that of the path from the root to the parent of where
the insertion is to occur. Adopting a strong *-property, the inserted element can only
have a sensitivity that matches that of the inserting user’s classification. If this require‐
ment is relaxed, two problems arise: (1) a downward flow of information is possible if
a high level user inserts a new element at a low level, or (2) a conflict occurs when a
low level user attempts to insert an element that may already exist at a higher level. The
adoption of a stronger *-property as described above, where insertions are only allowed
at the user’s classification, prevents this issue. Recalling a C user with no compartments,
28 L. Kerr

insertions will only be allowed at any of the three readable elements, provided the inser‐
tion bears only the classification and compartments of the inserting user. Any insertion
not bearing a C classification with no compartments represents a violation of the strong
*-property.
Each of the other types of access involves changing the XML data, either by value
of some element or attribute, or its structure as in the cases of adding or removing
elements. Deletion of an element presents a number of issues. An element must only be
considered for deletion if it is accessible by the user in a read capacity – a user would
not realistically need to delete an element that the user is unaware of. So as with a read
access, the clearance of the user must dominate the path from the root to the element to
be deleted. A confidential user with no compartments would then only be allowed to
remove elements tagged with a like classification.
A further consideration involves the content associated with the element. The sensi‐
tivity of descendant elements to the deleted element must be considered to ensure only
appropriate data is removed. If the clearance of the user performing the deletion domi‐
nates the sensitivity of all child trees rooted at the element being deleted, there is no
potential for information flow down to lower levels, as any child elements would already
be unknown to lower level users. The deletion of an unknown element does not impact
a low level user.
If the element contains some child elements strictly dominating the user’s clearance,
however, the deletion cannot simply remove the element. As the deleting user does not
know of the existence of the higher level data, no judgment can be made by the user if
the higher level child elements are appropriate for removal. To resolve this situation, a
preserve attribute is used to mark the element to be deleted as removed. The setting of
this flag must propagate to all descendant elements matching the classification of the
deleted element. Once this has been set, the elements “deleted” by the user are no longer
visible to a user of that clearance, but remain visible to strictly dominating users. This
scenario is shown in Fig. 2, where a confidential user with no compartments has deleted
a child element or the root element. As this element has children which the user was not
cleared to view (and are thus unknown to the user), the present attribute is updated to
REMOVED, effectively removing the element rom the user’s view while retaining the
more sensitive child elements for higher cleared users.
With an update action, there are two possible scenarios for the update: either a value
associated with an element is being updated, or that of an attribute. In the first case, the
value of an element is changed (the value here being some child element or some inner
data, but not the tag itself). This operation is allowed for subjects with a clearance that
is the same as the classification of the element being updated – that is, the subject’s level
both dominates and is dominated by the level of the object. The path in this case must
allow the user to have read access to the element (as an update makes no sense for
something the subject cannot read), but does not necessarily determine the ability of the
subject to update the accessible element. This allows the value to be changed while
avoiding any downward flow of information, and prevents any “blind writes” into higher
level data that the subject should not have access to.
The second update scenario, where a subject attempts to update an attribute follows
the same logic as an element update, with a few conditions:
 UI Tags: Confidentiality in Office Open XML 29

1. The classification of the containing element determines the updateability of the

attribute.
2. The classification label attribute cannot be changed by a subject as this would repre‐
sent a potential downward flow of information.
3. Similarly, the compartment attribute cannot be changed.
4. The preserve attribute cannot be added or manipulated directly by users
A further concern here, as with delete, is the possibility of child elements of the
edited node that are of a higher classification than the clearance of the user. These chil‐
dren are not visible to the user and therefore subject to loss if we allow the edit to proceed.
To overcome this obstacle, we employ a series of steps:
1. Ensure both the simple security property and *-property hold for the node with
content being edited.
2. Examine the MaxDescendant values for affected child elements. Those with a value
that strictly dominates that of the edited element must be retained.
3. Set the preserve attribute to “REMOVED” of those elements with higher max
descendants that would be lost by the update.
4. Perform the update to the element, making certain that the “REMOVED” or domi‐
nating descendants are retained.
Following these steps, users can edit content of a node in the XML tree without the
worry that the edits of a low level might displace any child elements of a higher sensitivity.

5 UI Tags Phase 2

Since the early work of Kerr [20], UI Tags has been extended in a number of ways by
coordinated efforts in three different areas: (1) an early cooperative effort among Amack,
Bhaskar, and Kerr worked towards a foundational prototype system leveraging a native
XML database in which individual word processing documents are stored in compliance
with a MAC policy as their individual XML parts; (2) Amack’s work on a derivative clas‐
sification module that operates on documents as they are processed, adjusting tagged para‐
graphs as necessary based on their content as matched to a set of rules [22]; (3) Bhaskar’s
extension of the prototype, adding elements of attribute-based access control [23].
UI Tags Phase 2 work began by extending the Phase 1 tagging approach to OOXML
based word processing documents. Tagging occurs in the document.xml part at the para‐
graph level, largely as the concept of paragraph exists both in the text content of the
document and as a common element in the XML. Most content in the main body of text
within the document is contained within paragraph elements. Other more granular
elements could be used, though these do not necessarily relate to a logical unit of content
in the eyes of the user (text runs, for example, are used to distinguish separate editing
events or other application specific artifacts).
In addition to attaching compartments and labels to XML paragraph elements, a set
of tags appearing at the beginning of each paragraph’s text is also inserted. This allows
for persistence of tag information when the document is opened and subsequently saved,
30 L. Kerr

as any custom XML markup is removed by MS Word, per a court decision involving a
patent on custom XML in Word documents [24].
Using a database for backend storage of XML content led to the selection of native
XML database eXist-db [25]. With eXist-db, individual XML parts of an OOXML
document can be stored, queried, and retrieved using XPath [26] and XQuery [27]
expressions.
On a read request, each individual part of the document is retrieved from the database.
Once the document.xml part is obtained, a check of each paragraph is conducted,
ensuring the requesting user’s clearance dominates the classification of the paragraph.
If a paragraph is not dominated, it is removed from document.xml, resulting in a docu‐
ment containing only those paragraphs a user is allowed to view. In the event there are
no paragraphs viewable by the user, no document is returned.
This work provides limited support for edit operations. The prototype is able to
determine if change has occurred in a document using a fingerprint scheme similar to
Rönnau, Pauli, and Borghoff [18], though this only works on documents that are whole,
not in cases where the user is allowed a view of only a subset of the document. In cases
where the whole document is available, the edited version simply takes the place of the
original – no delta script is generated or applied.
In addition to this issue with change tracking and subsequent merging of different
versions, one other concern of interest was identified in the course of this work. First,
as mentioned by Lindholm [17], metadata management becomes an issue when merging
changes between versions of documents. This is further compounded by the security
policy. Document metadata may itself represent a leakage should higher level informa‐
tion be exposed. For example, a document containing paragraphs with a range of clas‐
sifications is edited by a high level user. If the metadata reflects this change to all users,
lower level users are able to view this and may infer the existence of nature of the higher
level insertion simply by having the identity of the higher level user.
Building on the UI Tags foundational prototype, Amack [22] developed a means of
building and applying derivative classification rules. These rules define specific strings and
the classification that paragraphs containing these strings must bear. The need for deriva‐
tive classification arises when new documents are created based on content in previously
classified documents, with the new content requiring classification in a like manner.
Derivative classification is governed by a classification guide that consists of a
number of classification rules established by an original classifier [21]. Each rule
contains a string that is associated with a specific classification. Should a paragraph
contain the indicated string, it is expected that paragraph will be assigned the indicated
classification. Amack established an XML format for classification rules in UI Tags [22].
Rule creation is facilitated for the original classifier by a rule builder. As rules are created,
they are appended to a rule file stored in eXist-db.
Derivative classification can occur when documents are uploaded to the server as
well as when read requests are submitted. In either case, each paragraph is inspected for
an occurrence of a classification string in the collection of rules. If a match is discovered,
a check for rule expiration is made. Non-expired matching rules result in a check for
dominance. Here only rules that result in a new classification that dominates the existing
classification are allowed. If the rule indicates a new classification that is non-dominating
 UI Tags: Confidentiality in Office Open XML 31

or non-comparable, the change is marked for review and an error condition explaining
the non-dominating result is logged. An original classifier must then review and resolve
these issues.
Bhaskar [23] introduced some elements of ABAC to UI Tags. Attributes in this
context represent further indicators that supplement the MAC labeling which could
include designations such as dissemination and export controls.
Facilitating these ABAC tags presents somewhat of a problem. While the document
is being stored and processed, these attributes can be stored in the XML, but for persis‐
tence (as they will be removed as custom XML) a new solution is necessary as the
addition of further text prepending each paragraph becomes somewhat unwieldy. To
resolve this issue, the use of endnotes is used here in conjunction with XML attribute
tags. Each paragraph still has the security label prefix on each paragraph, accompanied
by a reference to an endnote. In the endnote, where space and readability are not issues,
full details on the classification, compartments, and additional attributes are found,
allowing for persistence in a way that is familiar to the user. While this provides a means
of ABAC tagging, it does not use the tags in access control decisions.

6 Future Work

As UI Tags evolves, a number of areas for further work have emerged. While many of
the previously enumerated objectives have been satisfied with prior work, several critical
issues still remain. Among these are extending the MAC model to incorporate ABAC
features, particularly in how these attributes affect specifically MAC artifacts – the
simple security property, the *-property and polyinstantiation. In coordination with
extending this model, implementing the read, insert, update and delete operations with
support for ABAC constraints is also necessary.
Along with ABAC operation support, metadata management and change tracking
are critical. Metadata needs to be managed in such a way as to remain coherent and
consistent, but not leak any information to lower levels. While change tracking is
supported in a limited way, further work is necessary to adequately track changes under
security constraints.
Finally, dynamic document creation work must be completed, whereby a user is able
to submit a query, and a document containing relevant results is returned, consisting of
information pulled from various documents in the database. These dynamic documents
are subject to MAC and ABAC security constraints, as well as derivative classification,
and must show sources for all information retrieved.

References

1. Ecma, T.C.: Office Open XML (2006)

2. ISO/IEC 29500-1:2012 - Information technology – Document description and processing
languages – Office Open XML File Formats – Part 1: Fundamentals and Markup Language
Reference (2012). http://www.iso.org/iso/home/store/catalogue_ics/
catalogue_detail_ics.htm?csnumber=61750. Accessed 30 October 2014
32 L. Kerr

3. Bell, D.E., La Padula, L.J.: Secure computer system: Unified exposition and Multics
interpretation (1976)
4. Lunt, T.F.: Polyinstantiation: an inevitable part of a multilevel world. In: 1991 Proceedings
of Computer Security Foundations Workshop IV, pp. 236 –238 (1991)
5. Wiseman, S.: Lies, Damned Lies and Databases (1991)
6. Jin, X., Krishnan, R., Sandhu, R.: A unified attribute-based access control model covering
DAC, MAC and RBAC. In: Cuppens-Boulahia, N., Cuppens, F., Garcia-Alfaro, J. (eds.)
DBSec 2012. LNCS, vol. 7371, pp. 41–55. Springer, Heidelberg (2012)
7. Kuhn, D.R., Coyne, E.J., Weil, T.R.: Adding attributes to role-based access control. Computer
43(6), 79–81 (2010)
8. Wang, L., Wijesekera, D., Jajodia, S.: A logic-based framework for attribute based access
control. In: Proceedings of the 2004 ACM Workshop on Formal Methods in Security
Engineering, pp. 45–55 (2004)
9. Bobba, R., Fatemieh, O., Khan, F., Gunter, C.A., Khurana, H.: Using attribute-based access
control to enable attribute-based messaging. In: 2006 22nd Annual Computer Security
Applications Conference, ACSAC 2006, pp. 403–413 (2006)
10. Frikken, K., Atallah, M.J., Li, J.: Attribute-based access control with hidden policies and
hidden credentials. IEEE Trans. Comput. 55(10), 1259–1270 (2006)
11. Cirio, L., Cruz, I.F., Tamassia, R.: A role and attribute based access control system using
semantic web technologies. In: Meersman, R., Tari, Z. (eds.) OTM-WS 2007, Part II. LNCS,
vol. 4806, pp. 1256–1266. Springer, Heidelberg (2007)
12. Ecma Technical Committee 45, “Office Open Xml Overview.” Ecma International (2006)
13. Standard ECMA-376 (2012). http://www.ecma-international.org/publications/standards/
Ecma-376.htm. Accessed 30 June 2013
14. Khan, L., Wang, L., Rao, Y.: Change detection of XML documents using signatures. In:
Proceedings of Workshop on Real World RDF and Semantic Web Applications (2002)
15. Peters, L.: Change detection in XML trees: a survey. In: 3rd Twente Student Conference on
IT (2005)
16. Cobena, G., Abiteboul, S., Marian, A.: Detecting changes in XML documents. In: 2002
Proceedings 18th International Conference on Data Engineering, pp. 41–52 (2002)
17. Lindholm, T.: A three-way merge for XML documents. In: Proceedings of the 2004 ACM
Symposium on Document Engineering, pp. 1–10 (2004)
18. Rönnau, S., Pauli, C., Borghoff, U.M.: Merging changes in XML documents using reliable
context fingerprints. In: Proceedings of the Eighth ACM Symposium on Document
Engineering, pp. 52–61 (2008)
19. Rönnau, S., Philipp, G., Borghoff, U.M.: Efficient change control of XML documents. In:
Proceedings of the 9th ACM Symposium on Document Engineering, pp. 3–12 (2009)
20. Kerr, L.: Polyinstantiation in multilevel secure XML databases. MS Thesis, Department of
Computer Science, University of Idaho, Moscow, Idaho (2012)
21. Executive Order 13526- Classified National Security Information | The White House (2009).
http://www.whitehouse.gov/the-press-office/executive-order-classified-national-security-
information. Accessed 22 October 2014
22. Amack, A.S.: Automating derivative classification in multi-level secure documents. MS
Thesis, Department of Computer Science, University of Idaho, Moscow, Idaho (2014)
23. Bhaskar, D.V.: Software Design Specification for Storing Multilevel Secure XML for Easy
Retrieval. University of Idaho, Moscow (2014)
24. Microsoft Corp. v. i4i Ltd. Partnership - Supreme Court (2010). http://
www.supremecourt.gov/opinions/10pdf/10-290.pdf. Accessed 25 November 2014
 UI Tags: Confidentiality in Office Open XML 33

25. eXistdb - The Open Source Native XML Database. http://exist-db.org/exist/apps/homepage/

index.html. Accessed 22 October 2014
26. Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.F., Kay, M., Robie, J., Siméon, J.:
XML path language (xpath). In: World Wide Web Consort. W3C (2003)
27. XQuery 1.0: An XML Query Language (Second Edition) (2011). http://www.w3.org/TR/
xquery/. Accessed 25 November 2014
 The Search for Trust Evidence

David E. Ott ✉ , Claire Vishik, David Grawrock, and Anand Rajan

( )

Intel Corporation, Chandler, AZ, USA

{david.e.ott,claire.vishik,david.grawrock,anand.rajan}@intel.com

Abstract. Trust Evidence addresses the problem of how devices or systems

should mutually assess trustworthiness at the onset and during interaction.
Approaches to Trust Evidence can be used to assess risk, for example, facilitating
the choice of threat posture as devices interact within the context of a smart city.
Trust Evidence may augment authentication schemes by adding information
about a device and its operational context. In this paper, we discuss Intel’s 3-year
collaboration with university researchers on approaches to Trust Evidence. This
collaboration included an exploratory phase that looked at several formulations
of Trust Evidence in varied contexts. A follow-up phase looked more specifically
at Trust Evidence in software runtime environments, and whether techniques
could be developed to generate information on correct execution. We describe
various research results associated with two key avenues of investigation,
programming language extensions for numerical Trust Evidence and an innova‐
tive protected module architecture. We close with reflections on industry-univer‐
sity researcher collaborations and several suggestions for enabling success.

1 Introduction: The Problem of Trust Evidence

As the number and diversity of computing devices continues to grow at a rapid pace,
there is a need to develop more sophisticated frameworks for establishing trust between
interacting devices. Consider, for example, a set of Internet of Things (IoT) devices in
the context of a smart city. Devices under the control of a user may wish to connect with
peer devices offering information or other services. Likewise, service devices are
designed to connect with user devices, either peer-to-peer, directly, or through a
gateway. In general, user devices are frequently heterogeneous and the context of inter‐
action is dynamic. For example, mobility may enable a large number of devices to
interact in passing as users come and go.
Authentication is one means by which interacting systems may establish a trust‐
worthy relationship. By exchanging private information using a secure communication
protocol, a service device may identify a client device (and/or its user) in order to estab‐
lish trust. Similarly, a client device may use digital certificates or another means to
identify the service and establish trust with the service device. Cryptographic or trusted
computing methods may be employed to ensure the identification process is robust
against man-in-the-middle attacks, spoofing attacks, and other threats to the mutual
identification process.
Our reliance on authentication, however, is not without its problems. While authen‐
tication approaches may reliably establish the identity of a system and/or its user, they

© Springer International Publishing Switzerland 2016

K. Haltinner et al. (Eds.): CSS 2015, CCIS 589, pp. 34–45, 2016.
DOI: 10.1007/978-3-319-28313-5_3
 The Search for Trust Evidence 35

fail to assess whether the system involved is actually trustworthy. An obvious example
is a system infected with malware; while the user may successfully use the system to
connect with a service and pass authentication, the underlying device may independently
launch an attack against the interacting device, attempt to eavesdrop on private data
exchanges, or simply interfere with interaction between the devices. Perhaps less
obvious is a device that has been misconfigured, making it vulnerable to malicious
attacks or privacy breaches. For example, it may lack appropriate software updates or
fail to make use of antivirus software, operating system firewall features, or system
security policies. Also of concern are systems that have had failures or compromises
that leave them in an unknown state. A system may have sustained a breach by a network
bot leaving it in an ambiguous state of health or compromise. Or, a device may have
sustained a hardware failure (e.g., hard drive) leaving it in an unknown state that may
have security implications or be hard to distinguish from an overt attack.
Besides overlooking the operational state of a device, authentication commonly fails
to acknowledge different levels of trust and conditional trust, instead providing a single
barrier to entry and all-or-nothing access to promised services and interaction. Instead
of allowing provisional interaction until a system’s state and operational characteristics
can be verified, it ignores all considerations once authentication credentials can success‐
fully be delivered. One might imagine a more sophisticated scheme that requires addi‐
tional information about the type and state of the system that requests interaction. Simi‐
larly, one might image systems that don’t require authentication at all for non-private
services. However, a system requesting interaction must provide evidence of non-mali‐
cious intent and correct operation.
We refer to information beyond basic authentication credentials as Trust Evidence.
While the precise definition of Trust Evidence is an open research question, it might
include information about:
the authenticity of a device,
a platform’s configuration,
patterns of hardware and software operation with respect to normal behavior,
use of security policy or well-recognized security standards and levels,
mechanisms to protect stored secrets,
measures taken to insure message or data integrity, and
past event history, including remediation actions that have been taken.
Trust Evidence may be generated by request from a system wishing to interact, trans‐
mitted to the peer system for analysis, and then processed or consumed by the peer
system as part of its risk management framework. Two devices may mutually collect
Trust Evidence at the onset of an interaction, or periodically as an interaction proceeds
and enters different phases of data exchange, each with a different set of security consid‐
erations. For example, evidence of secure storage mechanisms may precede the
exchange of confidential information. Or, evidence of software updates and versioning
may precede software-based service interactions.
Trust Evidence may be used to establish whether a peer device or system is trust‐
worthy, to select a threat posture within an unknown or heterogeneous environment, to
dynamically assess the degree of trustworthiness of devices and systems as their software
36 D.E. Ott et al.

and operational environment changes, and to discover trustworthy devices and systems.
Trust Evidence may be seen as a companion to authentication approaches which are still
useful in establishing user or system identity, but which need additional mechanisms to
assess the actual system participating in the interaction.
Trust Evidence includes many open questions to be investigated by researchers
exploring the boundaries of what is possible and desirable in a crowded world of new
devices and device types. How might Trust Evidence be defined? How should Trust
Evidence be created and transmitted? How might Trust Evidence be consumed? Should
Trust Evidence be produced on the fly or stored by a device for future queries? Could
Trust Evidence be obtained and stored by a third party who provides profiles as an
information service? What is the life span of Trust Evidence? When does Trust Evidence
fail to be useful since system and device operation is dynamic and information can
become outdated?

2 Exploratory Research

To better understand how Trust Evidence might be formulated and applied to real-world
scenarios, Intel sponsored a 1-year university research effort involving several academic
teams. Such programs are often referred to by Intel as seedlings since preliminary
research is needed to better identify the right questions to ask and the most promising
approaches for further investigation. In many ways, such programs help to grow the
maturity of a research area and better position subsequent researchers for developing
usable results.
Research by University of North Carolina [1, 2] looked at techniques for game oper‐
ators to validate the behavior of game clients in terms of valid execution paths. Their
approach makes use of symbolic execution to extract constraints on client-side state as
implied by client-to-server messages. Researchers then use constraint solving to deter‐
mine whether the sequence of client-to-server messages can be verified given possible
user inputs, and in light of the server-to-client messages already received. The approach
implies that Trust Evidence may be inferred using symbolic execution of known sources
code and message histories that either follow or fail to follow expected execution
sequences.
Research by UC Berkeley [3] considered the use of a new program representation
referred to as a hybrid information- and control-flow graph or HI-CFG. The represen‐
tation may be used to study program inputs as they go through complex transformations
in order to understand when a system is being manipulated by an attacker and when it
is functioning as expected. Researchers leverage this structural understanding to scale
program analysis beyond what is feasible with monolithic symbolic execution. The
approach uniquely combines both control- and data-flow aspects of a system binary as
it executes, and researchers show the efficacy of their approach for applications like a
PDF viewer and a word processor. The framework might be used to generate Trust
Evidence both within the context of a single system, and by an interacting system that
shares a copy of the HI-CFG for a given piece of software.
 The Search for Trust Evidence 37

Research by Dartmouth College [4] looked at how real-world information security

practitioners, both developers and security officers, lack the appropriate policy language
to provide clear, intelligible, and machine-actionable descriptions of trustworthy
behavior. They propose three policy primitives: compositional reasoning, counting
primitives, and isolation primitives as SELinux extensions and provide two case study
policies to communicate expected process behavior and trust-altering process events.
Continued work looks at refining proposed extensions into more formal policy languages
and developing quantitative and qualitative metrics to evaluate relative effectiveness in
increasing system trustworthiness. The policy language may be used to define and
exchange Trust Evidence between interacting systems.
Finally, University of Washington researchers [5] considered interacting devices in
the context of a consumer home, including desktops, laptops, wireless routers, televi‐
sions, gaming consoles, appliances, healthcare devices, children’s toys, and various
home automation and infrastructure devices. After cataloging potential attack types and
vectors, they present a framework for thinking about device security and risk assessment.
The framework includes device security goals (privacy, availability, command authen‐
ticity, and execution integrity), digital data goals (privacy, integrity, and availability),
and environment goals (environment integrity, activity pattern privacy, sensed data
privacy, and sensor validity). Trust Evidence may be defined using their framework, and
risk assessment may follow from whether sufficient evidence has been provided to insure
each of these aspects.

3 Trust Evidence for Software Runtime Environments

A key outcome of seedling research was the realization that Trust Evidence requires the
ability to verify the correct execution of system and application software, and that
execution predictability was a central issue.
On the one hand, a framework was needed that could evaluate whether the behavior
of a device, directed by system or application software, followed an accepted path or
pattern of behavior that is expected. This idea within the program became known as
baselining. Baselining captures the notion that despite considerable complexity,
security-critical execution sequences often follow predictable patterns of control-flow
behavior, for example, executing frequent user functions or standard system protocol
sequences. This predictability might be captured and used to assess the behavior of a
device or system at runtime, and to generate Trust Evidence for system state, operation,
and configuration.
The notion of baselining is similar to that of control-flow integrity [6] in that it
examines the flow of instructions and control at runtime. But while CFI, which makes
use of control-flow graphs (CFG), binary analysis, execution profiling, and sometimes
static analysis, is interested in strictly enforcing acceptable paths of execution, base‐
lining is a coarser approach that aspires to be more practical. That is, a multiplicity of
approaches may be used to define execution reference points, and the goal is to generate
evidence of trustworthy execution rather than enforce strictly defined execution paths.
In baselining, the degree of conformance to a baseline is an indicator of trustworthiness
Other documents randomly have
different content
The text on this page is estimated to be only 26.81%
accurate

236 Notes on p. 33. ' Far-fetcht and dear-bought.' the end

to restore health to the business interests of the country — not the
feverish speculative activity that followed the war, and continued
until the crash of 1873, but a condition of moderate and reliable
prosperity. People are adapting their habits to their reduced incomes,
are denying themselves useless luxuries, and are discovering that
they can live just as comfortably with less outside display. The
importations of foreign goods have fallen largely, and for the first
time in sixteen years the balance of trade is in favour of the United
States, a calamity to the importers, no doubt, but a benefit to the
country at large. Fewer velvets, laces, diamonds, WortJis dresses,
French wines, and gimcracks are brought across the Atlantic, but no
political economist will see anything but a hopeful sign in that
fact."— Daily News, Oct. 5, 1876, p. 6, col. I, United-States'
Correspondent. p. 33, 1. 16 ; p. 65, 1. 16: far ref etched and deare
boughte is good for Ladyes : — " Mendoza. What shape ! Why, any
quick-done fiction . . . some such anything. Some far-fet trick good
for ladies, some stale-toy or other, no matter so 't be of our
devising." — Marston & Webster's Malcontent, V. ii., Webster's
Works, ed. Dyce, 1857, p. 358, col. 2. Dyce notes far-fet, i. e. far-
fetched. An allusion to the proverb, "Far-fet is good for ladies." So in
Jonson's Cynthia's Revels, Act IV. sc. i, " Marry, and \h.\$ may \>Q
good for tis ladies ; for it seems 'tis far-fet \>y their stay." See my
Tell-Troth, p. 6, 1. 7, & Stafford, N. Sh. Soc. p. 106 ; also Lyly's
Euphues, p. 33, 'far fet, and dere bought, is good for ladies.' Again :
— " Mineuer. God neuer gaue me the grace to be a Lady, yet I haue
all implements belonging to the vocation of a Lady. Sir Vaughan. I
trust, mistris Mineuer, you han all a honest oman shud haue.
Mineuer. Yes perdie, as my Coach, and my fan, and a man or two
that serue my turne, and other things which Ide bee loath euery one
should see, because they shal not be common. I am in manner of a
Lady in one point. Sir Vaughan. I pray, mistris Mineuers, let vs all see
that point for our better understanding. Mineuer. For I ha some
thinges that werefetcht (I am sure) v&farre as some of the Low
Countries ; and I payde sweetly for them too ; and they tolde me
they were good for Ladies." 1602. — T. Dekker, Satiromastix. Works,
1873, i. 204. See too Latimer's use of the phrase, p. 254 below. p.
33, p. 52. Pride in England. Peasants^ dress <3° extravagance. The
pride of "And the pride of England is, as it were, set up upon the
highest England mountain of the world, seen and scorned even of
the very infidels of the earth : such as know not God make marvel of
our monstrous attire, which exceedeth not only in cost and colour,
but in weight and fashion. O pull it down : it is not fit for such as are
taking the way to the kingdome of heaven ; it agreeth not with the
guest which lodgeth in us the Spirit of God ; it is no fit ornament to
deck the house of our silly souls, for it stinketh and pollutetli all
corners of the house. O remove it, and send every country his
fashion again : be not beholden to any nation for such trumpery,
neither to the garment-maker, whose study therein, though it please
the vain-glorious for a time, it will bring repentance, too late, to the
work and the workman. It is from the court come
The text on this page is estimated to be only 26.40%
accurate

Notes on pp. 33 — 42. 237 into the country, a dangerous

evil, and hath infected the poor ploughman, that a year's wages
sufficeth not one suit of attire. If I should tell all, T,he carte and ...
ploughman exceedthe carter would step in with his courtly gards,
and will defy eth in pride him that is not of the fashion ; men and
women, the rich and the poor, the old and the young, are too far
gone in this sickness : the Lord give a timely medicine lest we perish
therein." 1596. — J. Norden, Progress of Piety (Parker Soc.), pp.
172-3. Compare also the Surveyor John Norden (is he the same as
the writer of the religious tracts?) :— "where in those days [Henry
VI's] Farmers and their wiues were content with meane dyet and
base attire, and held their children to some austere gouernment,
without haunting Alehouses, Tauerns, Dice, Cards, & vaine delites of
charge, the case is altred : the Husbandman will be equal to the
Yoman, the Yoman to the Gentleman, the Gentleman to the Squire,
the Squire [to] his Superiour, and so the rest, euery one so farre
exceeding the corruptions [? consumptions] held in former times,
that I will speake without reprehension, there is at this day thirty
times as much vainely spent in a family of like multitude and quality,
as was in former ages whereof I speake." 1607. — John Norden, The
Surueyors Dialogue, p. 14. p. 36, 1. 12: his wife her perswasions.
See note on p. 36, 1. 3, of Tell Troth New Sh. Soc.— S. p. 36, 1. 10
from foot : some are so brasen faced
The text on this page is estimated to be only 25.29%
accurate

238 Notes on pp. 42 — 49. Meris Dress, Starch, &c. And,

but his heire loue vertu, as did he, He nis not gentille, thouhe him
riche seme, Al were he mytre, corone, or diademe." 1 The idea of
course is not new. It is found frequently enough in the Greek & Latin
literature. It occurs, we believe, for the first time in the fragments of
Epicharmus : — dya06f 8' dvijp Kaj>' 'A.i9io4> icai SovXos, ivyfvij£
tv and afterwards it is found in Euripides, Horace, Juvenal, — "
Stemmata quid faciunt ?" and lastly in Seneca. Doubtless Jean de
Meung took it from Seneca.' — W. Besant, in the British Quarterly
Review, Oct. 1871, p. 388. See Shakspere's Meas. for Meas. ,
Tennyson's Lady Clara Vere de Vere, &c. p. 43, 1. 14 : tagge and
ragge. Compare John Partridge in The Worthie Historie of . .
Plasidas, 1566, "To walles they go, both tagge and ragge, Their citie
to defende," and the other quotations in Mr. H. B. Wheatley's Diet, of
Reduplicated Words, Philolog. Soc. 1865, p. 85-6. p. 44. Pride &>
Apparel. — See Chaucer's Parson's Tale ( Works, ed. Morris, iii. 296-
8) on Pride, as shown " in superfluite of clotheynge " in his day, the
embroidering, indenting, waving, furring, chisel-punching, dagging,
of gowns, their trailing in the mire ; the short coats and tight parti
colourd hose or breeches showing the shameful members of man,
and making em look as if flayn, &c. &c. See also Piers Plowman,
Roberde of Brunne's Handlyng Synne, &c. p. 49, 1. 5 ' abhorring the
Christian povertie, &c. " Be rich, I say ; nay boy, be rich and wise !
Gold is an actious [so] mettle for the eyes . : -' Why ? rich men haue
much monie and gaie geare, And goodly houses, and most daintie
cheare ; Faire wiues, fine pictures, playes and morris-dances, And
many cheates, that come by many chances ; Fine Ciuet-boxes, sweet
perfumes, and waters, And twentie other such kind of matters. While
the poore man, that pines for want of friends, May sit and sigh, and
picke his fingers ends, And euery morning wash his face with teares,
And wipe his blubbered cheekes with sheualed heares. It is a heauie
sence, where coyne is wanting ; At such a time of care, friends are
scanting. 5: 1613- — The Vncasing of Machivils Instructions to his
Sonne, p. 22. p. 52, 1. 6 : liquide matter which they call Starch.
Howell relates that Mrs. Turner, the poisoner of Sir Thomas
Overbury, "the first inventress of yellmo Starch was executed in a
Cobweb Lawn Ruff of that colour at Tyburn ; and with her I believe
that yellow Starch, which so much disfigured our Nation, and
rendered them so ridiculous and fantastic, will receive its Funeral."
— E.pistol
The text on this page is estimated to be only 26.88%
accurate

Notes on pp. 49, 60. Merfs Dress. 239 p. 53, last line : if
they stand uppon their pantoffles. See notes in Tell Troth on p. 55,
last line. — S. MEN'S ABSURD DRESS, &c. See Harrison's amusing
Chapter 7, in his Book II, our Part I, p. 167 ; Father Hubburds Tales
at the end of Dyce's Middleton, vol. v, &c. p. 49, 60. Spanish,
French, &•* Dutch fashion. Men's changeable fashions and Women's
extravagant dress also movd Schoolmaster Averell to wrath in 1588.
In his "A meruailous combat of contrarieties. Malignantlie striuing in
tht members of mans bodie allegoricallie representing vnto vs the
enuied state of our florishing Common wealth : ivherin dialogue-wise
by the way, are touched the extreame vices of this present time, &c.
&c. by W. A." he makes "The Bellie" say (sig. B. I & 2) : — " Why,
had euer Premetheus more shapes, then the backe sutes ? or ye
Hydra more new heads then the back new Garments ? not so
variable for their matter, as changable for their fashion : to daie
French, to morrowe English, the next day Spanish, to daie Italianate,
to morrow for fashion a deuill incarnat, O tempora, o mores! To daie
you shine in sutes of silke, to morrow you iet it out in cloth of Golde,
one daie in blacke for show of grauitie, an other daie in white in
token of brauerie, this day that cullour, the next day another, nowe
short wasted, anon long bellied, by and by after great Buttoned, and
straight after plaine laced, or els your Buttons as strange for
smalnes, as they were monstrous before for greatnes, this yeere
bumbd like a Barrell, the next shottend like a Herring, nowe your
hose hang loose like a bowe case, the next daie as straite as a
pudding skinne, one while buskind for lack of stocks, another while
booted for want of shooes, and thus from you that are the grand
Maister, doo the inferiour members fetch their fashions, & these be
the mutabilities of men," [The continuation of the passage, on
Women, is on p. 253, below.] See too Burton's Anatomy of
Melancholy, Part III. Sect. 2, Memb. 3, subs. 3, "Artificial
Allurements," p. 295 of edition 1676 : — "Women are bad, & men
worse; no difference at all betwixt their & our times. Good manners
(as Seneca complains) are extinct with wantonness: in tricking up
themselves men go beyond women, they wear harlots colours, and
do not walk, but jet and dance, hie mulier, hac vir, more like Players,
Butterflies, Baboons, Apes, Anticks, than men. So ridiculous
moreover are we in our attires, and for cost so excessive, that as
Hierom said of old, ' Vno filo villarum insunt pretia, uno lino decies
sestertiiim inseritur ' ; 'tis an ordinary thing to put a thousand Oaks,
& an hundred Oxen into a suit of apparel, to wear a whole mannor
on his back. What with shoo-ties, hangers, points, caps and
feathers, scarfs, bands, cuffs, &c., in a short space their whole
patrimonies are consumed." Compare also Harrison, Pt. I. p. 343,
and Shakspere, in Henry VIII, I. i. 80-85, ' many Have broke their
backs with laying manors on 'em For this great journey,' &c. Also in
Hislrio-mastix, by Peele and Marston, 1590-1600, pr.
The text on this page is estimated to be only 26.42%
accurate

240 Notes on pp. 49, 50. Mens Hats, &c. 1610, we find the
Serving man saying to his master (School of S ha kspere, ii. 47) : —
" We breake your backs? No ! 'tis your rich lac'd sutes, And straight
lac'd mutton : those break all your backs. " See too in * A
Supplycacyon to . . Kynge Henry the Eyght,' 1544 (E. E. T. Soc.,
1871, p. 52) : "Is there not suche excesse and costelynes of apparel
/ bycause of dyueryte and chaurcge of fasshyons, that scarce a
worshipfull mans landes, which in tymes paste was wonte to fynde
and maynteyne twenty or thirty tall yowemen / a good plentyfull
howsholde for the releyfe and comforte of many poor and neadye /
and the same nowe is not suffycyent and able to maynteyne the
heyre of the, same landes / his wiffe/ her gentle woman or mayde /
two yowmen / and one lackey ? The pryncypall cause herof is their
costly apparell / and specially their manyfolde and dyuerse chaunges
of fasshyons whiche the man, and specially the woman, muste
weare vpon bothe headde and bodye. Somtyme cappe / somtyme
hoode / nowe the Frenshe fasshyon, nowe the Spanyshe fasshyon ;
than the Italyan fasshyon / and then the Myllen fasshyon ; so that
there is noo ende of consumynge of substaunce . . and all to please
the prowde folyshe man and womans fantasye. Hereof spryngethe
great myserye and neede." See too the Note for p. 53, 1. 4-6, p.
245, below. p. 49, 1. 9: one sute for the forenoone, &c. See the note
from Bp. Pilkington (for p. 58), p. 248, below. p. 50: hats, standing
collars, ruffs, shoestrings, &c. " Good Card-makers (if there be any
goodnes in you) Apparrell vs with more respected Care, Put vs in
Hats, our Caps are worne thread-bare, Let vs haue standing Collers,
in the fashion : (All are become a stiffe-necke generation) Rose Hat-
bands, with the shagged-ragged- Ruffe : Great Cabbage-
shooestrings (pray you bigge enough) French Doublet, and the
Spanish Hose to breech it : Short Cloakes, like old Mandilions (wee
beseech it) Exchange our Swords, and take away our Bils, Let vs
haue Rapiers, (knaues loue fight that kils1) Put vs in Bootes, and
make vs leather legs, This, Harts most humbly, and his fellowes,
begs." 1612. — Samuel Rowlands, The Knave of Harts (1874,
Hunterian Club, p. 12-13). The dress obtaind is describd in
Rowlands's More Knaues yet ? (1611 ?) sign. A 4 (ed. 1874 and p. 5)
: — ". . now the honest Printer hath bin kinde, Bootes, and Stockins,
to our Legs doth finde, Garters, Polonia Heeles, and Rose Shooe-
strings, Which somwhat vs two Knaues in fashion brings . . . 1 See
the extract from Howes, in Harrison, Pt. II, p. 31*.
The text on this page is estimated to be only 27.29%
accurate

Notes on pp. 50, 51. Meiis Feathers, &c. 241 Well, other
friends I hope we shall beseech For the great large abhominable
breech Like Brewers Hopsackes : yet, since new they be, Each knaue
will haue them, and why should not wee ? Some Laundresse we also
will entreate For Bands and Ruffes .... Scarffes we doe want to
hange our weapons by ... hats of newest blocke " . . p. 50. Hat &
feathers, &c. " His hat, himselfe, small crowne and huge great brim,
Faire outward show, and little wit within. And all the band vfth
feathers he doth fill, Which is a signe of a fantastick still, As sure as
(some doe tell me) evermore A goate l doth stand before a brothell
dore. His clothes perfum'd, his fustic mouth is ayred, His chynne new
swept, his very cheekes are glared." 1598.— Jn. Marston, Satyre III.
Works, 1856, iii. 223-4 : see p. 216 too. p. 51: feathers, wings,
breeches, cloak, rapier, hangers, boots, spurs. The dress of a young
dandy in 1604 is thus described by T. M. in his Father Hubburds
Tales, reprinted (in modern spelling) at the end of vol. v. of Dyce's
ed. of Middleton's Works, as probably Middleton's. " At last, to close
up the lament able tragedy of us ploughmen, enters our young
landlord, so metamorphosed into the shape of a French puppet, that
at the first we started, and thought one of the baboons had
marched-in in man's apparel. His head was dressed up in white
feathers like a shuttlecock, which agreed so well with his brain,
being nothing but cork, that two of the biggest of the guard might
very easily have tossed him with battledores, and made good sport
with him in his majesty's great hall. His doublet was of a strange cut
; and shew the furye of his humour, the collar of it rose up so high
and sharp as if it would have cut his throat by day light. His wings,2
according to the fashion now, were as little and diminutive as a
puritan's ruff, which shewed he ne'er meant to fly out of England,
nor do any exploit beyond sea, but live and die about London,
though he begged in Finsbury. His breeches, a wonder to see, were
full as deep 3 as the middle of winter, or the roadway between
London and Winchester, and so longe and wide withal, that I think
within a twelvemonth he might very well put all his lands in 1 The
emblem of lechery, as the sparrow also was. See the picture of
Lechery in the Cambr. Univ. Library's MS. Gg. 4. 27, Chaucer's
Parson's Tale, autotyped for the Chaucer Society. 2 See p. 524,
Dyce's Middleton, v: T. M.'s Blacke Booke, 1604: "apparel led in
villanous packthread, in a wicked suit of coarse hop-bags, the wings
and skirts faced with the ruins of dishclouts." ' Wings, lateral
prominencies extend ing from each shoulder.' Whalley's note on B.
Jonson's Works, ii. 103, ed. Giff. 3 * They strangle and cloke more
velvet in a deep-gathered hose, than would serve to line through my
lord What-call-ye-him's coach.' 1604. — T. M., Blacke Booke. Dyce's
Middleton, v. 524. SHAKSPEBE'S ENGLAND : STUBBES. 16
The text on this page is estimated to be only 27.25%
accurate

242 Notes on p. 51. A Dandy s Dress in 1604. them ; and

then you may imagine they were big enough, when they would out
reach a thousand acres : moreover, they differed so far from our
[old] fashioned hose1 in the country, and from his father's old
gascoynes,2 that his back-part seemed to us like a monster ; the roll
of the breeches standing so low, that we conjectured his house of
office, sir-reverence,3 stood in his hams. All this while his French
monkey bore his cloak of three pounds a yard, lined clean through
with purple velvet,4 which did so dazzle our coarse eyes, that we
thought we should have been purblind ever after, what with the
prodigal aspect of that and his glorious rapier and hangers all bost [
= embosstj with pillars of gold, fairer in show than the pillars in
Paul's or the tombs at Westminster ; beside, it drunk up the price of
all my plough-land in very pearl, which stuck as thick upon these
hangers as the white measles upon a hog's flesh. When I had well
viewed that gay gaudy cloak and those unthrifty wasteful hangers, I
muttered thus to myself : * That is no cloak for the pain, sure ; nor
those no hangers for Derrick ' ; when of a sudden, casting mine eyes
lower, I beheld a curious pair of boots of king Philip's [= Spanish]
leather, in such artificial wrinkles, sets and plaits, as if they had been
starched lately and came new from the laundress's, such was my
ignor ance and simple acquaintance with the fashion, and I dare
swear my fellows and neighbours here are all as ignorant as myself.
But that which struck us most into admiration : upon those
fantastical boots stood such huge and wide tops, which so
swallowed up his thighs, that had he sworn as other gallants did,
this common oath, 'would I might sink as I stand!' all his body might
very well have sunk down and been damned in his boots. Lastly he
walked the chamber with such a pestilent gingle 5 that his spurs
oversqueaked the lawyer, and made him reach his voice three notes
above his fee ; but after we had spied the rowels of his spurs, how
we blest ourselves ! they did so much and so far exceed the
compass of our fashion, that they looked more like the forerunners
of wheel barrows. Thus was our young landlord accoutred in such a
strange and prodigal shape [= dress] that it amounted to above two
years' rent in apparel." — T. M. The^Ant and the Nightingale, or
Father Htibburds Tales, 1604. " Asper . . But that a rook, by wearing
a pyed feather, The cable hatband, or the three-piled ruff, A yard of
shoe-tye, or the Switzer's knot 1 breeches. 2 galligaskins. 3 See
note, Dyce's Middleton, ii. 227. 4 "There is no fool to the satin fool
the velvet fool, the perfumed fool ; and therefore the witty tailors of
this age put them, under colour of kindness, into a pair of cloth
bags, where a voider will not serve the turn." 1602. — Return from
Parnassus. Hazlitt's Dodsley, ix. 184. 6 ' Caused by the large loose
rowels which are presently mentioned ; they were commonly of
silver. ' Compare — 11 Fastidious Brisk. . . my gray hobby . . a fine
fiery little slave, he runs like a — oh, excellent, excellent — with the
very sound of the spur. Carlo. How ! the sound of the spur ? Fast. O,
it's your only humour now extant, sir : a good gingle, a good gingle."
1599. — Ben Jonson, Every Man out of his Humour , II. i., Works, i.
80, col. 2 ; and in II. ii. p. 93, col. 2 : " Fungoso. I had spurs of mine
own before, but they were not ginglers."
The text on this page is estimated to be only 26.41%
accurate

Notes on p. 51. Bandless hats, &c. 243 On his French

garters, should affect a humour ! O, it is more than most ridiculous."
Ben Jonson, Every Man out of his Humour (acted 1599). Induction,
Works, ed. Cunningham, i. 67, col. I. See the Cap's complaint about
the Feathers stuck in him in "A Pleasauntf Dialogue or Disputation
betiueene the Cap,\ and the Head. I" 1564, quoted in my Thynne's
Animadversions (E. E. T. Soc. ), p. cxxxi. p. 51, 1. 3 : hats without
bands ; feathers in hats, scarfs, &c. " EPIGRAMS. Epig. 27. Aske
Humors, why a Feather he doth weare ? » It is his humor (by the
Lord) heele sweare. Or what he doth with such a Horse-taile locke ?
Or why vpon a Whoore he spendes his stocke ? He hath a Humor
doth determine so. Why in the Stop-throate fashion doth he go, With
Scarfe about his necke ? Hat without band ? It is his humor, sweete
sir, vnderstand . . . Obiect, why Bootes and Spurres are still in
season ? His Humor answeres : Humor is the reason. If you perceiue
his wittes in wetting shrunke, It commeth of a Humor, to be drunke.
When you behould his lookes pale, thin, and poore, Th' occ[a]sion is,
his Humor, and a Whore : And euery thing that he doth vndertake, It
is a vaine, for sencelesse Humors sake. " 1600.— S. Rowlands, The
Letting of Humours Blood in the Head- Vaine, sign. C (ed. 1874, p.
33). p. 51, &c. : dress, & starcht ruffs 6° rabatos, — "There was
then [in Adam's days] neither the Spanish slop, nor the skipper's
galligaskin, the Switzer's blistered codpiece *, nor the Danish sleeve
sagging down like a Welsh wallet, the Italian's close strosser, nor the
French standing collar : your treble-quadruple daedalian ruffs, nor
your stiffnecked rabatos, that have more arches for Pride to row
under than can stand under five London bridges, durst not then set
themselves out in print, for the patent for starch could by no means
be signed. Fashions then was counted a disease, and horses died of
it 2 ; but now, thanks to folly, it is held the only rare physic, and the
purest golden asses live upon it." 1609.- T. Dekker. Guls Hornbook,
ch. i., ed. 1862, p. 8. 1 See Coryafs Crudities on this. Rowlands
makes it Danish: — " His faces chiefest ornament, is nose, Full
furnished with many a Clarret staine, As large as any Codpiece of a
Dane, Embossed curious : " 1600. — S. Rowlands, Letting of
Humours Blood, sign. D 3 (1874, p. 53). a Lobado en el cuerpo,
bunches in the flesh, the fashion in a horse, Tuber struma. 1591. R.
Perciuale. Spanish Diet. ' Ldbado, m. bunches in the flesh' a disease
in a horse, called the fashions.' 1623. Jn. Minsheu's enlargd
Perciuale'
The text on this page is estimated to be only 26.80%
accurate

244 Notes on pp. 51, 52. Men's Bands, &c. p. 51. Ruff &>
Band, &c. (See p. 259 below, note on p. 70-1.,) " Behold, at length
in London streetes he showes. His ruffe did eate more time in
neatest setting, Then Woodstocks worke in painfull perfecting; It
hath more doubles farre than Ajax shield, When he gainst Troy did
furious battle weild. Nay, he doth weare an embleme bout his neck ;
For under that fayre rtiffe so sprucely set, Appeares a. fall, ^.falling-
band forsooth ! O dapper, rare, compleate, sweet nittie youth ! Jesu
Maria ! How his clothes appeare Crost and recrost with lace ! sure,
for some feare Least that some spirit with a tippet mace Should with
a gastly show affright his face." 1598.— Jn. Marston, Satyre III.,
Works, 1856, Hi. 223. p. 52. "Lambskin. My father was a starch-
maker, and my mother a laun dress ; so, being partners, they did
occupy 1 long together before they were married ; then was I born."
1632. — Win. Rowley, A Woman never vexed, in Hazlitt*s Dodsley,
xii. 137. p. 52, second side-note : Euery pesant hath his stately
bands. See Fairholt's capital quotations in Hist, of Costume in
England, p. 216, from Lodge's Wits Miserie, 1596, and Euphttes
Golden Legacie, 1592. The first is, "The plowman, that in times past
was contented in russet, must now a daies have his doublet of the
fashion, with wide cuts, his garters of fine silk of Granada, to meet
his Sis on Sunday. The farmer, that was contented in times past with
his russet frock and mockado sleeves, now sells a cow against
Easter, to buy him silken geere for his credit." See too in Harrison,
II, 36*, what Howes says : " men of meane ranke weare Garters
and shooe Roses, of more then fiue pound price ; and some weare
scarffes from ten pounds a piece, vnto thirtie pounds or more. The
like may be truly said concerning wrought Wastcoates." The dresses
of a smart Tailor (p. 19), a Baker (p. 29), a Dancing-master, and a
Vintner (p. 30), a Grasier (p. 31), an Informer (p. 32), a
Husbandman (p. 33), a Cumberland copyholder's family (p. 35), are
described in The Debate between Pride and Loivliness wrongly
ascribed to Francis Thynne, old Shakesp. Soc. 1841. The author has
15 men on his Jury, and rejects 3 : Greene, in his prose Quip for an
Upstart Courtier, which was modelled on the earlier poem, has 24
men in his Jury, and rejects 27 : this Quip should be read for its
sketches of the characters. See my Trial- Forewords to my Six- 7"ext
of Chaucer's Canterbury Tales, p. IOI-2. 1 ' Enjoy, in the sense of a
man having knowledge of a woman. Doll Tearsheet says of Pistol, in
the Second Part of Henry IV, ' ' These villains will make the word '
captain ' as odious as the word occupy, which was an excellent good
word before it was ill-sorted." See Nares, edit. 1859 in v. ; and Percy
Folio MS. Loose and Humorous Songs, p. 29.'
The text on this page is estimated to be only 26.35%
accurate

Notes on p. 53. Cost of Men s Dress, &c. 245 p. 53, I. 4-6:

result of extravagance in dress, &c : — "yet take . . the cost with the
pleasure, and tell me then if once In seauen yeares, when your state
is weakened and your Land wasted, your Woods untimbered, your
Pastures vnstored, and your Houses decayed : then tell me whether
you find the prouerbe true, of the Courtier young and old." 1 1618.
— N. Breton, The Court and Country (1868), p. 178. See too the
interesting « Health to the Gentlemanly profession of SeruingmenJ
by I. M., 1598, in the same vol. Hazlitt's Inedited Tracts, 1868, p. 95
; also, Quips upon, Questions, 1600, sign. G 2. " Carlo. — First, to be
an accomplished gentleman, that is, a gentleman of the time, you
must give over housekeeping in the country, and live altogether in
the city amongst gallants ; where, at your first appearance, 'twere
good you turned four or five hundred acres of your best land into
two or three trunks of apparel." 1599. — Ben Jonson, Every Man out
of his Humour, I. i., Works, ed. Cunning ham, i. 73, col. I. In II. i, p.
87, col. 2, Fungoso puts the cost of his suit at about ,£40 of our
money; "Let me see, the doublet: say fifty shillings the doublet ; and
between three or [= and] four pound the hose ; then boots, hat,
and band : some ten or eleven pound will do it all, and suit me, for
the heavens." 1596-8. — Ben Jonson, Every Man in his Humour, II.
ii., Works, ed. Cunning ham, i. 21, col. I. p. 53 : shirts. When
Fastidious Brisk is describing the articles of his dress injured in his
duel, in Ben Jonson's Every Man out of his Humour (acted A.D. 1599
; 410. 1600, fol. 1616), IV. iv, Carlo says, " I wonder he speaks not
of his wrought shirt " [he does, 14 lines lower] ; and Gifford notes :
" The linen, both of men and women, was either so worked as to
resemble the finest lace, or was ornamented, by the needle, with
representations of fruits, flowers, passages of history," &c. The
Puritans, it appears, turned the mode to account, and sub stituted
texts of Scripture for the usual embellishments. There is a pleasant
allusion to this practice in the City Match : " Sir, she's a Puritan at
her needle too : My smock sleeves have such holy embroideries, And
are so learned, that I fear in time All my apparell will be quoted by
Some pure instructor." Works, ed. Cunningham, i. 120, Act II, sc. ii.
In Ben Jonson's Every Man out of his Humour (1590) Puntarvolo
describes his dress in the account of his duel with Luculento: "He
again lights me here,— 1 " And if thou be a Courtier, know thy place
: But do not serue for onely shew of grace, But let thy profit
answere thy expence, Least want do proue a wofull patience, And
thou do proue the prouerbe often tolde, ' A carelesse Courtier yong,
a Begger olde.' " 1613. — The Vncasing of Machivils Instructions to
his Sonne : With the Answere to the same, p. 7.
The text on this page is estimated to be only 26.26%
accurate

246 Notes on pp. 54-6. Mens Doublets, Canions, &c. I had

on a gold cable hatband, then new come up, which I wore about a
murrey French hat I had, — cuts my hatband, — and yet it was
massy goldsmith's work — cuts my brims, which, by good fortune,
being thick embroidered with gold twist and spangles, disappointed
the force of the blow : nevertheless it grazed on my shoulder, takes
me away six purls of an Italian cut-work band I wore, cost me three
pound in the Exchange but three days before . . . He, making a
reverse blow, falls upon my embossed girdle — I had thrown off the
hangers 1 . . strikes off a skirt of a thick-laced satin doublet I had,
lined with four taffatas, cuts off two panes embroidered with pearl,
rends through the drawings-out of tissue, enters the linings, and
skips the flesh . . . not having leisure to put off my silver spurs, one
of the rowels catched hold of the ruffle 2 of my boot, and being
Spanish leather, and subject to tear, overthrows me, rends me two
pair of silk stockings that I put on, — being somewhat a raw
morning, — a peach colour and another, and strikes me some half
inch deep into the side of the calf ; he . . takes horse, and away ; I,
having bound up my wound with a piece of my wrought shirt . . rid
after him." Act IV. sc. iv. Works, ed. Cunningham, i. 119, col. 2. p.
54: men tender now. — Cp. Harrison, Part I, p. 337-8, "when our
houses were builded of willow, then had we oken men ; but now
that our houses are come to be made of oke, our men are not onlie
become willow, but a great manie . . altogither of straw," &c. p. 55.
Dublets -with great bellies. " Fungoso. look you, that's the suit, sir : I
would have mine such a suit without difference, such stuff, such a
wing, such a sleeve, such a shirt, belly and all ; therefore, pray you
observe it." 1599. — Ben Jonson, Every Man out of his Humour, III.
i., Works, i. IOI, col. I. p. 56. With Cantons annexed. — See the V '
Q\vnQ-canioned hobbyhorses, in Northward Ho, p. 231 above. "
Canons de Chausses, Cannyons. Chaussesa queue de merlus. Round
breeches with strait cannions ; hauing in the seat a peece like a
fishes tayle ; and worne by old men, schollers, and such like
niggardlie or needie persons." 1611. — Cotgrave. " Cantons were
rolls of stuff which termi nated the breeches or hose at the knee
(fig. 135," [where 2 heavyish rolls or sausages all round the knee
are cut] ), Fairholt : he refers to Henslowe's diary, "under April,
1598, he [H.] disburses ,£6 8s. for a bugell doblett and a payer of
paned hose of bugell panes drawne out with cloth of silver and
canyons to the same," &c. p. 56 : gally-hosen; also Gally-gascoynes.
See that word in Fairholt, p. 454. p. 56: hosen of a Marke price. —
This was an extravagant price in William Rufus's day, when 3.5-. was
the figure. See the anecdote about the king's hose in Robert of
Gloster's Chronicle, quoted by Fairholt under hose, p. 512. p. 56 :
trunk hose. — " Sometimes I have scene Tarleton play the clowne,
and vse no other breeches than such sloppes or slivings as now
many gentlemen weart : 1 "'The fringed loops appended to the
girdle, in which the dagger or small sword usually hung." 2 The turn-
over fringe or scollop of fine leather, often edgd with gold lace.
"Ruffle your brow like a new boot." Ib. I. i. p. 73.
The text on this page is estimated to be only 26.21%
accurate

Notes on pp. 56, 57. Meris Trunk-hose, &c. 247 they are
almost capable of a bushel of wheate ; and if they be of sackecloth,
they would serve to carrie mawlt to the mill. This absurd, clownish,
and unseemly attire, only by custome now is not misliked, but rather
approved." 1601. — Trios. Wright. The Passions of the Minde in
generall. (Dedicated to Lord Southampton ; and has Verses by Ben
Jonson.) See also the interesting extracts and cut in Fairholt's
Costume, p. 217. He was before me, I see, in quoting the following :
— "When Tarlton clown' d it in a pleasant vaine, And with conceites,
did good opinions gaine Vpon the Stage, his merry humors shop,
Clownes knew the Clowne, by his great clownish slop. But now
th'are gull'd, for present fashion sayes, Dicke Tarltons part,
Gentlemens breeches playes : In euery streete where any Gallant
goes, The swagg'ring Sloppe, is Tarltons clownish hose." 1600.— S.
Rowlands, The Letting of Humours Blood in the Head-Vaine, C 2,
back (ed. 1874, p. 36). See too the bit from More Knaves Yet, p.
240, above, and Ben Jonson's " I'll go near to fill that huge tumbrel-
slop of yours with somewhat, an I have good luck : your Garagantua
breech cannot carry it away so." 1598 — 1601.— Every Man in his
Humour, II. ii, Works, i. 18, col. I. 11 And for false cards and dice, let
my great slops, And his big bellied dublet both be sercht, And see
which harbors most hypocrisie." 1606. — No- Body and Some- Body,
Simpson's School of Shakspere, i. 353"The rest of France takes the
modell of the court, as a rule unto it selfe to follow. Let Courtiers
first begin to leave off and loath these filthy and apish breeches, that
so openly shew our secret parts : the bumbasting of long pease-
codbellied doublets, which makes us seeme so far from what we are,
and which are so combersome to arme : These long, effeminate,
and dangling locks : That fond custome to kisse what we present to
others, and Beso las manos in saluting of our friends: (a ceremonie
heretofore only due unto Princes:)" 1603.— J. Florio, Montaignes
Essayes, 1634, p. 146. " In our Old Plays, the humor Love and
Passion, Like Doublet, Hose and Cloak, are out of fashion." 1667. —
Prologue to James Shirley's Love-Tricks, first calld The Schoole of
Com plement, 1631. (Shirley died in Oct. 1666.) p. 57 : nether-
stockes, the stockings, as distinguisht from the hose, when the latter
became breeches. See the Debate between Pride and Loivliness —
wrongly attributed to Francis Thynne, from the forged ' F. Th.' on its
title-page— ' The neather stockes of pure Granada silke,' and other
authorities quoted by Fairholt, Costume in England, 1860, p. 211. p.
57 : shoes. — See Fairholt, Costume in England, p. 385-7. " Pinsnet,
apparently the same as Pinson, a thin-soled shoe. ' Calceamen and
calcearium is
The text on this page is estimated to be only 26.80%
accurate

248 Notes on p. 58. Mens Boots and Coats. a shoo, pinson,

socke.'— Wit Juris* Dictionarie, ed. 1608, p. 211." Nares, by
Halliwell and Wright. Pinion, pin$onnet are not in any French
Dictionary or Glossary that Mr. Henry Nicol or I can find ; and my
friend Prof. Paul Meyer doesn't know the words. See p. 266 below. p.
58 : boots with wide tops. — " if thy quicksilver can run so far on thy
errand as to fetch thee boots out of S. Martin's, let it be thy
prudence to have the tops of them wide as the mouth of a wallet,
and those with fringed boot-hose over them to hang down to thy
ancles." 1609. — T. Dekker. Guls Hornbook ', ch, iii. (1862), p. 16.
Instead of high-soled cork shoes, the earlier dandies had piked ones
: See the passage at the end of Gregory's Chronicle, after his death,
p. 238. Camden Soc. 1876. " A.D. 1468-9. Alle so that yere the Pope
sende a bulle for the Cordyners, and cursyd thoo that made any
longe pykys passynge ij yenchys of lengthe, and that no Cordyner
shuld not sylle no schone a-pone the Sonday, ne put no schoo a-pon
no man-ys fote, ne goo to noo fayrys a-pon the Sonday, uppon
payne of cursynge. And the kynge grauntyd in a conselle and in the
Parlement thaf hyt shulde be put in excecussyon, and thys was
proclaymyd at Poulys Crosse. And sum men sayd that they wolde
were longe pykys whethyr Pope wylle or nylle, for they sayde the
Popys curse wolde not kylle a flye. God amend thys ! And within
schorte tyme aftyr, sum of the Cordyners gate prevy selys and
proteccyons to make long Pykys, and causyd tho same men of hyr
crafte that laboryd to the Pope for the destruccyon of longe pykys to
be trobelyd and in grete donger." " 1582. In this Queenes dayes
[Anne of Bohemia, Rich. II's Queen], began the detestable vse of
piked shooes, tyed to their knees with chaines of siluer and gilt. Also
noble women vsed high attire on their heads, piked like homes, with
long trained gownes, and rode on side saddles, after the example of
the Queene, who first brought that fashion into this land, for before,
women were vsed to ride astride like men." 1605.— Jn. Stowe.
Annales, p. 471. p. 58. Coats, &c. " But these tender pernels must
have one gown for the day, another for the night ; one long, another
short ; one for winter, another for summer ; one furred through,
another but faced ; one for the work day, another for the holy day ;
one of this colour, and another of that ; one of cloth, another of silk
or damask ; change of apparel, one afore dinner, another after, one
of Spanish fashion, another Turkey ; and to be brief, never content
with enough, but always devis ing new fashions and strange ; yea, a
ruffian will have more in a ruff and his hose than he should spend in
a year. I read of a painter that would paint every country man in his
accustomed apparel, the Dutch, the Spaniard, the Italian, the
Frenchman ; but when he came to the English man, he painted him
naked, English and Save him clothe,1 and bad him make it himself,
for he changed his apparel fashion so often, that he knew not how
to make it ; such be our fickle 1 See the cut opposite, from Andrew
Boorde.
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookball.com