Date: Thu, 16 Sep 1999 07:09:00 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Brett Glass <brett@lariat.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <199909161409.HAA06535@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 15 Sep 1999 20:12:54 MDT." <4.2.0.58.19990915200910.048dba50@localhost>
index | next in thread | previous in thread | raw e-mail
In message <4.2.0.58.19990915200910.048dba50@localhost>, Brett Glass
writes:
> At 09:21 AM 9/16/99 +1000, Darren Reed wrote:
>
> >If the machine is rooted, you're fucked anyway, unless it's so wired
> >down with things using file flags that you can't even use vi any more.
>
> Well, setting securelevel and making certain key files, like the kernel,
> immutable helps immensely.
>
> Say, there's a thought. Would it be possible to make a high security
> level "lock down" BPF? Or would it be possible to disable it via
> a kernel config option? One could run the kernel configuration
> utility to enable or disable it at boot.
How about a compromise? Leave BPF in the generic kernel but add a boot
option to disable it, then a site can create a loader.conf to to
disable it. To enable it an intruder would have to modify loader.conf
and reboot. This would surely be noticed -- noticed as much as an
intruder building a new kernel with BPF and rebooting. This approach
will have the advantage of leaving BPF disabled even after an upgrade.
To satisfy any new install requirements, create a sysinstall option or
question to disable it during install. We could even create a
make.conf option to add this option to loader.conf during make
installworld.
Personally, I don't see why people are so impassioned about this. I
and my team build a custom kernels for each FreeBSD, Tru64 UNIX, and
Linux system we maintain and usually maintain custom /etc/system files
for our Solaris boxes. We put in the kernel only what the kernel will
use on a system, making the kernel as small as possible. Normally we
disable BPF, however in cases where customers (usually developers) have
many complaints about inaccessibility of a host or service, we turn on
BPF, as it helps diagnose problems much more quickly.
If you build custom kernels, as I think one should, this whole issue is
irrelevant.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909161409.HAA06535>