On Sat, Apr 13, 2013 at 08:36:53PM +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(1) -fstack-protector{,-all} doesn't implement full bounds checking for every C object.
But it prevents (with probability (256^n-1)/256^n, where n is the size of the canary in bytes, which for n=4 is approximately .99999999976717) exploiting the overflows to change the return address of any C function.
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 do know quite a lot about this, having written the very first bounds checking extension to GCC back in 1994/5:
http://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
(2) SELinux controls what labelled resources a process can access. This covers far more than buffer overflows in C programs. It covers other programming languages, design flaws and implementation 'thinko's of all sorts. I would argue (separate from this) that it's good to define precisely what resources a program can access, rather than the default "access just about everything".
And I would argue that this amounts to second-guessing/duplicating what the program tries to do in an unmaintainable morass of rules, which even for the targeted policy (which is not even close to covering all programs in Fedora other than as "unconfined") keeps having bugs which need to be fixed every day, even after YEARS of debugging. SELinux just does not scale, it's a centralized database which needs to essentially contain a variant of every program's source code, rewritten in a rule language only few people actually comprehend.
That's your opinion. I suggest you take a look at SELinux policies as well as the many new policy management tools.
Instead of duplicating the information already contained in the program's source code, the right approach is to ensure the program does not do anything that is NOT part of its source code, which means blocking arbitrary code execution exploits!
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.
Rich.