A story of three kernel vulnerabilities

Posted Feb 20, 2013 16:01 UTC (Wed) by drag (guest, #31333)
In reply to: A story of three kernel vulnerabilities by robert_s
Parent article: A story of three kernel vulnerabilities

> If you're saying that an exploit granting access to a user space program is just as dangerous as it having access to kernel space, I think most people would disagree with you.

No.

I am saying that taking a security problem that exists in kernel space and then trying to fix it by moving to a mixture of kernel space and userspace and throwing in a couple setuid root binaries isn't a silver bullet.

Fuse requires kernel file system features as well as setuid root binaries to operate properly. Without granting users access to /dev/fuse you can't 'mount' fuse file systems. Just granting users the ability to use fuse is a security risk in itself.

Now if you were to say that you wanted to use something like GVFS, which itself doesn't require any special privileges or fuse mounts or anything like that, then that's different. That is completely in a user account, but it's not POSIX compatible and requires programs to be GVFS aware.

A story of three kernel vulnerabilities

Posted Feb 20, 2013 16:07 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

Oh and as far as 'userspace vs kernelspace', since all this stuff requires root privileges to do, unless you want to depend entirely on GVFS and whatnot, then any exploit that gives you root access gives you kernel access. Pretty much same different, unfortunately.

A story of three kernel vulnerabilities

Posted Feb 21, 2013 19:40 UTC (Thu) by alonz (subscriber, #815) [Link]

The only setuid binary involved with using FUSE is "fusermount", which only opens /dev/fuse and immediately drops privilege. The filesystem handler itself runs as an unprivileged user.

So I, for one, really don't get your point.