2 ms·
It's a second safety net. It probably can be used by lazy programmers, but that's not what it is intended for. The idea is "make it impossible for my app to mi
by rocqua 5y ago
It's a second safety net. It probably can be used by lazy programmers, but that's not what it is intended for.
The idea is "make it impossible for my app to misbehave in certain ways". It is a lot easier to enforce this at the kernel (don't need to check every usage of e.g. open() ).
Moreover, there isn't really a way to screw this up through a logic mistake.
But most of all, to say with absolute certainty your software does not allow unintended remote code execution is nigh impossible for anything complex. By adding this, you reduce the possible downsides of any such exploit. It also helps you detect such exploits earlier.
It's similar to the kernel using address layout randomization, compiling with stack-guards, having non-executable stack, etc. It is defense in depth.