Expanding the list of "Hardened Packages"

Kevin Kofler kevin.kofler at chello.at
Sat Apr 13 23:43:05 UTC 2013


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



More information about the devel mailing list