OLD | NEW |
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. |
30 | 29 |
31 ## Feature user experience | 30 ## Feature user experience |
32 | 31 |
33 This feature adds one additional commandline argument `-m` to `sel_ldr`. `-m` | 32 This feature adds one additional commandline argument `-m` to `sel_ldr`. `-m` |
34 takes a path to the directory to be used as the root by the untrusted | 33 takes a path to the directory to be used as the root by the untrusted |
35 application. | 34 application. |
36 | 35 |
37 All of the given requirements can be satisfied by this `chroot`-style | 36 All of the given requirements can be satisfied by this `chroot`-style |
38 interface: | 37 interface: |
39 | 38 |
40 * The only overhead for file I/O is in adding (and sanitizing) a path prefix | 39 * The only overhead for file I/O is in adding (and sanitizing) a path prefix |
41 to absolute paths passed through to the host. | 40 to absolute paths passed through to the host, or the cwd to relative paths |
| 41 passed through to the host. |
42 * Read-only or read/write access can be controlled using normal filesystem | 42 * Read-only or read/write access can be controlled using normal filesystem |
43 permissions for the user running the `sel_ldr` process. | 43 permissions for the user running the `sel_ldr` process. |
44 * Using host-side filesystem primitives such as Linux bind mounts, users can | 44 * Using host-side filesystem primitives such as Linux bind mounts, users can |
45 map disparate paths from the host into the untrusted process's root. | 45 map disparate paths from the host into the untrusted process's root. |
46 | 46 |
47 ## Implementation | 47 ## Implementation |
48 | 48 |
49 For the most part, this feature is simple and relatively straightforward to | 49 For the most part, this feature is simple and relatively straightforward to |
50 add. When `-m` is given (even if `-a` is not), file operations will be enabled | 50 add. When `-m` is given (even if `-a` is not), file operations will be enabled |
51 and the provided chroot path will be added as a path prefix to all absolute | 51 and the provided chroot path will be added as a path prefix to all absolute |
(...skipping 12 matching lines...) Expand all Loading... |
64 * `rename` | 64 * `rename` |
65 * `chmod` | 65 * `chmod` |
66 * `access` | 66 * `access` |
67 * `utimes` | 67 * `utimes` |
68 | 68 |
69 ### Path sanitization | 69 ### Path sanitization |
70 | 70 |
71 Path sanitization happens through a three stage process: | 71 Path sanitization happens through a three stage process: |
72 | 72 |
73 1) Ensure the user's path is absolute. | 73 1) Ensure the user's path is absolute. |
| 74 If the user's path is relative, transform it to be absolute by prepending |
| 75 the cwd. This requires that the cwd is within the mounted directory. |
74 2) Prefix the path to the mounted directory. | 76 2) Prefix the path to the mounted directory. |
75 3) Ensure that the path does not contain "..". | 77 3) Ensure that the path does not contain "..". |
76 | 78 |
77 ### Symlinks | 79 ### Symlinks |
78 | 80 |
79 Ideally, symlinks should behave as if we had just chrooted into the path given | 81 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). | 82 to `-m` (which means they would resolve relative to the untrusted root). |
81 | 83 |
82 However, it's not straightforward to have `sel_ldr` call `chroot` itself to | 84 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 | 85 make the kernel do appropriate symlink resolution in a cross-platform way. So |
(...skipping 33 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
117 | 119 |
118 * `getdents` - `..` might reference an inode outside of the untrusted | 120 * `getdents` - `..` might reference an inode outside of the untrusted |
119 root, but that's okay because the untrusted application can't do anything | 121 root, but that's okay because the untrusted application can't do anything |
120 with it. | 122 with it. |
121 * `fstat` - no different than `stat`, which is already allowed. | 123 * `fstat` - no different than `stat`, which is already allowed. |
122 | 124 |
123 For both of these calls, we might need to make sure there's no file descriptors | 125 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 | 126 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 | 127 root, but even if we don't there's very little the untrusted application could |
126 do with the data these calls return. | 128 do with the data these calls return. |
OLD | NEW |