linux-kernel - Re: [PATCH 5/7] FUSE: implement ioctl support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48B6FFB6.7000104@kernel.org>
Date:	Thu, 28 Aug 2008 21:42:46 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	greg@...ah.com, fuse-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] FUSE: implement ioctl support

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.

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.

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.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/