[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Head Up: Prepare for dropping fuse group in the nearest future



On Fri, 2008-02-08 at 08:32 -0500, Steve Grubb wrote:
> On Friday 08 February 2008 07:26:53 Alexander Larsson wrote:
> > On Thu, 2008-02-07 at 10:29 -0500, Steve Grubb wrote:
> > > > Now, Gnome (and many other things) start using fuse because it lets you
> > > > implement very desireable features.
> > >
> > > What are these desirable features? Just curious since I may wind up doing
> > > a lot of code review.
> >
> > There are many cases where you as a user want to access and/or modify
> > something that contains files.
> 
> Which brings up something, I spent the last 3 years getting the audit system 
> working everywhere. Does filesystem auditing still work under fuse? When a 
> user mounts a filesystem, is that auditable? Does fuse support extended 
> attributes & SE Linux enforcement is still working correctly?

I don't know about auditing. But the extended attributes and selinux
question is a bit weird. Fuse itself supports extended attributes in the
sense that the request for attributes is proxied to the filesystem
implementation. Whether there is support for reading and/or writing of
extended attribute on a particular filesystem type is entierly up to
that filesystem implementation. For instance, its highly unlikely that a
ftp backend supports extended attributes, since that is not part of ftp.

As for enforcement, by default fuse itself doesn't do permissions
checks, and its up to the filesystem implementation to handle this
(based on whatever security model the implemented filesystem has).
However, the filesystem itself runs as the user, so it will itself be
protected by selinux and cannot access anything the user normally
cannot.

As for general security issues. In order to avoid problems fuse
filesystems are limited in some ways. From the docs:

        There must however be some limitations, in order to prevent Bad
        User from doing nasty things.  Currently those limitations are:
        
          - The user can only mount on a mountpoint, for which it has
        write
            permission
        
          - The mountpoint is not a sticky directory which isn't owned
        by
            the user (like /tmp usually is)
        
          - No other user (including root) can access the contents of
        the
            mounted filesystem.

> > However most apps don't use these interfaces so they can't access files
> > like this. The standard way to access files is through the syscall
> > interface, and then things must be mounted, meaning the implementation
> > generally lives in the kernel with all the issues related to that.
> 
> And the protection to the system enforced by the kernel. :)

Well, the fuse filesystem is implemented as a process running on said
kernel, so the protection that the kernel gives the client process it
also gives to the fuse filesystem process.

> > Some things like loopback mounting an iso is possible, but requires root
> > access, even if the file is readable by the user. Other things are just
> > not possible.
> 
> Which is sensible. Remember my fsfuzzer tool? Its found some flaws in 
> fliesystems that could be exploitable with some work. I have not yet had the 
> time to fuzz fuse since its never really be seriously considered for any of 
> our work.

I know perfectly well why you need root to mount a kernel-based
filesystem. But if you find an exploit in a fuse filesystem you cannot
really do anything you couldn't already do. I mean, if you can run
fsfuzzer against the filesystem you already have all the rights of the
filesystem, so an exploit does not give you a priviledge increase. Nor
does it make the kernel unstable.

> > However, with fuse these things can be solved. The filesystem
> > implementation runs as the user, and user syscalls are proxied to the
> > filesystem process via a pipe.
> 
> You cannot do auditing from userspace very well. It requires CAP_AUDIT_WRITE 
> and maybe some other permissions.

I'm not sure what exactly you want to audit. Say you have an iso file in
your homedir. You mount this file using a fuse loopback isofs. Then you
access a file on the mounted filesystem. Then you run some app that
opens a file on the image. What do you want to record?

The full path of the file on the mounted filesystem is passed through
the kernel, so that can be recorded. Then you have the filesystem
process that opens and reads from the iso file, this will also be
visible to the kernel and it could audit things from there.

> > This means that anything "filesystem like" that can be accessed from
> > userspace can be accessed by all applications. So, for instance, you can get
> > things like remote filesystem access via ssh, easily mountable network
> > filesystems (smb, ftp, nfs) and user-mountable loopback mounts.
> 
> But we already have things like that with auditing and security checks in 
> place. :)  

No, we don't. Not for users. Only for root. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]