39
edits
Security/Sandbox: Difference between revisions
Jump to navigation
Jump to search
→Linux: Trivial markup fix.
(→Linux: Rewrite this section to try to explain why as well as what/how. Might need more hyperlinks.) |
(→Linux: Trivial markup fix.) |
||
| Line 461: | Line 461: | ||
Linux sandboxing technologies generally fall into two categories: those that act on the semantics of operations (e.g., what happens when a filesystem path is resolved) and those that affect raw system calls (e.g., what happens when syscall #83 is invoked). There's a more | Linux sandboxing technologies generally fall into two categories: those that act on the semantics of operations (e.g., what happens when a filesystem path is resolved) and those that affect raw system calls (e.g., what happens when syscall #83 is invoked). There's a more | ||
detailed explanation in [http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html | detailed explanation in [http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html the blog post announcing seccomp-bpf], which is the main syscall-filtering facility. | ||
the blog post announcing seccomp-bpf], which is the main syscall-filtering facility. | |||
We're primarily using seccomp-bpf because it's the only thing that's available everywhere (>99% of the Linux Firefox userbase, at last count). There are some weaknesses to using only seccomp-bpf: | We're primarily using seccomp-bpf because it's the only thing that's available everywhere (>99% of the Linux Firefox userbase, at last count). There are some weaknesses to using only seccomp-bpf: | ||