Date: Mon, 02 Aug 2004 14:14:09 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) To: Matteo Riondato <rionda@riondato.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha mem.c src/sys/alpha/conf GENERIC src/sys/alpha/include memdev.h src/sys/amd64/amd64 io.c mem.c src/sys/amd64/conf GENERIC NOTES src/sys/amd64/include iodev.h memdev.h src/sys/conf NOTES files files.alpha files.amd64 ... Message-ID: <xzpu0vlaga6.fsf@dwp.des.no> In-Reply-To: <1091447175.2201.48.camel@kaiser.sig11.org> (Matteo Riondato's message of "Mon, 02 Aug 2004 13:46:15 %2B0200") References: <200408011140.i71BesOt070889@repoman.freebsd.org> <xzpy8kxai03.fsf@dwp.des.no> <1091447175.2201.48.camel@kaiser.sig11.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Matteo Riondato <rionda@riondato.com> writes: > Dag-Erling Sm=F8rgrav wrote: > > The other good news of course is that it is now possible to build a > > kernel that does not have /dev/mem and /dev/io - that's pretty > > significant from a security point of view. Thanks! > Can you please explain why it's signficant? /dev/mem and /dev/io are back doors to a system's memory and hardware, which allow you to bypass all error and credential checks once you've gained access to them. For instance, an attacker which manages to obtain read access to /dev/mem (e.g. by exploiting a hole in a setgid kmem application) can read any data present in system memory, including the contents of the buffer cache, and stuff like unencrypted ssh keys held in memory by an ssh agent. Of course, /dev/mem and /dev/io can be protected through conventional means (including removing the actual device nodes), but given the choice between protecting a back door and not having one in the first place, I definitely prefer the latter. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpu0vlaga6.fsf>