Re: [RFC] ext2 and ext3 block reservations can be bypassed

[Elladan <elladan@eskimo.com>]

A second method was proposed as well - create a file with a hole in it,
map it, then dirty the pages in the hole and exit.  This would not
require suid.

This is basically a documentation issue, unless someone wants to go fix
it.  I wouldn't bother myself - it's ext[23] only and not really very
useful.

The basic problem is this: the documentation states "This is intended to
allow for the system to continue functioning even if non-priveleged
users fill up all the space available to them."  This states that it's a
security feature.  It does not work as intended - all users are
privileged to do this - so the documentation should be updated.

I'll send a patch to someone later today.

-J

On Tue, May 14, 2002 at 12:55:36PM -0400, Mark Mielke wrote:
> Notice how the space can only be filled up if a setuid program is used
> to actually fill it up. Even if it is a partial 'security feature', every
> administrator knows that setuid violates security in a non-natural way.
> 
> 1) Provide a patch and see if it is accepted.
> 
> 2) Convince somebody else that they should put time into features of
>    questionable value such as this one.
> 
> mark
> 
> 
> 
> On Tue, May 14, 2002 at 09:22:54AM -0700, Elladan wrote:
> > I went to google and attempted to find information about the root
> > reserve space for ext2, as a user wondering about the feature would.  I
> > couldn't find any documentation that states it's purely a fragmentation
> > and convenience feature.  I did, however, find documents stating
> > otherwise.  Note how even Documentation/filesystems/ext2.txt states that
> > it's a security feature?
> > 
> > If this is not a security feature, Documentation/filesystems/ext2.txt
> > needs to be changed.  Eg., 
> > 
> > "In ext2, there is a mechanism for reserving a certain number of blocks
> > for a particular user (normally the super-user).  This is intended to
> > keep the filesystem from filling up entirely, which helps combat
> > fragmentation.  The super-user may still use this space.  Note that this
> > is not a security feature, and is only provided for convenience -
> > various methods exist where a user may circumvent this reservation and
> > use the space if they so wish.  Quotas or separate filesystems should be
> > used if reliable space limits are needed."
> > 
> > 
> > 
> > 1. http://web.mit.edu/tytso/www/linux/ext2intro.html
> > 
> > Design and Implementation of the Second Extended Filesystem
> > 
> > [....] Ext2fs reserves some blocks for the super user (root). Normally,
> > 5% of the blocks are reserved. This allows the administrator to recover
> > easily from situations where user processes fill up filesystems.
> > 
> > 
> > 2. Documentation/filesystems/ext2.txt
> > 
> > Reserved Space
> > --------------
> > 
> > In ext2, there is a mechanism for reserving a certain number of blocks
> > for a particular user (normally the super-user).  This is intended to
> > allow for the system to continue functioning even if non-priveleged
> > users fill up all the space available to them (this is independent of
> > filesystem quotas).  It also keeps the filesystem from filling up
> > entirely which helps combat fragmentation.
> > 
> > 
> > 3. Note what mke2fs prints:
> > 
> > 3275 blocks (5.00%) reserved for the super user
> > 
> > It does not say "reserved to combat fragmentation"
> > 
> > 
> > -J
> > 
> > 
> > On Mon, May 13, 2002 at 06:57:23PM +0100, Christoph Hellwig wrote:
> > > On Mon, May 13, 2002 at 10:52:50AM -0700, Elladan wrote:
> > > > > It is _not_ a security feature, it is meant to keep the filesystem from
> > > > > fragmenting too badly. root can use that space, since root can do whatever
> > > > > she wants anyway.
> > > > 
> > > > But it *appears* to be a security feature.  Thus, someone might
> > > > incorrectly depend on it, unless it's clearly documented as otherwise.
> > > 
> > > So what.  People rely on chroot() as security feature all the time and
> > > we don't "fix" it either.  If you need security nothing but gaining
> > > knowledge about all details helps.
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -- 
> mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
> 
>   One ring to rule them all, one ring to find them, one ring to bring them all
>                        and in the darkness bind them...
> 
>                            http://mark.mielke.cc/