Date: Thu, 2 Feb 2006 11:39:47 +0100
From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <nigel@suspend2.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Pekka Enberg <penberg@cs.helsinki.fi>,
       linux-kernel@vger.kernel.org
Subject: Re: [ 01/10] [Suspend2] kernel/power/modules.h
Message-ID: <20060202103947.GB1884@elf.ucw.cz>
References: <20060201113710.6320.68289.stgit@localhost.localdomain> <200602021922.11100.nigel@suspend2.net> <20060202101626.GD1981@elf.ucw.cz> <200602022029.32524.nigel@suspend2.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200602022029.32524.nigel@suspend2.net>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1956
Lines: 40

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.
								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/