Date: Wed, 3 Feb 1999 09:52:50 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> Cc: Eivind Eklund <eivind@FreeBSD.ORG>, Michael Richards <026809r@dragon.acadiau.ca>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, security@FreeBSD.ORG Subject: Re: tcpdump Message-ID: <Pine.BSF.3.96.990203094506.27795D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.3.96.990203092622.27795B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Alright then--assuming netgraph arrives in -CURRENT somday, then this
> would be feasible. In the mean time, they load up an lkm/kld that remaps
> the code page containing the ip_input and ip_output routines as writable,
> then replaces some of the machine code with jumps to the lkm/kld versions
> of the same routines; these routines effectively are bpfilter-esque. This
> is the nice thing about programmable computers... :)
I over-simplify. That's what I get for rolling out of bed and in front of
the computer on the way to taking a shower :). In the mean time, as I was
saying, they load up a lkm/kld that includes code tailored to their
ethernet device to put the device into promiscuous mode, and then patches
the ether_ routines pulling packets off the wire so they can be sniffed
before they pass through the ARP code. Needless to say, this would suck
like sniffing on linux without some spiffy BPF code, so either they don't
mind it being slow (they're crackers), or they also write the module to
include a BPF-like interface.
So it is definitely non-trivial; on the other hand, with modification of
the running kernel as a tool, I'm not sure it's too bad.
One solution that no-one has suggested is limiting the capabilities of BPF
in a more-fine grained way in securelevel. So BPF works by adding a
simple state machine that is programmable; by virtue of not allowing
loops, it is not Turing complete, and also has a predictable termination
by virtue of limits to program length. Libpcap presumbably builds these
BPF programs based on the requests passed to it (I know about BPF, but not
libpcap :). If you want to allow only DHCP to run, then you just add a
policy to the kernel that only specific programs are allowed. For
example, by hard configuring into the kernel, or by pushing the policy up
as part of a sysctl or the like. Something like the following:
if (securelevel > 0) {
push_bpf(allow_dhcpc_program);
push_bpf(allow_dhcpd_program);
push_bpf(allow_appletalksniffing);
}
etc.
This would increase the cost associated with loading a new program into a
bpfilter, but would not increase the cost of actual sniffing. It would
require space for policies to be stored (i.e., allow this program, etc),
but would provide a fine-grained restriction on how bpf could be used.
This would require that DHCP and other restricted uses of bpf consistently
use the same filter; I assume that this is the case; if not, then this
mechanism would not help. If it does work, then we can continue to allow
processes to open/close bpf devices once the securelevel is raised. This
would allow DHCP (and other programs like it) to be started after the
securelevel is raised, be restartable, and protect against nasties
involving debuggers attaching to processes using bpf, or other subversion
of such processes via files in the file system.
Robert N Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
Carnegie Mellon University http://www.cmu.edu/
TIS Labs at Network Associates, Inc. http://www.tis.com/
SafePort Network Services http://www.safeport.com/
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?Pine.BSF.3.96.990203094506.27795D-100000>