4 ms·
I do think a cleaner, more careful file(1) implementation is a step in the right direction. But it's still a bit unnerving to me that a bug in a utility like fi
by _delirium 12y ago
I do think a cleaner, more careful file(1) implementation is a step in the right direction. But it's still a bit unnerving to me that a bug in a utility like file(1), which needs to do nothing but read a file and output text to stdout, could possibly do things like overwrite other files, write to the network, etc., even in the presence of parsing bugs and a maliciously crafted file. A parsing bug in a utility that does nothing but read files and parse them should not be able to do anything worse than force a misparse! The file(1) binary simply does not need to have permission to do things like write to the network or disk. This seems like a shortcoming of the traditional Unix permissions model. A promising direction imo is the more fine-grained permission model of Solaris/Illumos, which FreeBSD's Capsicum project also aims in the direction of.
- BruceM 12y agoOr object capability systems in general ... like the material at http://erights.org/ http://erights.org/ and the security kernel work from long long ago: http://mumble.net/~jar/pubs/secureos/ http://mumble.net/~jar/pubs/secureos/ and http://mumble.net/~jar/pubs/secureos/secureos.html http://mumble.net/~jar/pubs/secureos/secureos.html
- geofft 12y agoWhile capability systems are totally awesome, for this sort of application, you don't really need it. Open the target file read-only, open the magic database read-only, keep stdout open, and then even something as restrictive as Linux's seccomp mode 1 sandbox (read(2), write(2), exit(2), nothing else) should be enough to let you print out an answer.
- rwmj 12y agoSELinux does exactly this already.
- benmmurphy 12y agoI thought this was basically apparmour: https://wiki.ubuntu.com/AppArmor https://wiki.ubuntu.com/AppArmor