>
> The restricted dev/mem patches we've had in Fedora for a while
> do the right thing, but they're a bit crufty (in part due to
> drivers/char/mem.c being a bit of a mess before we even start
> patching it). I've had "clean these up for upstream" on my
> todo for a while. I might get around to
On Thu, Feb 15, 2007 at 10:13:04PM +, Pavel Machek wrote:
> Hi!
>
> > Now, this is not a complete solution by any means: the core kernel is not
> > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> > controls) one relatively simple attack vector.
>
> Could we f
Hi!
> > well, the situation for external modules is no worse than usual.
> > They still work, they just aren't signed. Which from a distributor point
> > of view, is actually a nice thing, as they stick out like a sore thumb
> > in oops reports with (U) markers :)
>
> I agree, that's really what
Hi!
> Now, this is not a complete solution by any means: the core kernel is not
> protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> controls) one relatively simple attack vector.
Could we fix the /dev/*mem holes, first? They are already used by
malicious modules (aka root
Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Feb 2007, David Howells wrote:
>> > This is really the weak point - it offers no advantage over an equivalent
>> > implementation in user space (e.g. in the module tools). So why has to be
>> > done in the kernel?
>>
>> Because the init_module(
