Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek <pavel@ucw.cz>]

Hi!

>  > >  > > Just for info: If this goes in, Red Hat/Fedora kernels will fork
>  > >  > > swsusp development, as this method just will not work there.
>  > >  > > (We have a restricted /dev/mem that prevents writes to arbitary
>  > >  > >  memory regions, as part of a patchset to prevent rootkits)
>  > >  > 
>  > >  > Perhaps it is trying to tell you that you should be using SELinux rules
>  > >  > not kernel hacks for this purpose ?
>  > > 
>  > > I don't think selinux can give you the granularity to say
>  > > "process can access this bit of the file only", at least not yet.
>  > > 
>  > > Even if that was capable however, it still doesn't solve the problem.
>  > > Pavel's implementation wants to write to arbitary address spaces, which is
>  > > what we're trying to prevent. The two are at odds with each other.
>  > 
>  > I do not think thats a security problem. By definition, suspending code
>  > can change arbitrary things in memory -- it could just write image with
>  > changes it desires, then resume from it. Whether this code is in kernel
>  > or not, it has to be trusted.
> 
> Stop thinking about the suspend usage case for a minute.
> 
> With your proposed changes, an attacker can scribble over random
> bits of /dev/mem without suspending in order to do whatever he
> wants.

Well, without my changes, an attacker can scribble over random bits of
memory, too; I was not the one that introduced /dev/mem :-).

> With what we have in-kernel, and a restricted /dev/mem, achieving the
> attack you mention is a lot less feasible, as the attacker has no access
> to the memory being written out to the suspend partition, even as root.
> Even if they did, people tend to notice boxes shutting down pretty quickly
> making this a not-very-stealthy attack.

Can I read somewhere about security model you are using? Would it be
enough to restrict /dev/[k]mem to those people that have right to
update kernel anyway? Or your approach is "noone, absolutely noone has
right to modify running kernel"? [Do you still use loadable modules?]

								Pavel

-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/