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

[Dave Jones <davej@redhat.com>]

On Sat, Nov 19, 2005 at 11:43:32PM +0000, Pavel Machek wrote:
 > 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.

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.

		Dave

-
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/