Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(287)

Side by Side Diff: documentation/filesystem_access.txt

Issue 1690983004: Extended restricted filesystem to support relative paths. (Closed) Base URL: https://chromium.googlesource.com/native_client/src/native_client.git@master
Patch Set: Allow relative paths without prepending CWD Created 4 years, 10 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
1 # Safe filesystem access 1 # Safe filesystem access
2 2
3 ## Background 3 ## Background
4 4
5 Native Client is a useful library for restricted code execution that is useful 5 Native Client is a useful library for restricted code execution that is useful
6 beyond the browser. There’s all sorts of cases where one might want to run 6 beyond the browser. There’s all sorts of cases where one might want to run
7 untrusted code in a system disconnected from Chromium or PPAPI. 7 untrusted code in a system disconnected from Chromium or PPAPI.
8 8
9 In these cases, it is additionally useful to allow restricted filesystem 9 In these cases, it is additionally useful to allow restricted filesystem
10 access, but to still run untrusted code. 10 access, but to still run untrusted code.
11 11
12 ## Constraints 12 ## Constraints
13 13
14 These constraints are NOT GUARANTEED TO BE ENFORCED BY SEL_LDR, and must 14 These constraints are NOT GUARANTEED TO BE ENFORCED BY SEL_LDR, and must
15 be guaranteed by the caller: 15 be guaranteed by the caller:
16 * The mounted directory is assumed to not include any symlinks. 16 * The mounted directory is assumed to not include any symlinks.
17 17
18 These constraints will be enforced by sel_ldr: 18 These constraints will be enforced by sel_ldr:
19 * Pathnames must be absolute. Relative pathnames are explicitly disallowed.
20 * Pathnames may not include the substring "..". 19 * Pathnames may not include the substring "..".
21 * Access to filesystem within sel_ldr will behave as if as if the mounted 20 * Access to filesystem within sel_ldr will behave as if as if the mounted
22 directory is root. 21 directory is root.
23 22
24 ## Requirements 23 ## Requirements
25 24
26 * Very low overhead File I/O. 25 * Very low overhead File I/O.
27 * Give users the ability to have selective read-only or read/write access. 26 * Give users the ability to have selective read-only or read/write access.
28 * Give users control over the entire filesystem layout presented to the 27 * Give users control over the entire filesystem layout presented to the
29 untrusted application. 28 untrusted application.
(...skipping 31 matching lines...) Expand 10 before | Expand all | Expand 10 after
61 * `unlink` 60 * `unlink`
62 * `truncate` 61 * `truncate`
63 * `link` 62 * `link`
64 * `rename` 63 * `rename`
65 * `chmod` 64 * `chmod`
66 * `access` 65 * `access`
67 * `utimes` 66 * `utimes`
68 67
69 ### Path sanitization 68 ### Path sanitization
70 69
71 Path sanitization happens through a three stage process: 70 Requires that the cwd is within the mounted directory (set at initialization).
Mark Seaborn 2016/02/24 21:19:19 Make this "Path sanitization checks that..." so th
Sean Klein 2016/02/24 23:40:43 Done.
72 71
73 1) Ensure the user's path is absolute. 72 If the user's path is absolute, prefix the path to the mounted directory.
74 2) Prefix the path to the mounted directory. 73 Ensure that the path does not contain "..".
75 3) Ensure that the path does not contain "..".
76 74
77 ### Symlinks 75 ### Symlinks
78 76
79 Ideally, symlinks should behave as if we had just chrooted into the path given 77 Ideally, symlinks should behave as if we had just chrooted into the path given
80 to `-m` (which means they would resolve relative to the untrusted root). 78 to `-m` (which means they would resolve relative to the untrusted root).
81 79
82 However, it's not straightforward to have `sel_ldr` call `chroot` itself to 80 However, it's not straightforward to have `sel_ldr` call `chroot` itself to
83 make the kernel do appropriate symlink resolution in a cross-platform way. So 81 make the kernel do appropriate symlink resolution in a cross-platform way. So
84 our other option to support symlinks is to do an Lstat on every path load and 82 our other option to support symlinks is to do an Lstat on every path load and
85 try to resolve symlinks ourselves. This would be a pretty big performance hit 83 try to resolve symlinks ourselves. This would be a pretty big performance hit
(...skipping 31 matching lines...) Expand 10 before | Expand all | Expand 10 after
117 115
118 * `getdents` - `..` might reference an inode outside of the untrusted 116 * `getdents` - `..` might reference an inode outside of the untrusted
119 root, but that's okay because the untrusted application can't do anything 117 root, but that's okay because the untrusted application can't do anything
120 with it. 118 with it.
121 * `fstat` - no different than `stat`, which is already allowed. 119 * `fstat` - no different than `stat`, which is already allowed.
122 120
123 For both of these calls, we might need to make sure there's no file descriptors 121 For both of these calls, we might need to make sure there's no file descriptors
124 in the untrusted application that reference files outside of the untrusted 122 in the untrusted application that reference files outside of the untrusted
125 root, but even if we don't there's very little the untrusted application could 123 root, but even if we don't there's very little the untrusted application could
126 do with the data these calls return. 124 do with the data these calls return.
OLDNEW
« no previous file with comments | « no previous file | src/trusted/service_runtime/sel_ldr_filename.c » ('j') | src/trusted/service_runtime/sel_ldr_filename.c » ('J')

Powered by Google App Engine
This is Rietveld 408576698