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: <20050712123851.GD73197@eddie.nitro.dk> Date: Tue Jul 12 13:38:57 2005 From: simon at FreeBSD.org (Simon L. Nielsen) Subject: Possible security issue with FreeBSD 5.4 jailing and BPF On 2005.07.12 13:20:06 +0200, ronvdaal wrote: > >>While playing around with FreeBSD 5.4 and jailing I discovered that it was > >>possible to put an ethernet interface into promiscious mode from within > >>the > >>jailed environment, allowing a packetsniffer to gather data not meant for > >>the jailed box. This also affects FreeBSD 5.3 (tested) but not FreeBSD 4.x > >>This can be reproduced on boxes where BPF support is enabled in the kernel > >>and a BPF device is available in the jail (badly configured devfs/no > >>rules) > >[...] > >>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. Yes, it could be considered a feature since you might want to use jails to partially restrict a program that needs BPF access (and of cause you would be aware of the different tradeoff's while doing that). The commit that removed the explicit jail check: http://cvsweb.FreeBSD.org/src/sys/net/bpf.c#rev1.77 : Remove unnecessary jail() check in bpfopen() -- we limit device access in jail using /dev namespace limits and mknod() limits, not by explicit checks in the device open code. > (...) However, if it's a feature not a bug - then where is it documented? I don't think this change is documented anywhere, but I can't really see where it should be documented since it's just a change in behavior between two FreeBSD major versions. Anyway, if you want to discuss this further I would suggest you mail one of the appropriate FreeBSD mailing lists. -- Simon L. Nielsen FreeBSD Security Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050712/905b377c/attachment.bin
Powered by blists - more mailing lists