Hi. On Thursday 02 February 2006 20:39, Pavel Machek wrote: > Hi! > > > > > I'm more concerned about the security implications. I'll freely admit > > > > that I haven't spent any real time looking at your code, but I'm > > > > concerned that the additional functionality made available could be > > > > used by viruses and the like. I'm sure you'd have to be root to do > > > > anything, but how could the interfaces be misused? > > > > > > In vanilla kernel userland suspend has no security implications: root > > > can just do what he wants in /dev/mem, anyway. > > > > Ok. > > > > > 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 the corruption would be detected at resume time because the data wouldn't decompress properly. The hypothetical malicious program wouldn't be able to assume that blocks are page aligned, or that a particular compression method was used. Encryption might also be used, and that could be using any of the cryptoapi modules in any valid configuration. Regards, Nigel -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode
Attachment:
pgpiiP7nKkLBq.pgp
Description: PGP signature
- Follow-Ups:
- Re: [ 01/10] [Suspend2] kernel/power/modules.h
- From: Pavel Machek <[email protected]>
- Re: [ 01/10] [Suspend2] kernel/power/modules.h
- References:
- [ 00/10] [Suspend2] Modules support.
- From: Nigel Cunningham <[email protected]>
- Re: [ 01/10] [Suspend2] kernel/power/modules.h
- From: Nigel Cunningham <[email protected]>
- [ 00/10] [Suspend2] Modules support.
- Prev by Date: Re: [BUG] sizeof(struct async_icount) exported to userspace on SH, SH64 and xtensa
- Next by Date: Re: [lock validator] inet6_destroy_sock(): soft-safe -> soft-unsafe lock dependency
- Previous by thread: Re: [ 01/10] [Suspend2] kernel/power/modules.h
- Next by thread: Re: [ 01/10] [Suspend2] kernel/power/modules.h
- Index(es):
 |