Bug 173345 - Review Request: fuse
Review Request: fuse
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
David Lawrence
http://sourceforge.net/projects/fuse
:
Depends On:
Blocks: FE-ACCEPT 173341 173369
  Show dependency treegraph
 
Reported: 2005-11-16 09:52 EST by Richard Dawe
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-26 08:54:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
petersen: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Richard Dawe 2005-11-16 09:52:52 EST
Spec Name or Url: http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/fuse.spec
SRPM Name or Url: http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/fuse-2.4.1-1.src.rpm
Description:

From the FUSE README:

"FUSE (Filesystem in Userspace) is a simple interface for userspace programs to export a virtual filesystem to the linux kernel.  FUSE also aims to provide a secure method for non privileged users to create and mount their own filesystem implementations."

FUSE was incorporated and ships in kernel-2.6.14-1.1637_FC4. But to be able to write userspace filesystems, you need the userspace libraries and utilities. I've packaged them up according to the Extras guidelines. Please review them.

Note that there are currently some rpmlint failures (see below). I don't think these are errors. I opened bug #173341 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173341> about the udev rules; I think they belong in the udev package in the future.

[rich@katrina FC4]$ rpmlint i386/fuse-2.4.1-1.i386.rpm
W: fuse non-conffile-in-etc /etc/udev/rules.d/40-fuse.rules
E: fuse setuid-binary /usr/bin/fusermount root 04755
E: fuse non-standard-executable-perm /usr/bin/fusermount 04755
[rich@katrina FC4]$ rpmlint i386/fuse-devel-2.4.1-1.i386.rpm
[rich@katrina FC4]$ rpmlint fuse-2.4.1-1.src.rpm

Please let me know if you'd like some detailed instructions on how to get a userspace filesystem up and running with FUSE.

Also, thanks for reviewing in advance!
Comment 1 Thorsten Leemhuis 2005-11-16 11:58:27 EST
Okay, we have a problem now. I also prepared fuse packages and we discussed
those on fedora-extras and fedora-maintainers list already. See those threads:

https://www.redhat.com/archives/fedora-extras-list/2005-October/msg01506.html
https://www.redhat.com/archives/fedora-extras-list/2005-November/msg00120.html

I also planed to open a review today -- I don't think opening another bug is
helpful, so here are my packages:

http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/fuse.spec
http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-2.4.1-3.src.rpm

They have the following benefits over yours afaics: 
- Splits utils and lib
- Uses a fuse group to restrict access
- Only allows members of the fuse group to write to /dev/fuse
- maybe other, did not look closely

BTW, these are wrong in your package:
>BuildRequires: autoconf
>BuildRequires: automake
>BuildRequires: libtool

So, how to proceed? Richard, if it's okay for you I'd suggest we go with those
packages that were discussed already. But if you want to maintain fuse in
extras-FC4 it's okay for me. Note that fuse might be included in Core soon.

Richard, btw, do you have a sshfs package? I would submit
http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-sshfs-1.2-2.src.rpm
for review if you don't have a similar/better package.
Comment 2 Richard Dawe 2005-11-16 12:15:55 EST
Hi Thorsten.

It looks like you've already done a lot of work on this. I agree - we should go
with what's been discussed already. I'll try to review the packages at the
weekend - if I don't, please proceed anyway.

This is my own fault. I should have checked fedora-extras-list!

Thanks, bye, Rich
Comment 3 Miklos Szeredi 2005-11-16 14:37:07 EST
Hi Thorsten,

Thanks for packaging FUSE.

About security:  FUSE has been designed in a way, that even malicious users
can't cause problems.  This is modulo any unknown bugs of course.  To date there
has been only one security bug found (an information leak) and fixed in 2.3.0
that could be exploited by a  hostile user.

So restricting mounting to a subset of users IMO just makes administration
harder.  So at least it should be documented that it's an option for the
sysadmin to change the mode of /usr/bin/fusermount to 4755 instead of having to
individually add users to the fuse group.

Thanks,
Miklos
Comment 4 Warren Togami 2005-11-16 23:26:48 EST
Packaging /usr/bin/fusermount as 0755 and expecting the sysadmin to set it to
4755 in order to use it is not a good option, because upon package update it
will change the permission back to the default.  Red Hat engineering is now
assessing our options about what exactly to do with FUSE userspace tools and
exactly how we will ship it by default.  It will probably be a week or two
before we come to any conclusions because we are currently busy trying to get
FC5test1 out the door.  In the mean time if you have any further information
about the security risks of this, including any proof of code audits or design
details of the system please submit links here for our analysis.
Comment 5 Linus Walleij 2005-11-17 04:41:01 EST
The discussion here already start to resemble what we already had on the
Fedora Extras list. The points raised was these:

1. Some people expressed disbelief in the FUSE security system, and
   wanted to restrict its use to things listed in /etc/fstab. A 
   special concern raised was that sshfs would be able to mount most
   anything.

2. Protest from me (perhaps some others too) that this was not good,
   and actually, just mounting things listed in /etc/fstab is not
   what FUSE is intended for. (See package description above!)

IMHO the most reasonable thing is to package FUSE suid root as the 
developers intended it, and the developers claim this is secure.
If sysadmins don't like the goals of the FUSE project or do not
believe it is secure though it's claimed to be, they should not 
install the FUSE packages at all.

With respect to the worry of sshfs mounting just anything, the
way suid-mounting something using sshfs+FUSE would be different 
from using GNOME VFS on top of common ssh evades me totally. 
Just that the kernel is involved and something is run suid root 
doesn't change the basic concept, its just a matter of whether
kernel VFS or GNOME VFS is involved in the operation, the result
is the same: user mounts whatever user wants and that's cool.

