2 ms·
I don't think they fail. Usually you profile the program first, and once you set up the rules, a deviation might get blocked. If you want to define what the pro
by dvfjsdhgfv 8y ago
I don't think they fail. Usually you profile the program first, and once you set up the rules, a deviation might get blocked. If you want to define what the program is definitely not authorized to do, this is the way to go.
Using the unveil() is a completely different approach that should yield less false positive and involve less hassle. There is just one caveat: you need to make sure the binary hasn't been tampered with. If someone replaced/modified it, SELinux will block unauthorized behavior, whereas counting on unveil() still working in this case might let you down.
- Someone 8y ago”If someone replaced/modified it […] counting on unveil() still working […] might let you down.” Might is an understatement. If somebody changed what you run, there’s no guarantee at all that it even still calls unveil. However, I would think chances that your system is set up such that third parties can tamper with your binaries are about equal to those that the system setup allows them to ‘tweak’ your SELinux configurations.