Chromium Code Reviews| 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. |
| (...skipping 31 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
| 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 Loading... | |
| 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. |
| OLD | NEW |