Re: [ 01/10] [Suspend2] kernel/power/modules.h

[Nigel Cunningham <nigel@suspend2.net>]

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