Messages in this thread | | | Date | Thu, 2 Feb 2006 12:40:19 +0100 | From | Pavel Machek <> | Subject | Re: [ 01/10] [Suspend2] kernel/power/modules.h |
| |
Hi!
> > > > In fedora kernel, userland suspend can be [miss]used to snapshot an > > > > image, modify it, and write it back. Fortunately, this is going to > > > > take *long* time so people will notice. [Interface changed on DaveJ's > > > > request, now we have separate device, we no longer mess with > > > > /dev/mem]. And similar problem exists in suspend2 -- malicious > > > > graphical progress bar could probably modify memory image on disk. > > > > > > How? It's just an ordinary process with no special permissions or access > > > to memory. The communication between the userspace process and the kernel > > > is in the form of a netlink socket, with the only messages sent back and > > > forth being what should be displayed or what actions the user requested. > > > Everything related to preparing the image and performing the I/O is done > > > in the kernel. There's no way I can see that a malicious userspace > > > program could modify anything but its own memory. > > > > Fedora people have some "interesting" ideas about security. They want > > to prevent userland to modify kernel memory, root or not. AFAICS > > progress bar helper could access kernel memory while it is on disk, > > then wait for resume to pick up the modifications. > > Hi again. > > Maybe I'm just being thick, but I don't see what you mean by "progress bar > helper could access kernel memory while it is on disk". I suppose it could > potentially be given some means of writing directly to the disk that bypassed > filesystem code (remember that filesystems are frozen), but even if it could > overwrite a page of the image, most Suspend2 users compress the image, and
...yep, I said that fedora people have ""interesting"" ideas about security :-). 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/
| |