FUSE provides infrastructure for a lot of nice userland things
and sshfs will presumably not be the most interesting thing
that can be done with it, so I discourage this narrow focus on
one single application. I have been waiting for FUSE so that
I can then package EncFS, a use case that would be destroyed or
hampered beyond repair by crippling fusermount like this.

Sorry if stressing my opinion this hard hurts anyones feelings.
I'm no sysadmin so please enlighten us to where exactly the
problems with FUSE+sshfs are, I don't get it, could be out of
my ignorace or misinformedness.
Comment 6 Thorsten Leemhuis 2005-11-17 05:03:17 EST
Just FYI: OpenSuse also ships without suid root, see:
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/fuse-2.4.1-3.src.rpm

Quote:
># should be 4755, but no security review yet
>%attr(0755,root,root) %{_bindir}/fusermount

With the fuse group and suid binary, that is only executable by members of the
fuse group, we IMHO have a nice solution. Adding yourself to that group and
relogin is not that complicated, so please stop whining. 
Comment 7 Norman Gaywood 2005-11-17 06:06:40 EST
I my view the fuse group is too restrictive. I potentally want any user to mount
a USB stick in a LTSP environment. I don't want to add users to a group, I want
anyone to be able to do this. I have over 20,000 usernames in an LDAP server.

I want to trust to security of the fuse userland tools. If there is a problem
there then the tools must be fixed.
   
Comment 8 Thorsten Leemhuis 2005-11-17 06:20:20 EST
(In reply to comment #7)
> I my view the fuse group is too restrictive.

Several other people say: Shipping programms suid root is a security risk -- we
have seen that in the past with several programms and therefor avoid suid root
as much as possible. 

I agree with that opinion. But fuse simply does not work without suid root
(note: smbfs, cifs, ncpfs and several other do). So the fuse group is a compromise.

> I potentally want any user to mount
> a USB stick in a LTSP environment.

Interesting environment where users have direct access to physical devices. And
mounting a USB-Stick works for me on recent Fedora versions without fuse. But
that is a diffenrent story. So back on topic:

> I don't want to add users to a group, I want
> anyone to be able to do this.[...] 
> I want to trust to security of the fuse userland tools.

Then do a chmod 0755 /usr/bin/fusemount. You are free to do that, I won't complain.
Comment 9 Linus Walleij 2005-11-17 07:11:43 EST
I will keep whining until the bitter end :-)
Comment 10 Albert Strasheim 2005-11-17 10:05:19 EST
Where the USB stick idea becomes useful is when you combine a USB stick with
EncFS. This is a good way for carrying around sensitive documents and the like.
Comment 11 Miklos Szeredi 2005-11-17 10:44:30 EST
(In reply to comment #4)
> Packaging /usr/bin/fusermount as 0755 and expecting the sysadmin to set it to
> 4755 in order to use it is not a good option, because upon package update it
> will change the permission back to the default.

An alternative is to restrict access to /dev/fuse and install
/usr/bin/fusermount with 4755.

> In the mean time if you have any further information
> about the security risks of this, including any proof of code audits or design
> details of the system please submit links here for our analysis.

No security audit has been done on any part of FUSE.  Prior to inclusion into
Linux, the kernel part was reviewed by a couple of people, but without special
attention to security.

The above alternative would "only" require an audit of fusermount, but of course
a full audit (kernel module + fusermount) would be nice.

The long term goal is to make mount() syscall unprivileged (with policy
controllable via sysctl and ulimit), and so remove the requirement for a suid
mount helper.  The earliest this could happen is 2.6.16.
Comment 12 Warren Togami 2005-11-21 21:04:47 EST
I APPROVE of Thorsten's fuse package.  We need to give this technology a chance
in Extras to see how it goes.

Thorsten perhaps submit sshfs to another bug for review and approval?
Has anyone packaged encfs too?  That sounds interesting.
Comment 13 Warren Togami 2005-11-21 21:13:06 EST
Oops, I see Bug #173369 for sshfs.
Comment 14 Warren Togami 2005-11-22 15:18:42 EST
Unapprove until this public security issue is verified to be fixed in our package.

http://marc.theaimsgroup.com/?l=full-disclosure&m=113267802021371&w=2
Comment 15 Ignacio Vazquez-Abrams 2005-11-23 07:24:50 EST
Fixed in 2.4.2.

http://sourceforge.net/project/shownotes.php?release_id=373087
Comment 18 Warren Togami 2005-11-23 14:14:37 EST
OK looks fine, APPROVED
Comment 19 Thorsten Leemhuis 2005-11-26 08:54:24 EST
Build and published in devel; should soon hit fc4, too.
Comment 20 Peter Lemenkov 2007-07-22 02:22:51 EDT
New Package CVS Request
=======================
Package Name: fuse
New Branches: EL-4 EL-5
Comment 21 Peter Lemenkov 2007-07-22 02:24:27 EDT
Oops! Copypasted wrong first line.

Package Change Request
=======================
Package Name: fuse
New Branches: EL-4 EL-5
Comment 22 Peter Lemenkov 2007-07-24 05:05:17 EDT
New co-maintainer

Package Change Request
=======================
Package Name: fuse
New Branches: EL-4 EL-5
Updated Fedora Owners: lemenkov@gmail.com,tcallawa@redhat.com
Updated EPEL Owners: lemenkov@gmail.com,tcallawa@redhat.com
Comment 23 Jens Petersen 2007-07-24 10:14:51 EDT
added

Note You need to log in before you can comment on or make changes to this bug.