From owner-freebsd-security Fri Sep 17 13: 5:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 97C4414E9F for ; Fri, 17 Sep 1999 13:05:14 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA82735; Fri, 17 Sep 1999 14:05:13 -0600 (MDT) (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 OAA04763; Fri, 17 Sep 1999 14:04:10 -0600 (MDT) Message-Id: <199909172004.OAA04763@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 18:54:24 MDT." <4.2.0.58.19990916185341.00aaf100@localhost> References: <4.2.0.58.19990916185341.00aaf100@localhost> Date: Fri, 17 Sep 1999 14:04:10 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990916185341.00aaf100@localhost> Brett Glass writes: : At 04:14 PM 9/16/99 -0700, Liam Slusser wrote: : : >Right...but if the system was hacked what would stop the hacker from : >building BPF in a kernel? : : securelevel=2 or securelevel=3. : : Or Tripwire. Dreamer. This is covered in the archives. Unless every file that root could run before secure level is raised, including any dynamically linked in libraries is set immutable, you loose. However, there is a hole the size of a truck right now in that anything that is listed in the rc.d directories gets run before the secure level is changed. Did you remember to list them all in the list of files that have schg tagged on them? Also, some programs can be run based on the presense or absense of files in /etc, which cannot be marked schg or users will be unable to change their passwords, finger information, etc. If even one of these items is missed, I can force a reboot after putting my trojan into that file, load the module and then put the file back to how it was before in an environment that will give me a good chance of restoring the damage before Tripwire can run. Also, most of the commands in /etc/rc do not include complete paths, so path games are possible. Did I forget anything? Likely. This was a 5 minute glance at the source. What would a couple of hours have revealed? If you can fix all of these problems trivially, then you might have an arguement. As it is, it takes a hell of a lot of work to keep root from running completely arbitrary commands on boot. The pain of recompiling the kernel is minor in comparison. The pain of not having DHCP is much worse... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message