PinUP: Pinning User Files to Known Applications
William Enck, Patrick McDaniel, and Trent Jaeger
Systems and Internet Infrastructure Security (SIIS) Laboratory
Department of Computer Science and Engineering, The Pennsylvania State University
Users commonly download, patch, and use applications
suchasemailclients, officeapplications, andmedia-players
from the Internet. Such applications are run with the user’s
full permissions. Because system protections do not dif-
ferentiate applications, any malcode present in the down-
loaded software can compromise or otherwise leak all user
data. Interestingly, our investigations indicate that common
data. In this paper, we take advantage of this reality by
developing protection mechanisms that “pin” user files to
the applications that may use them. These mechanisms re-
strict access to user data to explicitly stated workflows–thus
preventing malcode from exploiting user data not associ-
ated with that application. We describe our implementa-
tion of PinUP on the Linux Security Modules framework,
explore its performance, and study several practical use
cases. Through these activities, we show that user data can
be protected from untrusted applications while retaining the
ability to receive the benefits of those applications.
Users frequently download, patch, and use largely un-
trusted applications from the Internet.
approach to limit exposure to untrusted applications–
sandboxes–provides an easy mechanism to protect a system
by containing an application within a resource-constrained
environment. However, sandboxes are limited for manag-
ing programs such as email clients, office applications, and
media-players that must necessarily access sensitive user
data. Conversely, current system protections provide little
defense against hidden malcode; downloaded applications
in commodity operating systems can access any and all data
that the user can. In a sense, traditional OS protections do
not limit the sharing of information between applications
and thus fail to provide least privilege over user data.
Interestingly, applications processing sensitive user data
(e.g., Quicken) often use application-specific files. Further,
our investigations indicate inter-application sharing is fre-
quently well-defined (e.g., localized to the creating applica-
tion, or limited to applications within a suite), fitting within
recognizable workflows. Ignoring for the moment system
operations such as backups, the degenerate and most fre-
quent workflow occurs when a user file is created and used
only by a single application. Additionally, in some environ-
ments, inter-user sharing occurs between systems via only a
few applications (e.g., email) . This reality represents an
opportunity for new protection schemes. We propose mech-
anisms that govern access by ensuring that every user appli-
cation adheres to its expected workflows. Thus, in contrast
to sandboxing which limits access based on a general notion
of containment, these new protection mechanisms identify
access policy as positive application-aware workflows.
lay system.We design and implement a mechanism to
pin user files to applications (and thus enforce application
workflow protections). In doing so, we found that realiz-
ing this conceptually simple policy in a protection mecha-
nism is more complex than one might initially expect. Such
complexity lies not only in understanding the often subtle
relationships between applications and data, but also in an-
ticipating and dealing with unexpected but essential shar-
ing. We implement PinUP upon the existing Linux Security
Modules framework  and we show that user data can be
protected from untrusted applications.
We now illustrate the new protection mechanism by con-
sidering a Quicken accounting application scenario. The
high value files created by Quicken, e.g., .qdf files, only
need to be accessed by Quicken. It seems natural that the
system should enforce that policy. Of course, the user may
wish upon occasion to email the Quicken file to an accoun-
tant. However, in this case, the email client should only
have read access to the file and only for the short duration
of sending the email. A protection mechanism must han-
dle such exceptions. Such exceptions are at the heart of the
mechanism complexity, and their recognition and handling
is considered in depth in the latter sections of this paper.
PinUP is intended to augment existing security services
within the OS. It is designed to operate above MAC sys-
1PinUP conceptually “pins” files to specific applications.
tems such as SELinux  and AppArmor , which we
believe are better suited to protect system files. However,
these system level mechanisms are not appropriate for pro-
tecting user files. Every user has a different set of applica-
tions and files related to their data. Hence, specifying pol-
icy for these artifacts using largely foreign concepts such
as groups, roles, and attributes is difficult and probably
impractical. The PinUP access control overlay provides a
straightforward method to protect the user files. We explore
the degree of applications this works well in Section 6.
The remainder of this paper considers the design and im-
plementation of the PinUP system. This work represents a
new tack at achieving system level least privilege. In so do-
ing, we focus our efforts on the users themselves, beginning
in the following section by considering the motivation and
requirements such a model and system.
2 Protection Approach
Traditional DAC systems authorize file access by check-
ing whether the user identity associated with the requesting
process has the necessary permissions. Because every pro-
cess run by a user has the same identity, all processes oper-
ate with the same permissions–leaving all user data vulner-
able to any single malicious process. For example, email
client attachments can be downloaded and executed with
access to any user data, enabling theft of financial informa-
tion (e.g., Quicken files), the modification of important doc-
uments (e.g., corporate documents), and the modification of
executables (especially if the user runs as an administrator).
Emerging approaches, such as SELinux  and AppAr-
mor , enforce MAC policy over file access. Unlike tra-
ditional discretionary systems, MAC systems associate per-
missions with process labels, typically defined by the ap-
plication being run and not the user.2MAC is well suited
to protect system files, but generally not for protecting user
files. For example, the SELinux reference policy uses a la-
bel user_ttoexpressuseraccesspolicy. Notonlydoesthis
it does not even isolate one user from another.
PinUP builds upon the existing MAC infrastructure to
sustain the integrity of the underlying system, enforc-
ing bindings between applications and files. PinUP poli-
cies work in unison to govern flows of data between
applications–the aggregate behavior of which will define
legal application workflows. For example, PinUP can re-
strict Excel spreadsheet .pdf output to printing applica-
tions, whose output is restricted to print spoolers, etc. How-
ever, PinUP is not a yet another DAC system; every change
to PinUP policies occurs through administrative tools that
require per-use user authentication. In particular, user pro-
cesses do not have the ability to modify PinUP policy.
2Other forms of MAC, such as multilevel security , focus on the
secrecy of the objects rather than the users or applications, but these ap-
proaches are too restrictive for the protection that we have in mind.
app: (vi, rw)
app: (gcc, rw)
app: (vi', rw)
from vi to vi')
Make available to
app: (vi, rw)
(Require authorization and
transfer permission to new file)
(Rules for initial access
Figure 1. A summary of the administrative
tasks for managing access to files.
Moreover, policies only need modification when applica-
tion or local administrator provided polices are insufficient.
We now illustrate important tasks that PinUP must con-
sider via the example in Figure 1. Assume that user jdoe
creates file x.c using the editor vi. The identity of the user,
creating application, and other attributes such as file exten-
sion are used to identify the PinUP policy to be applied to
the file, e.g., jdoe, vi, and .c. The policy explicitly states
which applications are allowed subsequent file access. In
this case, vi is given read and write access. x.c is a source
file, so user jdoe desires read-only access for a compiler
through a command line tool. Note that such a policy need
not be manual–an alternate policy may dictate that all .c
files created by vi are made available to gcc automatically.
The compiler can then create a new object file x.o that it
can write and can be read by the linker. Similar policy en-
forcement will occur as applications cascade over data to
consume and create protected files.
Figure 1 also illustrates a number of interesting design
and implementation challenges. For example, how one se-
curely identifies applications and propagates identity across
updates is key to ensuring correct policy enforcement. The
issue of attaching, tracking, and propagating PinUP polices
associated with user files is also daunting. This latter pro-
cess is closely related to label management in MAC sys-
tems. However, due to policy semantics and form, PinUP
policy tracking requires different machinery.
The central challenge of PinUP is to develop a system
that protects high-value user files3by limiting the applica-
tions that can access those files. The PinUP system consists
evolution of such rights and (2) an authorization mechanism
that can enforce such access. This system ensures that when
a user creates files from an authorized binary, subsequent
accesses to this file will be limited to applications specified
by a combination of system rules and authenticated user as-
signments. We begin this exploration in the next section.
3From this point, we will use the terms user files or user data to mean
high-value user files/data unless it is ambiguous.
3 System Design
The key design challenge is to enable effective adminis-
user files. Figure 1 presents different administrative opera-
Creating a File: Initial access rights are are required at file
creation. If rights are not set correctly, no applications may
be able to read or write the file. Further, we must not allow
access by maliciously modified applications, so we grant
access based on application binaries.
Granting Access: Determining the set of applications that
can access a file is non-trivial. A complete list of applica-
tions may be indeterminable at file creation, therefore man-
ual manipulation is necessary. However, the mechanism
must establish an authenticated channel with the user.
Upgrading Applications: Applications will be upgraded
over the lifetime of the system, so access policy update ac-
cordingly. This process must be secure and efficient.
File System Manipulation: Users occasionally rearrange
and delete files. File system utilities, e.g., cp, mv, rm, can-
not be added to application access lists, otherwise malicious
applications may acquire indirect access.
3.1 Creating a File
A file’s lifetime begins with its creation.
application-level control of user files requires an initial file
access policy. As a safe default, a high value file’s access
complex initial policies are described in Section 3.2.
File access policy specification requires identifying spe-
cific application binary instances. The enforcement mech-
anism must differentiate an authentic application from one
modified by a virus; even the slightest variation in the appli-
cation should deny access. Therefore, applications are iden-
tified by the cryptographic digest of their executable file (a
common method of binary code measurement ). This
ensures only authentic applications will gain access.
Our policy model associates a file with a user and a set
of application binary identifiers and their rights (e.g., read,
write, and execute) to the file in an access list. Such access
lists are stored with the file as is typical in MAC systems
(e.g., via the ext3 extended attributes as used by SELinux).
Determining the complete set of applications to assign
to a new file is non-trivial. As a safe default, a high value
file’s access list should at least contain the application that
created it. Beyond this, there are a number of hints that
can be leveraged. For example, the state of file creation,
including the creating application, the type of file created,
and the location of the new file, may be used to determine
the correct set of applications and their rights to the file.
In this section, we discuss methods of assigning an initial
# PinUP System Configuration Rules
# <Application> <file type> <add> <application>
# Allow "ld" to access all object files ".o"
# generated by "gcc"
gcc object add ld
# Allow "gv" to access all object files ".ps/.pdf"
# generated by "latex"
latex postscript add ghostview
latex pdf add ghostview
Figure 2. Example access automation rules
for a simple PinUP system configuration.
access lists via access automation rules. However, this list
can not always be determined at file create time; therefore,
we must provide a method of manual policy manipulation.
It is neither desirable nor practical to expect that a user can
determine all the applications and the rights that they can
use to access any high-value file. Some applications create
transient but important files as a matter of course. Other ap-
plications create many thousands of potentially important
files as they run. For example, consider again the use of
gcc in Section 2. gcc creates object files as it compiles
files, which are then used (often immediately) by a linker
to create an executable. A common “make” may indirectly
compile tens or hundreds of object files as the result of a
single user action. For well-known applications with po-
tentially high value files, such environments mandate auto-
mated tools for granting access to these files.
We have created an initial facility to automate this pro-
cess. The system is configured with a set of access au-
tomation rules indicating how files’ access lists should be
automatically defined upon creation. In the simplest instan-
tiation, the operating system monitors all file creation, and
new applications are added to the PinUP policy as directed
in those rules. Because access list entries are added with-
out user intervention, this can greatly reduce the burden of
managing transient files or prolific applications.
implementation is illustrated in Figure 2. The semantic of
this policy is as defined above: applications are configured
to automatically grant access (add) to some an application
when a particular class of files is created. For example, the
LATEX application grants read and write access to Ghostview
to all postscript and PDF files it creates. Note that this
policy illustrates one of potentially many automated pol-
icy specification operations, e.g., one may want to revoke
an application’s access to a file once it is closed. We defer
deeper analysis of policy automation to future work.
Access Automation Rules
While we envision access automation rules to encompass
the mass majority of policy specification, exceptions occur
Manual Policy Specification
when file’s set of authorized applications cannot always be
determined at a file’s creation time, e.g., temporarily grant-
ing an email client access. Therefore, the system requires
a mechanism that allows the user to add and remove appli-
cations from a file’s access policy. The key requirement of
this mechanism is that the system must establish a mutual
authenticated channel between the system and the user.
Both directions of authentication are important. The sys-
tem must authenticate the user to ensure a malicious ap-
plication has not requested the policy change, and the user
must authenticate the system to ensure a malicious appli-
cation cannot intercept and modify policy modification re-
quests. Unfortunately, the latter is an existing problem in
system security. Therefore, our current design only ac-
counts for authenticating the user to the system. Note that
while mutual authentication is desirable, a malicious appli-
cation acting as the user poses a more significant threat.
Currently, we establish an authenticated channel by re-
quiring the user to enter a password. While we use a pass-
word to establish the authenticated channel, any mechanism
that allows the system to authorize policy modification may
be substituted. However, we note that simply prompting the
user for confirmation without any context is a bad approach.
Users commonly accept all operation requests without read-
ing why the operation was requested.
Once the authenticated channel has been established, the
access policy may be modified. In traditional DAC systems
(e.g., UNIX and Windows), users specify the usernames
and rights for file access. Manually adding applications to
application-level access lists presents a similar experience.
We abstract the assignment of binaries to file access lists
using numeric application identifiers and groups of applica-
tions (similar to UNIX uid and gid values). To aid usability,
the user is presented the application name associated with
the numeric identifier. If a user frequently specifies multi-
ple applications for several files, redundant operations can
be reduced by creating predefined application groups, refer-
enced by application group identifiers (agids). Hence, users
need only specify an group name and the desired rights. Al-
lowing users to specify both applications and application
groups provides a flexible interface for users to influence
file access policy. While application groups must exist be-
fore they can be used, the system can predefine useful ap-
plication groups that can be extended by the user as needed.
3.3 Upgrading Applications
The file access policy restricts which application binary
instances can read, write, or execute a file. However, sys-
tems commonly upgrade application binaries for improved
features and security. Therefore, the system must differen-
tiate between a binary modification resulting from a legiti-
mate system upgrade from one resulting from a virus. Up-
grades are managed by updating access policy to reference
the latest binary instantiation of the application.
The update of file access policy corresponding to appli-
cation upgrade requires special attention. The system re-
quires a trusted mechanism to execute in tandem to existing
upgrade management tools. This tool must establish an au-
thenticated channel with the system administrator. Then, it
measures the digest of both the old and new application in-
stances. Finally, all references to the old digest are replaced.
This trusted application upgrade procedure need be in-
tensive. In PinUP, each file stores a list of application iden-
tifiers (aids), and application group identifiers (agids). The
associated application digests are stored in a central loca-
tion, hence, the process need only inspect the central store.
3.4 File System Manipulation
Files are occasionally rearranged and deleted. While
these file operations do not directly access content, they in-
fluence the file’s state (delete removes the file entirely) and
position within the file system. Adding commands such as
rm, cp, and mv to a file’s application access list allows mal-
ware to circumvent the protection system by executing the
command. Hence, file operations require special attention.
Users perform file operations with special utilities. We
propose a PinUP-aware utility for each operation, e.g.,
pinrm, pincp, and pinmv for rm, cp, and mv, respectively.
Each utility establishes an authenticated channel with the
user. Like the policy manipulation utilities described in
Section 3.2, these file utilities currently acquire an authen-
ticated channel by prompting for the user’s password (such
operations are expected to be infrequent, similar to man-
ual policy specification). Again, other authenticated chan-
nel mechanisms can be substituted. These special file util-
ities have implicit access to files by virtue of the authenti-
cated channel, because they ensure the operation is desired
by the user. Finally, the PinUP file utilities can be designed
to function as drop in replacements that only require an au-
thenticated channel when modifying a protected file, pro-
viding seamless integration with the existing system.
Figure 3 describes PinUP from an implementation per-
spective. In the figure, the user has specified application
and application group lists in the file system’s volume pol-
icy (note that a system configuration could require the ap-
plication and application group lists to be specified by a ad-
ministrator upon system installation). This is done using
human readable names not shown in the figure. Application
A, Application B, and an unknown application all attempt
to read and write a PinUP protected file. The file system
permissions indicate that the user may read and write the
file. Each application was invoked by the user that owns the
file; therefore, without PinUP in place, all access requests
would be granted. After performing a successful user per-
mission check, PinUP is invoked. PinUP obtains the appli-
cation binary digest from the current process table. Next,
1 = Digest(App A)
2 = Digest(App B)
App Groups List
1 = 1,2,10,23
2 = 21,15
Perm = (user,rw)
Apps = (1,rw)(3,r)
Groups = (1,r)
Figure 3. The PinUP File Protection System.
The user specified volume and file policy in-
dicates that Application A (aid 1) can read
and write the file; however Application B (in
agid 1) may only read it.
the file’s application access lists (for applications and ap-
plication groups) are read from the file’s attribute storage.
The identifiers are looked up in the appropriate application
and application group lists defined for the file system vol-
ume. Finally, the digest for the current process is matched
against the entries. In the figure, Application A has been
specified explicitly on the file with both read and write per-
mission (in the Named Applications List), therefore both
requests are granted. Application B belongs to application
group 1, which has read permissions on the protected file
(in the Named Application Group List). Therefore, Appli-
cation B can read, but not write the file. Finally, the un-
known application is not listed in the file’s access control
policy, therefore both read and write are denied.
The design goals of Section 2 present a number of im-
plementation challenges. The remainder of this section de-
scribes our implementation of PinUP using the Linux Secu-
rity Modules framework and custom administrative tools.
The PinUP model security hinges on the method of iden-
tifying applications. We have chosen to identify each ap-
plication using the cryptographic digest of its binary ex-
ecutable. Identifying an application by its digest ensures
not only the application is correct, but also no modifications
have occurred (e.g., modified by a virus).
Calculating the digest of a process is straightforward in
the standard case. On process creation, we use a Linux Se-
curity Module (LSM) hook, bprm_set_security, to gain
access to the specific executable file. The contents are di-
gested and the resulting value is stored in the new process’s
task_struct for later comparison (see Section 4.4).
Unfortunately, not all applications follow the standard
binary executable model. Many system utilities are inter-
preted scripts written in various languages: Perl, Python,
etc. In this case, both the binary interpreter and textual
script define the application. To accommodate, PinUP di-
gests both the interpreter and the script. The two values are
XORed and stored as the digest value used to identify appli-
cations. Note that the interpreter and script are identifiable
in both user and kernel space; however, the latter requires
careful inspection the Linux binary loader data structures.
The digest technique described for standard binaries and
scripts provides adequate security; however, it does not ac-
count for runtime dependencies. In Linux, applications read
the trusted system file /etc/ld.so.cache to determine
dynamic library locations. This file and the dynamic li-
braries it references are a part of the system configuration
and are out of the scope of PinUP’s protection. As such,
PinUP relies on system protections, e.g., SELinux, to con-
trol the integrity trusted system dynamic libraries and inter-
preter modules (e.g., for Perl, Python, etc.). The interaction
between system protections and PinUP is inherently subtle.
We defer analysis of this interaction to future work.
PERLLIB, PYTHONPATH, etc.) may also determine library
and module location. Malicious modification of environ-
ment variables to load alternate libraries are well known.
The best method of mitigating this threat is to disable the
use of these environment variables altogether, as they are
an insecure substitute for an improperly configured system.
As an alternative solution, future versions of PinUP can
use an existing LSM hook to authorize a library load. The
file_mmap LSM hook mediates all library loads by the dy-
namic linker. We note that kernel-based integrity measure-
ment (e.g., Linux IMA ) uses this LSM hook to ensure
the measurement of all dynamically linked libraries. Thus,
PinUP can ensure that a library meets an expected hash
value (e.g., is a system library). For scripting languages,
the interpreters must be modified to perform such autho-
rization. We note that integrity measurement requires the
same modifications, so PinUP can leverage these as well.
4.2 Encoding Policy in the File System
The second component of the PinUP implementation is
the method of encoding policy within the file system. To
simplify the policy description and maintenance, e.g., up-
grading applications, the PinUP policy encoding spans the
file system and the files. The file system contains infor-
mation relevant to all files, while files contain only enough
information to describe specific access control restrictions.
As described in Section 3.2, users specify file access lists
in terms of applications and application groups. Similar
to how UNIX systems use centrally located files to define
users and groups (e.g., /etc/passwd and /etc/group), a
PinUP enabled file system maintains a special file, .pinup,
at its root. This file specifies the application digest (de-
scribed in Section 4.1) along with a unique numeric applica-
tion identifier (aid) and a human readable name. Similarly,
the file contains a list of application groups specifying the
unique application group identifier (agid), human readable
name, and list of aids belonging to the group. All files in
the file system volume used the defined aid and agid val-
ues to specify per-file access lists and permissions.
The per-file access lists and permissions are stored
ineach file’sinode extended
PinUP defines two new extended attribute handles,
security.pinup.apps and security.pinup.groups,
for lists of applications and application groups, respectively.
Each list is a binary array (similar to the character array
stored by SELinux) that specifies either the aid or agid
and the associated permissions, i.e., read (r), write (w), or
read and write (rw).4For storage purposes, the identifier
and permissions are marshaled into a single 32-bit integer,
using the two most significant bits for the permissions.
Users and administrators modify PinUP policy using
special utilities. The PinUP console, pincon, manipu-
lates the file system volume policy data, and pinmod (like
chmod) specifies permissions on specific files. Both utili-
ties use human readable names associated with the aid and
agid values. In many ways, working with PinUP policy
parallels administration of user-based access control, which
uses uid and gid values to identify users and groups.
The pincon utility allows users and administrators to
add, delete, and otherwise modify the application and ap-
plication group definitions for a file system volume. When
adding a new application, pincon calculates the SHA1 di-
gest of the provided file path and assigns the next highest
aid value. Similar operations result for application up-
grade. pincon also allows the user to create application
groups. New groups are assigned the next highest agid
value, and the user adds and deletes applications from a
group using the human readable names. Note that delet-
ing numeric identifiers has identical concerns as reassign-
ing uid values. Finally, after each update, pincon notifies
the PinUP kernel module to reread the policy by writing the
path of the policy file to a SecurityFS interface.
The pinmod utility references the aid and agid values
managed by pincon when specifying access permissions
on files. Users administer their own policy using pinmod
much in the way they currently use chmod. Users add and
delete applications and application groups by name along
with a right (r/w/rw). Accordingly, pinmod updates the ex-
tended attribute by encoding the identifier and right.
Both pincon and pinmod provide special administra-
tive privilege within the PinUP system, and therefore are
included in agid 0, which has implicit access to all PinUP
protected files. This functionality is similar to how the
root user in UNIX systems is treated with respect to user
file system protections. Applications within agid 0 must
essary policy complexity for a right rarely applied to high-value user files.
When access control based on execute rights is required, the discretionary
file system execute bit can be used.
open system call
(current user process)
Figure 4. PinUP Enforcement Mechanism
take special precautions to avoid invocation by a malicious
application. As discussed in Section 3.2, each invocation
must authenticate the user’s intentions. Our implementation
prompts forthe user’spassword using PAM authentica-
tion. Note that PAM authentication requires root privileges,
therefore the executables are owned by root with setuid
permissions. Implications of this ownership are discussed
in Section 4.4. Note that this configuration is also required
to modify the .pinup file and file extended attributes.
Finally, we understand that command line utilities are
often awkward for some users. Therefore, our utilities are
built upon a special PinUP library allowing logic reuse. We
expect future PinUP implementations to include graphical
counterparts to pincon and pinmod.
The PinUP policy specified by pincon and pinmod is
enforced by the PinUP Linux Security Module (LSM). The
implementation uses the inode_permission hook to de-
termine when a process attempts to access a file. Shown
in Figure 4, the enforcement mechanism retrieves the appli-
cation identity (as described in Section 4.1) and file policy
(stored in inode attributes as described in Section 4.2), inter-
policy stored in the .pinup file described in Section 4.2),
and determines if the accessing application may perform its
desired action, i.e., read or write.
As PinUP is only concerned with reads and writes, the
module interprets execution requests as reads and append
requests as writes. PinUP begins by iterating through the
list of application identifiers specified for the file. If the
requested operation meets the permissions for a specified
aid, the volume policy is consulted for the digest value as-
sociated with the aid. If the value matches that of the cur-
rent process, access is allowed. This iteration is continued
until a match is found. If no match is found, PinUP moves
to the application group list. PinUP iterates through this
list with an extra level of indirection, consulting each aid
associated with a agid when the specified rights allow the
requested operation. Finally, if no specified agid contains
an application with a digest value matching the current pro-
cess, PinUP checks agid 0, which contains the list of ad-
ministrative operations. Upon failing to match any digest
value, the hook returns -EACCES, indicating access denied.
This mediation technique works well to protect files;
however, it is inappropriate for directories. A directory is
opened and written to whenever the contents its contents is
modified. Protected files within a directory will have differ-
ent access control policies. As a result, determining which
applications can read and write a directory is difficult. How-
ever, completely ignoring directories is not appropriate ei-
ther. If a user has write permissions to a directory, rm can
override file permissions and remove files within it.
PinUP controls directory access by mediating the oper-
ations performed to the files contained within. PinUP me-
diates file removal using the inode_unlink LSM hook. If
a file contains a PinUP extended attribute, the hook only
requires the application to be in agid 0. A similar tech-
nique is applied when moving and renaming files using the
inode_rename hook, with the addition that protected files
cannot be be moved between file systems where volume
policy may redefine numeric values in access lists. The
special PinUP system utilities used to perform file manip-
ulation are discussed in Section 4.5.
Finally, PinUP mediates file operations that modify
the extended attributes used by file policies.
inode_setxattr and inode_removexattr LSM hooks,
PinUP ensures the current process is in agid 0 and that the
process’s uid matches that of the file’s owner. The latter
protects systems that requiring root access to set extended
attributes, thereby forcing pinmod to execute as root. With-
out this check, cross user policy modification may occur.
4.5 File Manipulation Utilities
to allow file manipulation. As discussed in Section 3.4,
pinrm, pinmv, and pincp use password authentication
to establish an authenticated channel.
and pincon, the file manipulation utilities authenticate the
user using PAM, thereby requiring the same root ownership
with setuid permission. PinUP is designed to supplement
user-based access control, therefore, each file utility subse-
quently relinquishes permission using seteuid().
All three utilities are included in agid 0 indicating
they are trusted applications.
trol logic in the inode_unlink and inode_rename LSM
hooks, pinrm and pinmv simply execute the unlink()
and rename() system calls after authenticating the user.
pincp, however, must also copy extended attributes.
In this section, we consider the run time costs of PinUP.
These costs principally occur at load time (application hash-
ing) and during the enforcement of policy (access checks).
In support of these tests, we have implemented the PinUP
file protection system (as described throughout) on the
Linux kernel 2.6.17 within the Ubuntu v6.10 distribution.
All experiments were performed on a 2.8GHz Intel Pentium
As with pinmod
Due to the access con-
File Size (KB)
Figure 5. Process Start-up Cost
4 with 1GB RAM and observed 95% confidence intervals
less than two orders of magnitude of the mean.
The initial PinUP user space utilities and libraries
consist of around 4,500 lines of C. The libraries pro-
vide a simple interface for interacting with PinUP file
and volume policy, digesting applications, and perform-
ing user authentication.The PinUP kernel code con-
sists of an additional 2,000 lines of C. The code cur-
rently exists as an LSM module and small kernel source
patches. The open source code is available for download
5.1 Load Time Costs
PinUP performs a cryptographic digest of every exe-
cutable as it is loaded. The time required to digest a bi-
nary as it is loaded is directly dependent on the size of
the file. Thus, an understanding of load cost must first be
based on an analysis of the size of executables. A quick in-
vestigation of executables in the /bin, /sbin, /usr/bin,
and /usr/sbin directories of Ubuntu v6.10 (2327 files in
total) ranged from 4MB to a few kilobytes. We found that
more than 60% of executables are smaller than 20KB, and
more than 80% are less than 100KB. Hence, it seems that
the majority of executables are indeed small. However, one
must be careful in assuming that that applications are used
at the same rate–some large executables may be extremely
popular. Thus, for the experiments that follow we conser-
vatively measure the costs of executables of powers of two
between 8KB to 4MB. We created executables of precise
sizes by padding a small application with nop operators.
We measured load time costs in two ways. First we per-
formed a microbenchmark of the digest mechanism alone.
Unsurprisingly, we found the digest cost scales linearly
with 16KB files taking around 100 µs and 4MB files tak-
ing around 40 ms. Next, the experiment was repeated,
but instead, the measurement code was instrumented in
userspace, thereby capturing the observable startup cost.
Figure 5 summarizes our findings. Interestingly, the start-
up cost does not vary with file size when PinUP LSM is not
used. This results from optimizations in the kernel process
loader where code pages are read on demand, whereas with
Access List Type
Figure 6. Permission Check Latency
PinUP the entire binary must be read before execution can
cess start-up is only around 0.8 ms. For 16KB files, which
accounts for nearly 60% of executables, only a 0.2 ms over-
head is added. Even for the largest binaries, 4MB, only a
40 ms delay is added. Such files are typical of graphical ap-
plications that are infrequently executed. In these cases, the
additional 40 ms (1/25th a second) is not noticeable by the
user. Thus, PinUP incurs negligible load-time overhead.
5.2Policy Enforcement Costs
PinUP policy is enforced through the kernel hooks to the
LSM. Called only after successful completion of the normal
file system access checks, the enforcement code searches
access lists to see if the governed application is allowed to
access the file. We analyze these costs by investigating the
search time as a function of access list lengths (the central
determinant in enforcement cost). The tests measure two
cases: when the application list is directly on the file and
when applications referenced by a single application group.
Figure 6 displays the results of accessing a file with an
access list of 5, 10, 50, and 100 applications (prefixed by
’A’) and a file with an access list including one applica-
tion group referencing 5, 10, 50, and 100 applications (pre-
fixed by ’G’). An experimental baseline is set by measur-
ing (failed) access cost (not invoking PinUP) denoted UNIX
deny. The experiments indicate an access check overhead
on the order of tens of microseconds. Note that the y-axis in
Figure 6 starts at 4.5 milliseconds. Hence, even for unreal-
istically large lists, the runtime costs of PinUP enforcement
are completely dominated by other access costs, e.g., con-
text switches and file I/O. Finally, the experiment indicates
greater efficiency when using application groups. The small
difference is explainable due to the reduced I/O access, i.e.,
only one agid is read from disk.
PinUP targets the objects of risk: user files. These files
are often subject to malware and commonly contain sensi-
tive data and/or cannot be easily recreated in the event of
compromise. Many previous works attempt to protect user
files by applying application “sandboxes.” In such works,
applications are sandboxed either by specifying resource
policies for applications (e.g., Janus ) or relinquishing
privileges before execution (e.g., TRON ). This section
compares PinUP to the application sandboxes, showing that
PinUP provides greater protection more straightforward ad-
ministration. We then consider three usage scenarios to
evaluate the ability to automate administrative actions.
6.1Comparison to Sandboxes
PinUP provides greater protection for user files than ap-
plication sandboxes. Traditional application sandboxes do
not provide explicit protection of user files. Rather, user
files are indirectly protected by ensuring untrusted applica-
tions execute in a limited environment. However, to ensure
user files are protected, the sandbox model assumes all un-
trusted applications can be identified. The complex envi-
ronments in current systems allow malicious software to be
introduced via unpredictable means. Additionally, there is
no separation in the level of trust in a trusted application.
An application trusted to access a certain type of user file
may incorrectly gain access to other files. Hence, we be-
lieve PinUP is more appropriate for protecting user files as
the set of trusted applications for a specific file can be easily
determined from the application access list for that file.
PinUP often requires less overall user effort than appli-
cation sandboxes. Traditional sandboxing techniques re-
quire the user to ensure a properly restricted execution envi-
ronment every time the application is executed. For exam-
ple, in TRON, the user must manually execute tron_fork
to delegate less privileges to a child process. In contrast, a
PinUP permission need only be specified once per file, and
can be often created automatically. For policy-based sand-
defined policies; however, the user must still perform the ar-
duous task of creating a new custom policy for every new
application. This requires determining the entire set of files
the application needs to access. Such file sets are often eso-
teric and vary between applications. In PinUP, the user must
only modify automatically created policy when a file needs
to be accessed by a new application.
Applications sandboxes also limit flexibility at run time.
For example, sandbox policies typically provide file protec-
tion by specifying file paths, or more commonly, directory
paths. In doing so, the sandbox restricts where the user may
store files, which can be cumbersome or confusing. PinUP,
on the other hand, is not restricted by directory structure,
thereby allowing users to store .qdf files along side related
.doc files without compromising the security of either.
To further examine PinUP’s appropriateness for a user
oriented platform, we created three example scenarios: (1)
a document development lifecycle; (2) a GUI application
to edit files; (3) web browser file retrieval. The experi-
ments study the policy implications of the file operations
incurred by real application use in each scenario. The op-
erations were inferred from file system open system calls
collected by the OS kernel. Our primary goal was to inves-
tigate the appropriateness of the workflow model for access
automation rules described in Section 3.2.1. With minor ex-
ception, all enforcement scenarios conformed to our expec-
tations about policy–the file accesses are restricted to well
known applications as determined user workflows.
Document Lifecycle: The first example consists of re-
trieving the LATEX document files from a Subversion repos-
itory, editing the document files using vim, building a
PDF, emailing the PDF, and receiving the PDF from an
email. This example requires two PinUP access automation
rules. The first permits editors to modify LATEX files down-
loaded using subversion, and the second permits the Adobe
viewer acroread to view the generated (from pdflatex)
or downloaded (from the email client on receipt) PDF. We
envision that since the user manually selects the files to
send, we should not give the email client access to all PDF
files by default. Thus, the user will have to grant the email
client access to the specific files using pinmod. As we
have shown in previous work , some common environ-
ments exhibit minimal inter-machine sharing implying ex-
plicit policy changes should not be overbearing.
Graphical Editor: In the second example, we examine use
ofaGUIeditor, OpenOffice, toeditthefilesratherthan vim.
others because it does not generate backup files. Some ed-
itors (e.g., vim) save files by renaming the original file to a
backup file before creating the saved file in a new file ob-
ject (of the original’s name). This is problematic because
a file’s application access lists are stored with the inode.
Note, however, that OpenOffice did not use this save tech-
nique. In fact, such function is not strictly necessary to vim,
as it will not create a backup if the rename is not authorized.
However, we expect such use will be common, so we envi-
sion PinUP rules will require extension to capture the case
where an application renames a file and creates a file with
the same name as the original.
Web Browser: In our final scenario, we view a PDF with
and without the Adobe Acrobat Plugin for Firefox. With
the plugin, Firefox opened the file from its cache directory,
forking the Adobe acroread binary, which subsequently
created a file in /tmp; the plugin API provided the raw data
to acroread. Other plugins were observed to behaved sim-
ilarly. Without the plugin, Firefox created a file in /tmp,
which was subsequently read by acroread. In the former
case, no additional rules are necessary, but in the latter case,
access to Firefox downloaded PDF files. A potential con-
cern is that Firefox can provide data access via the plugin
API. However, the mapping of plugins to file types is sim-
ilar to the PinUP access automation rule notion (no binary
hash, however). Integration of application-level access au-
tomation and PinUP access automation may be warranted.
7 Related Work
File system protection has received much attention.
Originally, all system daemons ran as root.
vulnerable daemons, systems administrators run each dae-
mon as a limited user. Unfortunately, some daemons re-
quire root privileges. Separation between root-level dae-
mons is provided by reference monitors , which allow
processes and files labeling (DTE ) and manage label
transitions (RBAC [11, 10]). SELinux , a derivative
of Flask , is the most widely used reference monitor
in commodity systems; however, writing polices describing
all system process activities is nontrivial, therefore, targeted
mode, which sandboxes specific applications, is most com-
mon. The sandbox approach is a common approach for iso-
lating system daemons [6, 20, 18]. Unfortunately, writing
sandbox policies requires files to either exist or be isolated
to directories. Ko et. al.  attempt to overcome this by
specifying polices of expected application behavior. Devia-
tions are viewed as anomalies and dealt with accordingly.
User files are more difficult to protect; their creation and
access patterns are often unpredictable only understood by
the user. File access control lists (ACLs)  provide ba-
sic flexible user controls; however provide no differentia-
tion between a user’s applications. Previous work proposes
executing applications in limited environments. This tech-
nique, known as sandboxing, uses either pre-specified poli-
cies for untrusted applications [1, 13, 15, 21] or privileges
reduction for child processes via capabilities [5, 17, 25] or
sub-user identities [12, 26]. As discussed in Section 6.1,
PinUP provides a more secure default and often requires
less overall user effort. Polaris  attempts to minimize
user effort by providing application-identity profiles; how-
ever, the user experience still leaves much to be desired .
Finally, SubOS  extends the process user identity with a
“sub-user” identify specified on an input file. However, Su-
bOS focuses more on controlling process activities resulting
from reading a malicious file than protecting user files.
Wichers et. al.  were the first to add program ac-
cess lists (PACLs) to files in an attempt to mitigate attacks
by viruses and Trojans. Unfortunately, programs are identi-
fied by the path to the executable, which is less secure than
the cryptographic digest used by PinUP. Additionally, PA-
CLs are inherited from directories. This approach is not
ideal when multiple file types exist in the same directory.
Finally, while PACLs was designed and simulated, a us-
able implementation was never built. LIDS  also pro-
vides a protection model similar to PinUP is also available
in LIDS ; however, the interface, which is more com-
monly used for sandboxing is restricted to systems admin-
istrators. Finally, FileMonster  adds application-based
protection labels to Microsoft Windows ACLs; however, vi-
olations allow users to continue by accepting a pop-up.
This paper introduced the PinUP access control overlay
system. PinUP enforces application workflows by “pin-
ning” files to the set of applications to which they are in-
tended to be used. Specifically, applications are allowed ac-
cess to high-value user files only if both system and access
overlay permissions allow it. The overlay tags a user’s files
with the applications that are allowed to access it. However,
as we found, implementing a system meeting this seem-
ingly simple policy turned out to be more complex than one
would initially think. We described and evaluated our im-
plementation and found policy could be enforced with very
modest performance impact. A consideration of use cases
confirmed that the policy adds a significant and important
new dimension to user file security.
In this work, we have shown how to extend the protec-
tions of current systems to enhance access control; how-
ever, more experience with PinUP and real applications is
required to develop proper and safe automated access rules.
It is these user experiences and design decisions, as well as
the experiences resulting from providing these tools to the
larger user community that will fully expose the long term
value of the PinUP system.
We thank Kevin Butler, Patrick Traynor, and the rest of
the SIIS lab for their continual feedback on this work.
 A. Acharya and M. Raje. MAPbox: Using parameterized be-
