qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] tcmu: Introduce qemu-tcmu


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH RFC] tcmu: Introduce qemu-tcmu
Date: Fri, 21 Oct 2016 18:33:35 +0800
User-agent: Mutt/1.7.0 (2016-08-17)

On Fri, 10/21 10:54, Stefan Hajnoczi wrote:
> On Fri, Oct 21, 2016 at 08:11:47AM +0800, Fam Zheng wrote:
> > On Thu, 10/20 10:21, Andy Grover wrote:
> > > On 10/20/2016 07:30 AM, Fam Zheng wrote:
> > > > On Thu, 10/20 15:08, Stefan Hajnoczi wrote:
> > > > > If a corrupt image is able to execute arbitrary code in the qemu-tcmu
> > > > > process, does /dev/uio0 or the tcmu shared memory interface allow get
> > > > > root or kernel privileges?
> > > > 
> > > > I haven't audited the code, but target_core_user.ko should contain the 
> > > > access to
> > > > /dev/uioX and make sure there is no security risk regarding buggy or 
> > > > malicious
> > > > handlers. Otherwise it's a bug that should be fixed. Andy can correct 
> > > > me if I'm
> > > > wrong.
> > > 
> > > Yes... well, TCMU ensures that a bad handler can't scribble to kernel 
> > > memory
> > > outside the shared memory area.
> > 
> > Thanks!
> > 
> > > 
> > > UIO devices are basically a "device drivers in userspace" kind of API so
> > > they require root to use. I seem to remember somebody mentioning ways this
> > > might work for less-privileged handlers (fd-passing??) but no way to do 
> > > this
> > > exists just yet.
> > 
> > In my example in the cover letter I use chmod + non-root which seems to be
> > working properly. So I think fd-passing is a promising mechanism.
> 
> Is there any way to use the in-kernel SCSI target without root?
> 
> For example, if an unprivileged user wants to run an iSCSI target on an
> unprivileged port to serve up a regular file (test.img).

No, not possible even on an unprivileged port AFAICT. Accessing targetcli
requires root.

> 
> If the answer is no then it's unlikely qemu-tcmu can ever be used
> without root anyway...

So you are right.. One possibility is we can implement some helper
functionalities in a daemon (such as tcmu-runner, or a new one), to which an
unprivileged qemu-tcmu then communicates this "export this LUN at XXX"
requests with a DBus call, similar to how libtcmu registers the new handler on
behalf of the program.

Fam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]