Bug 173345

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.

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

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

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.

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.

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. 

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.
   

(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.

I will keep whining until the bitter end :-)

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.

(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.

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.

Oops, I see Bug #173369 for sshfs.

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

Fixed in 2.4.2.

http://sourceforge.net/project/shownotes.php?release_id=373087

Update to 2.4.2:

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

Fixes CVE-2005-3531

(In reply to comment #16)
> http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-2.4.1-3.src.rpm

This must be:

http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-2.4.2-1.src.rpm

OK looks fine, APPROVED

Build and published in devel; should soon hit fc4, too.

New Package CVS Request
=======================
Package Name: fuse
New Branches: EL-4 EL-5

Oops! Copypasted wrong first line.

Package Change Request
=======================
Package Name: fuse
New Branches: EL-4 EL-5

New co-maintainer

Package Change Request
=======================
Package Name: fuse
New Branches: EL-4 EL-5
Updated Fedora Owners: lemenkov,tcallawa
Updated EPEL Owners: lemenkov,tcallawa

added