-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathproposal.tex
62 lines (49 loc) · 2.87 KB
/
proposal.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
\documentclass[12pt,letterpaper]{article}
\usepackage[margin=1in]{geometry}
\begin{document}
\noindent
William Hatch, [email protected] \\
\noindent
Scotty Bauer, [email protected] \\
\noindent
Matt Hunsaker, [email protected] \\
\noindent
Network Security (CS6490) Project Proposal
\section*{The Problem}
Users want to run code from a myriad of sources that are often either partially
trusted or completely untrusted. If given full access to a user account,
programs may access sensitive information (keys, passwords, personal
information), may track users, or many other bad things.
Unix permissions are insufficient to prevent this issue -- they are good for
permissions between users, but do not help with the issue of a user wanting to
run less-trusted code. Android permissions are inflexible (IE all permissions
are enumerated by the OS and dictated by Google), and all-or-nothing (you can't
run a program with partial permissions), it hijacks the user/group security of
Unix (therefore killing its usefulness as a multi-user system), and its
interface is bad (you agree to everything up-front, out of context). Other
permissions systems tend to have similar issues.
\section*{Proposed Solution}
We propose a novel system of parameterizable permissions for running programs
within a permission context. We model applications as a combination of a
permissions context with executable code. These permission contexts can be
created or modified by the user to run programs in, allowing for fine-grained
privilege control for running apps with different levels of trust and different
areas of responsibility. We will provide an interactive method of context
editing so that apps can request permissions when they are required, so that
permissions are requested to the user withinin context that they are needed.
If permissions are denied, the application will simply receive an exception,
and can continue to provide all other functionality that it does have
permissions for. Additionally we will provide non-interactive configuration
methods more suitable for system administrators and version control.
Permissions in this system may be either from a pre-defined set or
programmer-defined to protect unforseen functionality. Furthermore, our
permissions will be parameterized by an extra argument. This will allow for
permissions to be more granular, for example allowing access to a given
sub-tree of the file system rather than full access to all the user's files.
\section*{Plan for Implementation}
We plan to develop a proof of concept for this system by implementing a Racket
language. This language will enforce permissions on relevant functions (such as
file access, network access, etc), and provide functions to wrap new functionality
in permission checks. We will create the various configuration formats and utilities
for convenient use for both novice and advanced users.
\end{document}