On Wed, 2007-09-19 at 09:38 +0200, Thorsten Leemhuis wrote:
On 19.09.2007 09:09, Alexander Larsson wrote:
> On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
>> Thus I'm not even able to read from it:
>> $ dd if=/dev/sda3 bs=512K count=1 | strings
>> dd: opening `/dev/sda3': Permission denied
>> Life sucks, but that's how things are supposed to be in linux/unix land
>> as far as I know. But well, for fuse there seem to exist different rules:
>> $ mkdir ntfs
>> $ /sbin/mount.ntfs-3g /dev/sda3 ntfs/
>> $ touch ntfs/foo
>> $ ls -l ntfs/foo
>> -rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo
>> Which brings me to my questions: Can somebody please explain why the
>> above it working? Does it mean that if I write my own malicious
>> fuse.ext3 userspace driver that I can mount each and every block-device
>> on my system and read or modify the files on it (all by using fuse)?
>> What if there is a small error in mount.ntfs-3g somewhere -- could it be
>> abused to destroy a partition on my system while being a ordinary user?
> Thats quite weird. [...]
Agreed. But I got the impression that how some users expect it to work.
> Is /sbin/mount.ntfs-3g setuid perhaps?
$ ls -l /sbin/mount.ntfs-3g
-rwsr-xr-- 1 root fuse 40528 26. Aug 16:50 /sbin/mount.ntfs-3g
Oh. That seems like a bad idea to me. If this drops privs after opening
the device I think you can attach to the process using e.g. gdb and call
any read() operation on the device. If might even mean (with some
creative exploits) that any fuse group user can read any block on any
I think the "fuse" group thing is a bad idea for /sbin/fusermount, but
for something like this it might make sense. Although its probably
better to not have mount.ntfs-3g setuid and just force the user to be in
the "disk" group, as that makes it more obvious what this is about.