blob: 821dea673ff6d0f2d69c8f4fa6aaa2e32861511b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
Is it necessary to have some loopholes in the sandboxing system?
See also:
https://lobste.rs/s/kl1gd6/seccomp_unsafe_at_any_speed_2022
* Access to debug info files (which can be separate files).
- Where are those stored?
* Loading plugins
- /usr/lib
* Reloading configuration as needed:
- /etc/xxx
- ~/.config/xxx
* Checking CPU info, for example to check SIMD support
- /proc/cpuinfo
- Could be done at startup?
- Actually, this could leak information and/or maybe work as a
side-channel? For example, it includes the "cpu MHz" value.
How to restrict access to a specific directory
- Can openat / openat2 do it? It seems that `..` might always be accessible?
- But a seccomp filter could enforce RESOLVE_BENEATH in all calls
- Have a seccomp filter that allows open/openat/openat2 with a specific
pointer in .rodata? And mseal() that page.
- Could have a separate process, and communicate to it via a pipe and/or
by sending fd's.
|
