Expanding the list of "Hardened Packages"

[Richard W.M. Jones]

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