Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Nov 2000 19:24:00 -0700
From:      Warner Losh <imp@village.org>
To:        Mike Silbersack <silby@silby.com>
Cc:        Kris Kennaway <kris@FreeBSD.ORG>, KOJIMA Hajime <kjm@rins.ryukoku.ac.jp>, security@FreeBSD.ORG
Subject:   Re: FYI: Propolice for gcc-2.95.2 
Message-ID:  <200011170224.TAA71161@harmony.village.org>
In-Reply-To: Your message of "Thu, 16 Nov 2000 19:59:56 CST." <Pine.BSF.4.21.0011161940530.62772-100000@achilles.silby.com> 
References:  <Pine.BSF.4.21.0011161940530.62772-100000@achilles.silby.com>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0011161940530.62772-100000@achilles.silby.com> Mike Silbersack writes:
: 1.  Propolice actually stops some attacks.  While it looks great in
: theory, it doesn't sound like any commonly exploited apps have been tested
: for resiliance with propolice compilation.

I wouldn't want to give our users a false sense of security thinking
that all stack smashing attacks could be stopped by these patches.
There are an interesting number of theoretical attacks that I've read
about that it doesn't stop.

: 2.  Propolice doesn't break anything.  With the number of ports, this
: sounds like it could be extremely hard to figure out.  However, if they've
: successfully recompiled redhat with it, it can't break that many programs.

That we know of.

: Obviously the kernel wouldn't be compiled with Propolice ever.  A
: compilation of world with it would be nice in theory, but would certainly
: raise claims of slowdown.  Perhaps apps could be selectively added|removed
: from the list of protected apps in the base system based on their suid
: status and auditness?

Enabling it for setuid programs would be reasonable, assuming that it
didn't break them or introduce an unacceptible overhead.

However, there have been attacks against shell scripts running at
elevated privs where buffer overflows in unpriviledged programs were
used to get a foot in the door.  These are in the class of cgi
attacks, typically, and "shell" is used here very generically.

: Ports are really where the security's going to be an issue, as will the
: speed... I'd think propolice should be on there by default.  Experienced
: users concerned with apache running as fast as possible can use flags to
: cause its protections not to be used when compiling.

We'd need to install two libc's if we did this.  We'd need to install
a shared libc with this enabled and one without it enabled if we would 
try to split the baby.  But this might be as simple as installing them 
in separate directories.  Of course this would negatively impact
worldstone bragging rights for those that have a sub-half-hour
buildworld time now :-)

I'm sure that there are other issues involved.  Talk of enabling it by 
default is premature until someone makes the effort to port it to
FreeBSD's tree, get it integreated and do realworld performance
measurement.

Warner



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011170224.TAA71161>