From 9e3147feab8e313b54388df2bda8540ff2afdd02 Mon Sep 17 00:00:00 2001 From: Nikolaus Rath Date: Thu, 12 Jan 2017 10:10:34 -0800 Subject: Rephrased security information The permission caching bug has been present forever, is presumably going to stay around for a while, and is of less concern if allow_other is not used. Since allow_other is disabled by default, I think we can safely make this warning less prominent and document the problem when we describe allow_other. Also, drop the travis build status. It's confusing when reading README.md after extracting the tarball, and I am not sure who benefits from the build status when it is shown on GitHub either. --- README.md | 58 +++++++++++++++++++++++++++++----------------------------- 1 file changed, 29 insertions(+), 29 deletions(-) (limited to 'README.md') diff --git a/README.md b/README.md index 39e57bf..8201eeb 100644 --- a/README.md +++ b/README.md @@ -1,29 +1,6 @@ libfuse ======= -[![Build Status](https://travis-ci.org/libfuse/libfuse.svg?branch=master)](https://travis-ci.org/libfuse/libfuse) - -Warning: unresolved security issue ----------------------------------- - -Be aware that FUSE has an unresolved security bug -([bug #15](https://github.com/libfuse/libfuse/issues/15)): if the -`default_permissions` mount option is not used, the results of the -first permission check performed by the file system for a directory -entry will be re-used for subsequent accesses as long as the inode of -the accessed entry is present in the kernel cache - even if the -permissions have since changed, and even if the subsequent access is -made by a different user. - -This bug needs to be fixed in the Linux kernel and has been known -since 2006 but unfortunately no fix has been applied yet. If you -depend on correct permission handling for FUSE file systems, the only -workaround is to use `default_permissions` (which does not currently -support ACLs), or to completely disable caching of directory entry -attributes. Alternatively, the severity of the bug can be somewhat -reduced by not using the `allow_other` mount option. - - About ----- @@ -79,19 +56,42 @@ If you run `make install`, the *fusermount3* program is installed set-user-id to root. This is done to allow normal users to mount their own filesystem implementations. -There must however be some limitations, in order to prevent Bad User from -doing nasty things. Currently those limitations are: +To limit the harm that malicious users can do this way, *fusermount3* +enforces the following limitations: - - The user can only mount on a mountpoint, for which it has write + - The user can only mount on a mountpoint for which he has write permission - - The mountpoint is not a sticky directory which isn't owned by the - user (like /tmp usually is) + - The mountpoint must not be 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 (though this can be relaxed by allowing the use - of the `allow_other` and `allow_root` mount options in `fuse.conf`) + of the *allow_other* and *allow_root* mount options in + */etc/fuse.conf*) + + +If you intend to use the *allow_other* mount options, be aware that +FUSE has an unresolved [security +bug](https://github.com/libfuse/libfuse/issues/15): if the +*default_permissions* mount option is not used, the results of the +first permission check performed by the file system for a directory +entry will be re-used for subsequent accesses as long as the inode of +the accessed entry is present in the kernel cache - even if the +permissions have since changed, and even if the subsequent access is +made by a different user. This is of little concern if the filesystem +is accessible only to the mounting user (which has full access to the +filesystem anyway), but becomes a security issue when other users are +allowed to access the filesystem (since they can exploit this to +perform operations on the filesystem that they do not actually have +permissions for). +This bug needs to be fixed in the Linux kernel and has been known +since 2006 but unfortunately no fix has been applied yet. If you +depend on correct permission handling for FUSE file systems, the only +workaround is to use `default_permissions` (which does not currently +support ACLs), or to completely disable caching of directory entry +attributes. Building your own filesystem ------------------------------ -- cgit v1.2.3