Miklos Szeredi wrote:
quoted text
>> Another thing is that as it currently stands, the kernel side FUSE
>> implementation forms a nice safety net taking responsibility of most
>> security concerns and insulating the mistakes the client may make.
>> Letting userland client to access and possibly modify the caller's
>> memory directly weakens that insulation.
> 
> The same stupid mistakes can be done by giving the wrong instructions
> to the kernel about what to modify, thus thrashing the calling
> process.

Yeah, ioctl, by design, has that potential.  Whether it's implemented in
kernel or userland, it's gonna access arbitrary memory regions from deep
down the implementation, and it can corrupt things, but by giving the
responsibility to move data to kernel part of FUSE, we can at least
guarantee that it's only gonna ruin the calling address space even when
it screws up and when that happens it will be easy to track down by
tracing the communication between the kernel and FUSE client.

quoted text
>> Pushing memory access to userland feels a bit too risky to me.  There
>> seem to be too many loose components in security sensitive path and I
>> have a nagging feeling that someone will come up with something we can't
>> think of at the moment.
> 
> I don't see the difference.  You have to be careful either way, it's
> not possible to do ioctls safely as the rest of fuse unfortunately.
> This obviously also means, that it's impossible to run the filesystem
> as an unprivileged user, as it has to have access to the whole address
> space of the calling process either way (or ioctls have to be
> restricted somehow).

I'm not worried about the client accessing wrong memory regions or even
corrupting it.  It's pointless to try to protect against that.  From the
calling process's POV, it runs the same risk whether it calls an
in-kernel ioctl or a CUSE one and FUSE already has sufficient protection
against allowing unprivileged FS implementation to serve other users.

What I'm worried about is the possibility of CUSE client being able to
break out of that privilege protection which is currently ensured by the
kernel.  Also, what about containers?  How would it work then?

Thanks.

-- 
tejun
--
unsubscribe notice
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/