Date: Fri, 30 Jul 1999 16:21:35 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... Message-ID: <Pine.BSF.4.10.9907301619280.6951-100000@janus.syracuse.net> In-Reply-To: <Pine.BSF.4.10.9907301608140.6951-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
> > talking about how to make things work in the post-installation boot
> > scenario.
>
> When did that happen? :)
>
> In that case, my argument changes to:
> "There's no good reason not to have bpf in the GENERIC kernel."
And how about having
if (securelevel > 3)
return (EPERM);
in bpf_open()?
Here's a nice, relevant excerpt from security(7):
SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS
If an attacker breaks root he can do just about anything, but there are
certain conveniences. For example, most modern kernels have a packet
sniffing device driver built in. Under FreeBSD it is called the `bpf'
device. An intruder will commonly attempt to run a packet sniffer on a
compromised machine. You do not need to give the intruder the capability
and most systems should not have the bpf device compiled in.
But even if you turn off the bpf device, you still have /dev/mem and
/dev/kmem to worry about. For that matter, the intruder can still write
raw devices. Also, there is another kernel feature called kldload(8).
An enterprising intruder can use a KLD module to install his own bpf de-
vice or other sniffing device on a running kernel. To avoid these prob-
lems you have to run the kernel at a higher secure level, at least se-
curelevel 1. The securelevel can be set with a sysctl on the kern.se-
curelevel variable. Once you have set the securelevel to 1, write access
to raw devices will be denied and special chflags flags, such as `schg',
will be enforced. You must also ensure that the `schg' flag is set on
critical startup binaries, directories, and script files - everything
that gets run up to the point where the securelevel is set. This might
be overdoing it, and upgrading the system is much more difficult when you
operate at a higher secure level. You may compromise and run the system
at a higher secure level but not set the schg flag for every system file
and directory under the sun.
>
> >
> > - Jordan
> >
>
> Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
> green@FreeBSD.org _ __ ___ | _ ) __| \
> FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
> http://www.FreeBSD.org/ _ |___/___/___/
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9907301619280.6951-100000>