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