3 ms·
Why does file(1)[1] need its own chroot sandbox instead of using the pledge(2)[2] facility. They say: > Think of the following: You download a random file from
by avar 8y ago
Why does file(1)[1] need its own chroot sandbox instead of using the pledge(2)[2] facility. They say:
> Think of the following: You download a random file from the internet and analyze it using file. If file has a security hole (local code execution for example), he can run attacks with his prepared file. Thats why the file utility is sandboxed and chrooted by default.
Isn't that exactly the sort of case where file(1) would open(2) the downloaded file and its own database, and then proceed to drop all other access privileges before doing any of the parsing of the untrusted file?
1. https://why-openbsd.rocks/fact/file/ https://why-openbsd.rocks/fact/file/
2. https://why-openbsd.rocks/fact/pledge/ https://why-openbsd.rocks/fact/pledge/
- gbrown_ 8y ago> Why does file(1)[1] need its own chroot sandbox instead of using the pledge(2)[2] facility. It does use pledge(2) these days, those references are to how file(1) was sandboxed before. Why the author has linked to that I don't know.
- avar 8y agoYeah, on closer inspection their page describing the sandbox links to the CVS commit where the sandbox implementation was deleted in favor of tame(2), the predecessor of pledge(2).