Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Eric Van Hensbergen]

On 4/11/05, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> 
>   1) Only allow mount over a directory for which the user has write
>      access (and is not sticky)
> 
>   2) Use nosuid,nodev mount options
> 
> [ parts deleted ]

Do these solve all the security concerns with unprivileged mounts, or
are there other barriers/concerns?  Should there be ulimit (or rlimit)
style restrictions on how many mounts/binds a user is allowed to have
to prevent users from abusing mount privs?

I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues.  Essentially it would contain information about what
users/groups were allowed to mount what sources to what destinations
and with what mandatory options.

You can get the start of this with the user/users/etc. stuff in
/etc/fstab, but I was envisioning something a bit more dynamic with
regular expression based rules for sources and destinations.   So,
something like:

# /etc/usermounts: user mount permissions

# <fs>                        <mount point>          <type>               <opts>

# allow users to mount any file system under their home directory
*                                   $HOME                       *     
                   nosuid, nosgid
# allow users to bind over /usr/bin as long as its only in their
private namespace
*                                   /usr/bin                      
bind                    newns
# allow users to loopback mount distributed file systems to /mnt
127.0.0.1                      /mnt                           *       
                 nosuid, nosgid
# allow users to mount files over any directory they have right access to
*                                   (perm=0222)             *         
               nosuid, nosgid

Is this unnecessary?  Is this not enough?

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