Date: Tue, 09 Feb 1999 07:44:28 +0000 From: Karl Pielorz <kpielorz@tdx.co.uk> To: current@FreeBSD.ORG Subject: Re: adding DHCP client to src/contrib/ Message-ID: <36BFE75C.E7EC4DCC@tdx.co.uk> References: <199902090639.WAA08295@kithrup.com> from Sean Eric Fagan at "Feb 8, 1999 10:39:29 pm" <199902090718.XAA10270@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Eric Fagan wrote about the security implications of making the bpf device the default in GENERIC etc. > I'm sorry, but that's a complete non-issue: > > 1. /dev/bpf0 is mode 400, root.wheel -- to read it, you need to break root. > 2. If you can break root, you can rebuild a kernel with BPF *anyway*. Sorry - I disagree with that... We run an ISP on FreeBSD, and we'd damn well notice someone _rebooting_ (or even trying to reboot one of our machines (to get their new kernel to work it's magic) - Heck, our machines _don't_ reboot from a 'shutdown -r'! - they're AST's! :) Whilst the argument about removing the source tree / kernel source etc. has always been pretty mute (what hackers not worth their salt don't come prepared? :) - I don't like the idea of every root exploiter just being able to 'instantly' sit there and run BPF! (Without even things like tripwire having a chance of detecting a kernel change). I'd much rather having the hacker either blocked from doing this, or having to spend time doing it (e.g. getting the source / new kernel to the machine etc. - the longer the better)... I think having bpf compiled in by default is going to be a Bad Move (tm). It _usually_ follows if some new user has the ability to recompile the kernel with it 'in' - they have enough sense to know the implications, put it in by default and you'll be giving every root hacker (or box where root access is sadly routine - and I know probably shouldn't be) an instant christmas present on those kind of machines... (I know theres probably ways of doing this with kern_secure_level, but that defaults to 'NO' at the moment :) Just my $0.04! (and no, it's not on fire... :) -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36BFE75C.E7EC4DCC>