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
