lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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