Richard W.M. Jones wrote:
> I said it "doesn't implement full bounds checking for every C object",
> and I stand by that. I doesn't cover stack objects smaller than some
> cut-off size, nor any objects in static data or on the heap at all.
I never claimed it did. I said it prevents overwriting the return address on
the stack to execute arbitrary code. That's all it ever claimed to do. But
it is sufficient to prevent the majority of arbitrary code execution
exploits. And there is no cutoff size with -fstack-protector-all.
Now if you think the protection is not sufficient, then what you actually
want is to enable one of the full bound-checking solution, though the
performance and code size impact of that would be a lot larger. Still,
papering over the fact that code is exploitable by duplicating all
information about what the code is supposed to do elsewhere (in SELinux
policy) does not make sense, it is simply not a maintainable approach.
> That's your opinion. I suggest you take a look at SELinux policies as
> well as the many new policy management tools.
One needs to read pages of documentation to even do the small subset of
tweaks intended for an end user. Maintaining the actual policy is something
only a handful people are able to do.
> This would be excellent, and projects in this area could make a
> significant contribution. I suspect that any general code-to-policy
> translator will hit the Halting Problem, since it seems trivial to
> write a program which would not be possible to translate, but that
> doesn't mean it can't be solved for many useful real world cases.
That's exactly why SELinux policy is the wrong representation. It duplicates
information of the code without being automatically transformable either
way, requiring every change to be made twice.
I repeat: The proper solution is to prevent executing any machine code which
is not part of the program's source code. Block arbitrary-code execution
exploits and SELinux is just dead weight.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
