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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel