On Thu, 15 Feb 2007, Roman Zippel wrote:
On Thu, 15 Feb 2007, David Howells wrote:
It is possible to protect /dev/mem and /dev/kmem or make them unavailable and
it is possible to protect the kernel's memory whilst it is running (provided
you don't have nommu or broken hardware and you don't let userspace concoct any
DMA request it likes) which mostly closes those other vectors I mentioned.
This isn't something I intended to look at with this patch. Those are separate
holes.
Exactly and as long as there are these holes, these patches are only
kernel bloat. The simple verification can also be done in userspace and
module signing offers no real security.
What real value do these patches provide, that can't be reached via other
means? Who else than distributions would be interested in this? Pretty
much any use you initially mentioned can be done in simpler ways, e.g.
anyone afraid of modules simply disables module loading completely.
this issue, and these holes keep comeing up in discussions, why can't these
holes be closed? I seem to remember seeing patches that would remove /dev/kmem
being sent to the list, but they weren't accepted into the kernel (and I seem to
remember people being against the concept of removeing them, not against
techincal details of the patches. but this was many years ago)
at one point I remember hearing that X required raw /dev/kmem, but for servers
you don't need/want X anyway, so this is a useful option even if X doesn't get
fixed.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
