Re: [linux-pm] [RFC] userland swsusp
From: Pavel Machek
Date: Sun Nov 20 2005 - 17:09:48 EST
> > > > > 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
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?]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/