From owner-freebsd-security Thu Nov 16 18:24: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6FF1037B479; Thu, 16 Nov 2000 18:24:02 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAH2O1Q03206; Thu, 16 Nov 2000 19:24:01 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA71161; Thu, 16 Nov 2000 19:24:00 -0700 (MST) Message-Id: <200011170224.TAA71161@harmony.village.org> To: Mike Silbersack Subject: Re: FYI: Propolice for gcc-2.95.2 Cc: Kris Kennaway , KOJIMA Hajime , security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Nov 2000 19:59:56 CST." References: Date: Thu, 16 Nov 2000 19:24:00 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message 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