Message-ID: <20050712142727.P79478@fledge.watson.org>
Date: Tue Jul 12 14:55:55 2005
From: rwatson at FreeBSD.org (Robert Watson)
Subject: Possible security issue with FreeBSD 5.4
	jailing and BPF


On Tue, 12 Jul 2005, ronvdaal wrote:

>>> Usage of devfs rulesets is highly recommended as stated in the 
>>> manpages. Though a misconfiguration at this point would expose a big 
>>> security issue. The question is: should bpfopen() in bpf.c check for a 
>>> jailed proc or not?
>> 
>> This is not really a security bug since, as stated in the jail(8) 
>> manual, you should use devfs rulesets if you are using jails as a 
>> security measure.  Exposing a complete /dev file-system inside a jail 
>> is a bad idea security wise, not just with regards to BPF.
>
> I'm figuring out the reason why the jailing check has been removed from 
> the BPF code in the kernel source tree (if on purpose). Does this have a 
> reason? Because it was right there in the 4.x series kernels. And it's 
> also present in other parts of the 5.x kernel source. Therefore it seems 
> to be forgotten.
>
> While saying that this isn't a security bug, you're actually stating 
> this has turned into a "feature", allowing the privileged user on the 
> host box to decide which jailed root user can put ethernet devices into 
> promiscious mode. (...) However, if it's a feature not a bug - then 
> where is it documented?

Removing the jail check in BPF was an intentional change, as in FreeBSD 
5.x and higher, the devfs rules mechanism is the appropriate protection 
for administrators to use to prevent BPF access from within a jail.  The 
nature and intention of the change is described in the CVS commit message 
for bpf.c:1.77 in the FreeBSD CVS repository, and you'll notice that the 
default devfs rule set for jails does not allow jails access to BPF 
devices.  If in doubt about whether a change in FreeBSD is intentional, 
the CVS history is generally a useful first reference; if the commit 
message isn't clear, an e-mail to the author of the change will usually 
serve as a good starting point for getting clarification or reporting a 
bug.  The current behavior is documented in the sense that the 
functionality of the BPF device is documented in detail in bpf(4), and no 
explicit "it won't work in jail" documentation exists (that I know of). 
If you are aware of specific FreeBSD documentation indicating that BPF 
will not work in jail, please let me know and we can work to get it fixed.

The reason for the change is that sometimes it is actually quite desirable 
to run with BPF in a jail: specifically, network monitoring and network 
intrusion detection systems perform complex pattern matching and other 
processing of potentially maliciously crafted network data.  Running these 
systems in constrained environments, such as FreeBSD jails, offers useful 
security benefits. I know of at least one company that specifically ships 
a network monitoring product in this configuration in order to limit the 
scope for damage in the event that a vulnerability in the monitoring 
software is found.

This jail case is actually quite similar to another important case, in 
which the administrator delegates the right to use BPF to a process by 
changing the protections on /dev/bpf* so that non-root users can use BPF. 
This delegates specific rights, and should be done in an informed way, but 
is a valuable tool to reduce the quantity of code running with unnecessary 
privilege (ie., root privilege where just BPF use is needed).

Specifically on the issue of promiscuous mode: normally, setting 
promiscuous mode on a network interface on FreeBSD requires root 
privilege.  However, holders of a reference to a BPF descriptor are able 
to ioctl() the descriptor to enable promiscuous mode regardless of their 
real or effective process credential.  Administrators delegating the right 
to use BPF should be aware of this, and consider it carefully. 
Documentation of the ioctl can be found in the bpf(4) manual page. 
Applications should actually be written to function correctly whether or 
not promiscuous mode is in the state that they expect: because promiscuous 
mode is a global property of the interface, and BPF explicitly monitors 
packets seen by the interface, applications cannot rely on promiscuous 
mode not being enabled even if they haven't explicitly enabled it.

Thanks,

Robert N M Watson

Powered by blists - more mailing lists