4 ms·
The use case here is a process saying "I don't trust my future self not to do something stupid". Mseal alone doesn't seem enough for that. There are plenty of
by londons_explore 3y ago
The use case here is a process saying "I don't trust my future self not to do something stupid".
Mseal alone doesn't seem enough for that. There are plenty of other API's that would also need locking down - and many future API's too. This looks like a big maintenance burden forever into the future.
Perhaps a better model is seccomp BPF. Allow a process to install a seccomp BPF filter on itself. The filter could prevent calling mmap, mprotect, mremap and friends. The filter could also prevent the modification of the installed filter.
That seems far more general and far more powerful and requires less kernel code with only a handful of uses.
- supriyo-biswas 3y agoChrome already uses seccomp-bpf to that end, this is why the `chrome-sandbox` binary is setuid.
- londons_explore 3y agoPerhaps the real solution here is to let non-root use seccomp-bpf.
- boustrophedon 3y agoNon-root can use seccomp-bpf. Chrome already does.
- londons_explore 3y agoSo theres nothing preventing OP implementing what they want entirely in userspace with no kernel changes already?
- jagrsw 3y agomalloc can use mmap (aside from s/brk) - it's impossible these days to sandbox any more complex program and not allow mmap (arguments can be limited though to only a subset of flags).
- londons_explore 3y agoBut that would be the same for both this proposed mseal() and my proposed seccomp solution.
- Varriount 3y agoDoesn't OpenBSD have an API that has this kind of functionality too, albeit in a slightly simpler form?
- skywal_l 3y agopledge and unveil.
- masklinn 3y agopledge(2)? That’s generally about blacklisting syscalls though a few options allow carveouts (mostly around file system access). Sealing memory mappings is a lot lower level, and more fine-grained.
- tristan957 3y agohttps://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- akaij 3y agoLinux port by @jart: https://github.com/jart/pledge https://github.com/jart/pledge
- brynet 3y agoNot pledge. This is an overdesigned, overcomplicated clone of mimmutable. https://man.openbsd.org/mimmutable https://man.openbsd.org/mimmutable The OpenBSD kernel does automatic immutable for certain regions (e.g: stack, program text, bss), as well as from ld.so. Ironically, mimmutable(2) is already used in the OpenBSD chromium port for v8. https://marc.info/?l=openbsd-ports-cvs&m=168854379207826&w=2 https://marc.info/?l=openbsd-ports-cvs&m=168854379207826&w=2 There is absolutely no excuse for Google to propose something different for no reason.