havior classes to confine untrusted applications. In Proceed-
ings of the 9th USENIX Security Symposium, Aug. 2000.
 J. P. Anderson. Computer security technology planning
study. ESDTR-73-51, Air Force Electronic Systems Divi-
sion, Hanscom AFB, Bedford, MA, 1972. (Also available as
Vol. I, DITCAD-758206. Vol. II DITCAD-772806).
 L. Badger, D. Sterne, D. Sherman, K. Walker, and
S. Haghighat. A domain and type enforcement UNIX proto-
type. In Proceedings of USENIX Security Symposium, 1995.
 D. E. Bell and L. J. LaPadula. Secure Computer Systems:
Mathematical Foundations. Technical Report MTR-2547,
Vol. 1, MITRE Corp., Bedford, MA, 1973.
 A. Berman, V. Bourassa, and E. Selberg. TRON: Process-
specific file protection for the UNIX operating system. In
Proceedings of USENIX Technical Conference, 1995.
 C. Cowan, S. Beattie, G. Kroah-Hartman, C. Pu, P. Wagle,
and V. Gligor. SubDomain: Parsimonious server security. In
USENIX conference on System administration, 2000.
 A. DeWitt and J. Kuljis. Aligning usability and security: A
usability study of polaris. In Proceedings of the Symposium
On Usable Privacy and Security, July 2006.
 W. Enck, S. Rueda, Y. Sreenivasan, J. Schiffman, L. S. Clair,
