documentation/filesystem_access.txt - Issue 1690983004: Extended restricted filesystem to support relative paths.

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: Created 4 years, 9 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

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 Path sanitization checks that the cwd is within the mounted directory (set at

	71 initialization).

72	72

73 1) Ensure the user's path is absolute.	73 If the user's path is absolute, prefix the path to the mounted directory.

74 2) Prefix the path to the mounted directory.	74 Ensure that the path does not contain "..".

75 3) Ensure that the path does not contain "..".

76	75

77 ### Symlinks	76 ### Symlinks

78	77

79 Ideally, symlinks should behave as if we had just chrooted into the path given	78 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).	79 to `-m` (which means they would resolve relative to the untrusted root).

81	80

82 However, it's not straightforward to have `sel_ldr` call `chroot` itself to	81 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	82 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	83 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	84 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	116

118 * `getdents` - `..` might reference an inode outside of the untrusted	117 * `getdents` - `..` might reference an inode outside of the untrusted

119 root, but that's okay because the untrusted application can't do anything	118 root, but that's okay because the untrusted application can't do anything

120 with it.	119 with it.

121 * `fstat` - no different than `stat`, which is already allowed.	120 * `fstat` - no different than `stat`, which is already allowed.

122	121

123 For both of these calls, we might need to make sure there's no file descriptors	122 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	123 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	124 root, but even if we don't there's very little the untrusted application could

126 do with the data these calls return.	125 do with the data these calls return.

OLD	NEW

« no previous file with comments | « no previous file | src/trusted/service_runtime/sel_ldr_filename.c » ('j') | no next file with comments »