On Thu, 28 Aug 2008, Tejun Heo wrote:
quoted text
> Miklos Szeredi wrote:
> >> Well, it's only 240 lines with good amount of comments and iovec copying
> >> function.  The ioctl itself isn't too complex.  I'm a bit skeptical
> >> about direct access.  It can easily introduce security vulnerabilities
> >> as there really is no way to hold a pid.
> > 
> > I don't understand.  No new vulnerabilities are introduced, since it
> > would just use existing infrastructure.
> > 
> > Why is it better if the kernel does the copying of memory regions
> > instructed by the userspace filesystem, than if the userspace
> > filesystem does that copying itself?  I feel they are totally
> > equivalent, except that the latter needs more complexity in the
> > kernel.
> 
> I'm no security expert but it feels pretty dangerous to me.  First of
> all, there are cases where the calling process can exit before the
> userland FUSE is finished with an operation, so it might not be always
> possible for the FUSE client to tell the PID it got is the correct one.

OK, I grant this one.  But then it's easy to protect against by
getting a ref on the task (or just the task ID, I don't know if that's
possible) for the duration of the ioctl.

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.

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

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