T. Jaeger, and P. McDaniel. Protecting users from ”them-
selves”. In Proceedings of ACM CSAW, 2007.
 G. Fernandez and L. Allen. Extending the Unix protection
model with access control lists. In Proceedings of the 1988
USENIX Summer Symposium, pages 119–132, 1988.
 D. Ferraiolo, J. Cugini, and D. R. Kuhn. Role-based access
control (RBAC): Features and motivations. In Proceedings
of Annual Computer Security Application Conference, 1995.
 D. Ferraiolo and R. Kuhn. Role-based access control. In Pro-
ceedings of National Computer Security Conference, 1992.
 C. Friberg and A. Held. Support for discretionary role based
access control in ACL-oriented operating systems. In ACM
workshop on Role-based access control, 1997.
 I. Goldberg, D. Wagner, R. Thomas, and E. Brewer. A secure
environment for untrusted helper applicationos: Confining
the wily hacker. In USENIX Security Symposium, 1996.
 S. Ioannidis, S. Bellovin, and J. Smith. Sub-operating sys-
tems: A new approach to application security. In Proceed-
ings of ACM SIGOPS European workshop, 2002.
 T. Jaeger, A. Rubin, and A. Prakash. Building systems that
flexibly control downloaded executable content. In Proceed-
ings of USENIX UNIX Security Symposium, July 1996.
 C. Ko, G. Fink, and K. Levitt. Automated detection of vul-
