Gentoo Archives: gentoo-hardened

From: lists@×××.org
To: gentoo-hardened@g.o
Subject: Re: [gentoo-hardened] Just joined, normallly would lurk, but...
Date: Tue, 11 Mar 2003 22:06:43
Message-Id: Pine.LNX.4.53.0303111701540.28046@nautilus.m8y.org
In Reply to: Re: [gentoo-hardened] Just joined, normallly would lurk, but... by Alain Penders
1 On Tue, 11 Mar 2003, Alain Penders wrote:
2
3 > Yes, but:
4 >
5 > - "bash -c 'source abc'" still works, and does not require abc to be
6 > executable. Hence, protecting against setting the x bit does not prevent
7 > execution.
8 >
9 > - All commands needed to compromise the system are already signed and +x'd.
10
11 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.
12 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.
13
14 > Overall, this scheme doesn't seem to give any more security than a regular
15 > tripwire does. Giving access denied on a chmod() only educates a hacker on
16 > what does and does not work, and all he has to do is figure out how to
17 > compromise the system to the point where he can safely replace executables.
18 >
19 > All you can do while he's doing that is read log files and hope you'll catch
20 > the failed attempts he might have made.
21 >
22 > Very similar to tripwire, where a cracker would have to jump through the same
23 > hoops to avoid detection.... and the detection process isn't any faster.
24
25 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...
26
27 > From what I understand, SELinux and the new security framework in the 2.5
28 > kernels do a waaaaay better job at detecting all the various things one can
29 > screw with, and actually stopping crackers.
30
31 *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 :-)
32
33 I take it gentoo will simply use the 2.5 security framework?
34
35
36 --
37 gentoo-hardened@g.o mailing list