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!
