From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-hardened-return-8-arch-gentoo-hardened=gentoo.org@gentoo.org> Received: (qmail 9653 invoked by uid 1002); 11 Mar 2003 22:06:43 -0000 Mailing-List: contact gentoo-hardened-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-hardened@gentoo.org> List-Help: <mailto:gentoo-hardened-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-hardened-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-hardened-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-hardened.gentoo.org> X-BeenThere: gentoo-hardened@gentoo.org Received: (qmail 18223 invoked from network); 11 Mar 2003 22:06:43 -0000 Date: Tue, 11 Mar 2003 17:06:42 -0500 (EST) From: lists@m8y.org X-X-Sender: nemo@nautilus.m8y.org To: gentoo-hardened@gentoo.org In-Reply-To: <20030311215533.GA1750@purematrix.com> Message-ID: <Pine.LNX.4.53.0303111701540.28046@nautilus.m8y.org> References: <Pine.LNX.4.53.0303111602250.28046@nautilus.m8y.org> <20030311212853.GB1664@purematrix.com> <Pine.LNX.4.53.0303111634330.28046@nautilus.m8y.org> <20030311215533.GA1750@purematrix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [gentoo-hardened] Just joined, normallly would lurk, but... X-Archives-Salt: 66947ead-eecb-4a1d-a588-c5b2a326be58 X-Archives-Hash: f8613f057c672d9c03d995c4f6b94f46 On Tue, 11 Mar 2003, Alain Penders wrote: > Yes, but: > > - "bash -c 'source abc'" still works, and does not require abc to be > executable. Hence, protecting against setting the x bit does not prevent > execution. > > - All commands needed to compromise the system are already signed and +x'd. No disagreement on either point. That's why I thought their idea of signing the executables themselves was cooler. Their implementation was indeed rather trivial. It is true the exploitable code is already signed, but normally an exploit is used to bootstrap one's self into the system. Hard to do if the executable has tightly restricted rights to what operations it can perform, and you can't add executables to the system. > Overall, this scheme doesn't seem to give any more security than a regular > tripwire does. Giving access denied on a chmod() only educates a hacker on > what does and does not work, and all he has to do is figure out how to > compromise the system to the point where he can safely replace executables. > > All you can do while he's doing that is read log files and hope you'll catch > the failed attempts he might have made. > > Very similar to tripwire, where a cracker would have to jump through the same > hoops to avoid detection.... and the detection process isn't any faster. Yep. Tripwire makes one jump through a lot of hoops, but unless you're the sort of person who carries an MD5 sum of the tripwire executable on your person at all times, you can still be compromised... > From what I understand, SELinux and the new security framework in the 2.5 > kernels do a waaaaay better job at detecting all the various things one can > screw with, and actually stopping crackers. *That* sounds much more promising. If people are already building this into the kernel then I guess there's no point in my trying to do it myself :-) I take it gentoo will simply use the 2.5 security framework? -- gentoo-hardened@gentoo.org mailing list