nerabilities in privileged programs by execution monitoring.
In Proceedings of ACSAC, 1994.
 N. Lai and T. Gray. Strengthening discresionary access con-
trols to inhibit trojan horses and computer viruses. In Pro-
ceedings of USENIX Summer Symposium, 1988.
 Linux intrusion detection system (LIDS). http://www.
lids.org, accessed January 2007.
 National Security Agency.
 Novell. AppArmor application security for linux. http://
 N. Provos. Improving host security with system call policies.
In Proceedings of USENIX Security Symposium, 2003.
 R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design
and implementation of a TCG-based integrity measurement
architecture. In USENIX Security Symposium, 2004.
 V. Samar. Unified login with pluggable authentication mod-
ules (PAM). In Proceedings of ACM CCS, 1996.
 M. Schmid, F. Hill, and A. Gosh. Protecting data from mali-
cious software. In Proceedings of ACSAC, 2002.
 M. Seaborn. Plash. http://plash.beasts.org.
 P. Snowberger and D. Thain. Sub-identities: Towards operat-
ing system support for distributed system security. Technical
Report 2005-18, University of Notre Dame, Department of
Computer Science and Engineering, Oct. 2005.
 R.Spencer, S.Smalley, P.Loscocco, M.Hibler, D.Andersen,
and J. Lepreau. The flask security architecture: System sup-
port for diverse security policies. In Proceedings of USENIX
Security Symposium, Aug. 1999.
 M. Stiegler, A. Karp, K.-P. Yee, and M. Miller. Polaris: Virus
safe computing for windows xp.
2004-221, HP Laboratories Palo Alto, Dec. 2004.
 Trusted Computing Group.
chitecture overview:Revision 1.2.
trustedcomputinggroup.org, Apr. 2004.
 D. Wichers, D. Cook, R. Olsson, J. Crossley, P. Kerchen,
K. Levitt, and R. Lo. PACL’s: An access control list ap-
proach to anti-viral security. In Proceedings of the 13th Na-
tional Computer Security Conference, 1990.
 C. Wright, C. Cowan, J. Morris, S. Smalley, and G. Kroah-
Hartman. Linux security modules: General security support
for the Linux kernel. In USENIX Security Symposium, 2002.
Technical Report HPL-
TCG specification ar-