Date: Fri, 17 Sep 1999 14:04:10 -0600 From: Warner Losh <imp@village.org> To: Brett Glass <brett@lariat.org> Cc: Liam Slusser <liam@tiora.net>, Kenny Drobnack <kdrobnac@mission.mvnc.edu>, "Harry M. Leitzell" <Harry_M_Leitzell@cmu.edu>, security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <199909172004.OAA04763@harmony.village.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> <Pine.GSO.3.96.990916150427.5757E-100000@mission.mvnc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909172004.OAA04763>