[RFC] ext2 and ext3 block reservations can be bypassed

[RFC] ext2 and ext3 block reservations can be bypassed

[Kasper Dupont]

Usually the last 5% of the diskspace on ext2 and ext3
filesystems are reserved for root. But I just realized
that they can be bypassed by redirecting the output
from a suid root program to a file.

This command will keep writing beyond the 95% limit:
while true ; do mount ; done >filename

This was tested on a 2.4.19-pre8-ac1 kernel. Does
this problem exist on all other kernels as well, and
how severe is this problem?

It might be better to only allow write() if the user
was also allowed to do that when open() was called.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

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

[Jakob Østergaard]

On Sun, May 12, 2002 at 06:23:21PM +0200, Kasper Dupont wrote:
> Usually the last 5% of the diskspace on ext2 and ext3
> filesystems are reserved for root. But I just realized
> that they can be bypassed by redirecting the output
> from a suid root program to a file.
> 
> This command will keep writing beyond the 95% limit:
> while true ; do mount ; done >filename

Hej Kasper,

Sure you were not running the shell as root ?  :)

The redirection is handled by your shell, mount doesn't have anything to do
with the '>filename' part.

Actually, the more fun test is to
  mount > /etc/passwd
or
  mount > /dev/hda

But this won't work either, unless your shell (and therefore you as a user,
suid programs or not) have the permissions as required.

In short: I don't think you are seeing what you think you are seeing  ;)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

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

[Elladan]

His test was different.

He opened a file in a legal situation (shell can create a new file), and
then forked off a suid process over and over with the stdout of that
process set to a dup of the shell's already open fd.

It's perfectly legal for the shell to sit around with a file open and
pass it off to a child, even if the disk is full.

It's also perfectly legal for root to write to the fd, even if the disk
is full (for normal users).  

It just happens that the suid program wasn't the one who chose what file
it was going to write stdout to - the shell did.

Thus, the security violation.


mount > /etc/passwd doesn't work, because the shell can't open
/etc/passwd for writing.

-J


On Sun, May 12, 2002 at 06:42:04PM +0200, Jakob ?stergaard wrote:
> On Sun, May 12, 2002 at 06:23:21PM +0200, Kasper Dupont wrote:
> > Usually the last 5% of the diskspace on ext2 and ext3
> > filesystems are reserved for root. But I just realized
> > that they can be bypassed by redirecting the output
> > from a suid root program to a file.
> > 
> > This command will keep writing beyond the 95% limit:
> > while true ; do mount ; done >filename
> 
> Hej Kasper,
> 
> Sure you were not running the shell as root ?  :)
> 
> The redirection is handled by your shell, mount doesn't have anything to do
> with the '>filename' part.
> 
> Actually, the more fun test is to
>   mount > /etc/passwd
> or
>   mount > /dev/hda
> 
> But this won't work either, unless your shell (and therefore you as a user,
> suid programs or not) have the permissions as required.
> 
> In short: I don't think you are seeing what you think you are seeing  ;)
> 
> -- 
> ................................................................
> :   jakob@unthought.net   : And I see the elder races,         :
> :.........................: putrid forms of man                :
> :   Jakob ?stergaard      : See him rise and claim the earth,  :
> :        OZ9ABN           : his downfall is at hand.           :
> :.........................:............{Konkhra}...............:
> -
> 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/

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

[Alexander Viro]

On Sun, 12 May 2002, Elladan wrote:

> His test was different.
> 
> He opened a file in a legal situation (shell can create a new file), and
> then forked off a suid process over and over with the stdout of that
> process set to a dup of the shell's already open fd.
> 
> It's perfectly legal for the shell to sit around with a file open and
> pass it off to a child, even if the disk is full.
> 
> It's also perfectly legal for root to write to the fd, even if the disk
> is full (for normal users).  
> 
> It just happens that the suid program wasn't the one who chose what file
> it was going to write stdout to - the shell did.
> 
> Thus, the security violation.

	<shrug> relying on 5% in security-sensitive setup is *dumb*.
In that case you need properly set quota (better yet, no lusers with write
access anywhere on that fs)..

	There are worse holes problems 5% rule.  E.g. you can create a
file with hole, mmap over that hole, dirty the pages and exit.  Guess
who ends up writing them out?  Right, kswapd.  Which is run as root.
No suid applications required...

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

[Elladan]

On Sun, May 12, 2002 at 02:15:12PM -0400, Alexander Viro wrote:
> 
> On Sun, 12 May 2002, Elladan wrote:
> > 
> > It just happens that the suid program wasn't the one who chose what file
> > it was going to write stdout to - the shell did.
> > 
> > Thus, the security violation.
> 
> 	<shrug> relying on 5% in security-sensitive setup is *dumb*.
> In that case you need properly set quota (better yet, no lusers with write
> access anywhere on that fs)..
> 
> 	There are worse holes problems 5% rule.  E.g. you can create a
> file with hole, mmap over that hole, dirty the pages and exit.  Guess
> who ends up writing them out?  Right, kswapd.  Which is run as root.
> No suid applications required...

Regardless of whether it's a good thing to depend on security-wise, it
is a problem to have something that appears to be a security feature
which doesn't actually work.

Reading the documentation, I would expect that if I create an ext3
filesystem, reserve 20% of it for root, and then run a cron job as root
that uses 16% of that filesystem periodically, that cron job will not
actually fail whenever some luser decides they want it to.

I don't recall seeing it plastered in huge letters, "This space reserve
is just a convenience feature, and can easily be circumvented by the
user.  You must never rely on it for anything."

Having unsupported security features is typically a bad idea.

-J

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

[Jakob Østergaard]

On Sun, May 12, 2002 at 11:37:30AM -0700, Elladan wrote:
...
Ok, thanks for the explanation earlier in the thread. I was mistaken.

> 
> Regardless of whether it's a good thing to depend on security-wise, it
> is a problem to have something that appears to be a security feature
> which doesn't actually work.
...
> Having unsupported security features is typically a bad idea.

I guess the point is that it is not a security feature.

The 5% default is good for ext2, since the filesystem will get heavily
fragmented if you fill it up more than ~95%.  So it is a convenience
feature.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

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

[Mark Mielke]

On Sun, May 12, 2002 at 09:02:02PM +0200, Jakob Østergaard wrote:
> On Sun, May 12, 2002 at 11:37:30AM -0700, Elladan wrote:
> > Having unsupported security features is typically a bad idea.
> I guess the point is that it is not a security feature.
> The 5% default is good for ext2, since the filesystem will get heavily
> fragmented if you fill it up more than ~95%.  So it is a convenience
> feature.

I would place it as 'system crash avoidance' rather than 'convenience'
or 'security'.

If somebody purposefully tries to circumvent the 'system crash avoidance'
feature, well... they could just as easily have said "while (1) fork;"
and accomplished something similar.

mark

-- 
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/

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

[Peter Chubb]

>>>>> "elladan" == elladan  <elladan@eskimo.com> writes:


elladan> It's perfectly legal for the shell to sit around with a file
elladan> open and pass it off to a child, even if the disk is full.

elladan> It's also perfectly legal for root to write to the fd, even
elladan> if the disk is full (for normal users).

elladan> It just happens that the suid program wasn't the one who
elladan> chose what file it was going to write stdout to - the shell
elladan> did.

This is why in SVr4, struct cred is cloned at open time, and passed
down to each VFS operation.

There's a choice of security modules here--- should the credentials
of the opener or the credentials of the writer determine the use of
the extra space?  I think in this case it ought to be the credentials
of the opener.  Also, I'm not sure that mount(8) should be a setuid
program. (I know it's convenient for floppy mounts, but I'd rather
they were handled by autofs)

Peter C

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

[Alexander Viro]

On Mon, 13 May 2002, Peter Chubb wrote:

> This is why in SVr4, struct cred is cloned at open time, and passed
> down to each VFS operation.

That doesn't work for shared mappings over holes.  Unfortunately.
Yes, credentials cache a-la 4.4BSD would help in many cases, but
we have no reasonably credentials when kswapd writes a dirty page
on disk.  It _can_ cause allocations.  And many processes might've
touched that page until it finally got written out - which credentials
would you use?

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

[Kasper Dupont]

Alexander Viro wrote:
> 
> On Mon, 13 May 2002, Peter Chubb wrote:
> 
> > This is why in SVr4, struct cred is cloned at open time, and passed
> > down to each VFS operation.
> 
> That doesn't work for shared mappings over holes.  Unfortunately.
> Yes, credentials cache a-la 4.4BSD would help in many cases, but
> we have no reasonably credentials when kswapd writes a dirty page
> on disk.  It _can_ cause allocations.  And many processes might've
> touched that page until it finally got written out - which credentials
> would you use?

I'd rather have the check done when the page gets dirty in the
first place. Refuse the CoW if there is not diskspace to write
it back. Right now we can go beyond the diskspace we are allowed
to use and we will silently loose data if we go beyond the
available diskspace.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

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

[Elladan]

On Mon, May 13, 2002 at 06:22:42AM +0200, Kasper Dupont wrote:
> Alexander Viro wrote:
> > 
> > On Mon, 13 May 2002, Peter Chubb wrote:
> > 
> > > This is why in SVr4, struct cred is cloned at open time, and passed
> > > down to each VFS operation.
> > 
> > That doesn't work for shared mappings over holes.  Unfortunately.
> > Yes, credentials cache a-la 4.4BSD would help in many cases, but
> > we have no reasonably credentials when kswapd writes a dirty page
> > on disk.  It _can_ cause allocations.  And many processes might've
> > touched that page until it finally got written out - which credentials
> > would you use?
> 
> I'd rather have the check done when the page gets dirty in the
> first place. Refuse the CoW if there is not diskspace to write
> it back. Right now we can go beyond the diskspace we are allowed
> to use and we will silently loose data if we go beyond the
> available diskspace.

So, the way this would work (presumably) is that space gets reserved on
the filesystem as soon as the page goes dirty, if space is not presently
allocated for that page.  The process would receive a SIGBUS if they
attempt to write to the page, but backing store reservation failed, as
they do when, eg., there's an IO error on a page or some such.

If the mapping was held by more than one process, and one had permission
to dirty the page and the other did not, then whose credentials should
get used would just be a matter of which one writes first.  If the disk
is full for users and root dirties the page first, then the user can
re-dirty it.  If the user dirties it first, then the user receives
SIGBUS.  If the disk is full for everyone, then either one would receive
the signal.

-J

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

[Horst von Brand]

Elladan <elladan@eskimo.com> said:

[...]

> Regardless of whether it's a good thing to depend on security-wise, it
> is a problem to have something that appears to be a security feature
> which doesn't actually work.

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.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

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

[Elladan]

On Mon, May 13, 2002 at 01:09:15PM -0400, Horst von Brand wrote:
> Elladan <elladan@eskimo.com> said:
> 
> [...]
> 
> > Regardless of whether it's a good thing to depend on security-wise, it
> > is a problem to have something that appears to be a security feature
> > which doesn't actually work.
> 
> 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.
This is probably best considered a documentation issue.  Instead of
saying it's "reserved for root" etc., tools should indicate it's
"reserved to prevent fragmentation, still accessible by root"

At least one document I recall seeing indicates that this reserve is so
system software (eg. cron jobs) won't fail, and so root will still be
able to log in when the disk is full.  This interpretation makes it
sound like a security feature - if it isn't meant as one, some effort
should be made to ensure there's no confusion, or else someone might
depend on the behavior.

-J

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

[Christoph Hellwig]

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.

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

[Kasper Dupont]

Horst von Brand wrote:
> 
> Elladan <elladan@eskimo.com> said:
> 
> [...]
> 
> > Regardless of whether it's a good thing to depend on security-wise, it
> > is a problem to have something that appears to be a security feature
> > which doesn't actually work.
> 
> 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.

My point was that anybody can use this space if they want to.

While this feature might not be intended to be used for
security purposes, the documentation says the space is
reserved for the super-user. And in many cases it would be
convenient to use the feature for that purpose.

Since this would be a usefull feature for many people, and
since it AFAIK cannot be acomplished with quotas, I suggest
we find a way to make it work like most people would expect.

Would it cause any problems if the kernel ensured that the
block reservations could not be bypassed by users?

I have not yet verified if the same problem exists when
using quotas. (My kernel is compiled without quotas). But
if it does I guess we all would like to have it fixed.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

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

[Mark Mielke]

1) You can always submit a patch, and see whether other people approve of it.

2) If you won't do it, why would somebody else working on something that
   provides lower latency to user process response time, or improvement
   to the IDE drivers, take the time to deal with this issue?

You need to either do 1), or convince somebody to do 2).

As it is, there are plenty of other denial-of-service type attacks
that can be performed that would be more effective than the 'exploit'
you have mentioned. Your proposal would need to be 'fix them all', if
your complaint is that Linux has a security hole.

If you complaint is that an administrator might mistakenly believe
that it is a security feature, I suggest your understand that this is
merely one issue of quite a few. If the administrator is not aware of
issues such as these, perhaps they should not be an administrator?

mark


On Tue, May 14, 2002 at 05:40:58PM +0200, Kasper Dupont wrote:
> Horst von Brand wrote:
> > 
> > Elladan <elladan@eskimo.com> said:
> > 
> > [...]
> > 
> > > Regardless of whether it's a good thing to depend on security-wise, it
> > > is a problem to have something that appears to be a security feature
> > > which doesn't actually work.
> > 
> > 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.
> 
> My point was that anybody can use this space if they want to.
> 
> While this feature might not be intended to be used for
> security purposes, the documentation says the space is
> reserved for the super-user. And in many cases it would be
> convenient to use the feature for that purpose.
> 
> Since this would be a usefull feature for many people, and
> since it AFAIK cannot be acomplished with quotas, I suggest
> we find a way to make it work like most people would expect.
> 
> Would it cause any problems if the kernel ensured that the
> block reservations could not be bypassed by users?
> 
> I have not yet verified if the same problem exists when
> using quotas. (My kernel is compiled without quotas). But
> if it does I guess we all would like to have it fixed.
> 
> -- 
> Kasper Dupont -- der bruger for meget tid på usenet.
> For sending spam use mailto:razor-report@daimi.au.dk
> -
> 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/

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

[Elladan]

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/

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

[Mark Mielke]

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/

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

[Elladan]

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/

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

[Jesse Pollard]

Elladan <elladan@eskimo.com>:
> 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."
> 

If the root file system is ext2, it does become a security issue since
currently active logs will continue to record log entries until the
filesystem is absolutly filled. I should say, if the log device fills up,
since the log directory is usually /var/log, or /var/adm. Some logs show
up in etc, but that really depends on the configuration. It IS usefull if the
filesystem is "full" due to attacks - daemons tend to terminate themselves,
and their log entry indicates what the problem was. If it is an attack, then
it's a security issue.

The only reason it helps fragmentation (subject to actual implementor
statements) is that the filesystem code will use every scavanged block
possible under saturation. When the filesystem gets cleand up later,
these excessively fragmented files will remain, and continue to cause
access delays.

Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation.

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

True, but this is a side effect caused by stopping user allocations.
 
> 3. Note what mke2fs prints:
> 
> 3275 blocks (5.00%) reserved for the super user
> 
> It does not say "reserved to combat fragmentation"
> 

It shouldn't have to. This is a tuneable value, and can be set to 0.
(tune2fs).

The "super user" is also an option. It defaults to the user "root", but
can be specified to be a user OR a group by tune2fs (-g option for group,
-u option for user).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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

[Jesse Pollard]

Mark Mielke <mark@mark.mielke.cc>:
> 
> 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.

Actually, any existing daemon (read "syslog") can use this space. This is
partly why it is a "security feature" so that the logs can still get to disk
even if the filesystem is "full".

> 1) Provide a patch and see if it is accepted.

Patch not necessary - it is a tuneable feature. All that is missing is
an understanding of what the reservation is/can be used for.

> 2) Convince somebody else that they should put time into features of
>    questionable value such as this one.

Already done - see "man tune2fs".

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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

[Jesse Pollard]

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

Actually, the allocation that fills the partition (and goes one over)
should fail. Even if that is only adding a block to the hole, it should
fail. Now if it DOES continue then you have found a bug since it
shouldn't do that.

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

There is nothing wrong with the documentation. Though it could have
additions to more clearly explain why. The feature can already be disabled.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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

[Mark Mielke]

Don't put /var/log on the same file system as /home, and don't grant
access to /var/log to any normal userid.

This isn't 'new'.

mark


On Tue, May 14, 2002 at 12:53:47PM -0500, Jesse Pollard wrote:
> If the root file system is ext2, it does become a security issue since
> currently active logs will continue to record log entries until the
> filesystem is absolutly filled. I should say, if the log device fills up,
> since the log directory is usually /var/log, or /var/adm. Some logs show
> up in etc, but that really depends on the configuration. It IS usefull if the
> filesystem is "full" due to attacks - daemons tend to terminate themselves,
> and their log entry indicates what the problem was. If it is an attack, then
> it's a security issue.
> 
> The only reason it helps fragmentation (subject to actual implementor
> statements) is that the filesystem code will use every scavanged block
> possible under saturation. When the filesystem gets cleand up later,
> these excessively fragmented files will remain, and continue to cause
> access delays.
> 
> Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation.
> 

-- 
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/

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

[Kasper Dupont]

Mark Mielke wrote:
> 
> 1) You can always submit a patch, and see whether other people approve of it.

I might decide to do that. But I wouldn't spend the time
without first knowing if:
a) There were some very good reasons not to change it.
b) Somebody knowing this code by heart could write a
   patch in five minutes.

> 
> 2) If you won't do it, why would somebody else working on something that
>    provides lower latency to user process response time, or improvement
>    to the IDE drivers, take the time to deal with this issue?

I don't intend to try to force somebody to do it, if
they have more important things to do.

> 
> As it is, there are plenty of other denial-of-service type attacks
> that can be performed that would be more effective than the 'exploit'
> you have mentioned. Your proposal would need to be 'fix them all', if
> your complaint is that Linux has a security hole.

It surely would be nice to prevent all DoS attacks. But
of course that would require a lot of work. However I
think most other DoS attacks could be solved by a reboot.

> 
> If you complaint is that an administrator might mistakenly believe
> that it is a security feature, I suggest your understand that this is
> merely one issue of quite a few. If the administrator is not aware of
> issues such as these, perhaps they should not be an administrator?

We cannot blame administrators before the documentation
has been changed.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

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

[Kasper Dupont]

Elladan wrote:
> 
> it's ext[23] only and not really very useful.

I actually find it very useful, but I cannot argue against the
fact that it is an ext[23] specific feature.

I might like to implement a similar feature in a filesystem
independend way.

The documentation about quotas says it is also ext2 specific.
Is that still true? And has anybody BTW verified that the
quota system doesn't suffer from the same problems?

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-report@daimi.au.dk

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

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> Don't put /var/log on the same file system as /home, and don't grant
> access to /var/log to any normal userid.
> 
> This isn't 'new'.

Also not relevent. If you want to get picky, don't put root, /usr, /var
and /etc on the same filesystem. Make them all separate. Don't put
/tmp, /var/tmp, on the same filesystem either. Mount /usr read only.
mount / read only, mount all user writable filesystems nosetuid, nosetgid.

However, not all daemons run as root, but do log into /var/adm or /var/log.
If these fill up the log device without restraint, then your audit logs will
ALSO be affected (unless you have syslog send them to a different host).

Users don't have to have access to the filesystem to cause write activity
to it. The reserved space is just a small thing. It can't catch everything,
but the system CAN continue to function after the filesystem fills up.
Hopefully, long enough to record events and allow the administrator to
clean up. That is the ONLY security function it has.

> mark
> 
> 
> On Tue, May 14, 2002 at 12:53:47PM -0500, Jesse Pollard wrote:
> > If the root file system is ext2, it does become a security issue since
> > currently active logs will continue to record log entries until the
> > filesystem is absolutly filled. I should say, if the log device fills up,
> > since the log directory is usually /var/log, or /var/adm. Some logs show
> > up in etc, but that really depends on the configuration. It IS usefull if the
> > filesystem is "full" due to attacks - daemons tend to terminate themselves,
> > and their log entry indicates what the problem was. If it is an attack, then
> > it's a security issue.
> > 
> > The only reason it helps fragmentation (subject to actual implementor
> > statements) is that the filesystem code will use every scavanged block
> > possible under saturation. When the filesystem gets cleand up later,
> > these excessively fragmented files will remain, and continue to cause
> > access delays.
> > 
> > Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation.
> > 

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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

[Alexander Viro]

On Tue, 14 May 2002, Jesse Pollard wrote:
 
> However, not all daemons run as root, but do log into /var/adm or /var/log.
> If these fill up the log device without restraint, then your audit logs will
> ALSO be affected (unless you have syslog send them to a different host).

syslogd _does_ run as root and it can happily overflow the damn thing,
reserved blocks or not.

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

[Alexander Viro]

On Tue, 14 May 2002, Jesse Pollard wrote:

> If the root file system is ext2, it does become a security issue since
> currently active logs will continue to record log entries until the

You are kidding.  First of all, what kind of idiot has /var on root?  What
next - /var/spool/mail on the same filesystem, so that mailbombing root
(or just a mail loop) could screw you over?

What's more, if you can't deal with overflowing /var/log, you are screwed -
making syslogd to write something in log is _not_ hard.

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

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> 
> 
> On Tue, 14 May 2002, Jesse Pollard wrote:
>  
> > However, not all daemons run as root, but do log into /var/adm or /var/log.
> > If these fill up the log device without restraint, then your audit logs will
> > ALSO be affected (unless you have syslog send them to a different host).
> 
> syslogd _does_ run as root and it can happily overflow the damn thing,
> reserved blocks or not.
> 

Absolutely - and it should, since that IS the primary audit log daemon.

I don't consider that a "bug". Only if a "user" process (non-root, or
non-designated user) can exceed the set bounds, by either appending, or
filling in a hole, should there be a bug in the system.

Personally, I think ext2 works great. (And I DON'T count the time experimental
code with the warning "caution, may be hazardous to your filesystem" as
causing problems - I had expected it to.)

I've never had a problem with ext2, even when I did fill the filesystem.
I was able to log in and view the audit log, and clean up without
problems - exactly as I would expect.

It has been the most stable file system I've ever used (and I've used
quite a few - old Files-11 and Files-32, RT11, dos, UFS, UNICOS nc1, SGI
efs and xfs ...)

Easier fsck procedure than all of them. Fixed any inconsistancies as well
and didn't loose any resident files.

I've only lost one ext2fs - and that was due to a head crash. The drive
had been running for a couple of years continuously, with only a few
mis-guided reboots.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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

[Mark Mielke]

I.e. a fix to ext2/ext3 is not horribly useful.

mark


On Tue, May 14, 2002 at 01:54:40PM -0500, Jesse Pollard wrote:
> ---------  Received message begins Here  ---------
> 
> > 
> > Don't put /var/log on the same file system as /home, and don't grant
> > access to /var/log to any normal userid.
> > 
> > This isn't 'new'.
> 
> Also not relevent. If you want to get picky, don't put root, /usr, /var
> and /etc on the same filesystem. Make them all separate. Don't put
> /tmp, /var/tmp, on the same filesystem either. Mount /usr read only.
> mount / read only, mount all user writable filesystems nosetuid, nosetgid.
> 
> However, not all daemons run as root, but do log into /var/adm or /var/log.
> If these fill up the log device without restraint, then your audit logs will
> ALSO be affected (unless you have syslog send them to a different host).
> 
> Users don't have to have access to the filesystem to cause write activity
> to it. The reserved space is just a small thing. It can't catch everything,
> but the system CAN continue to function after the filesystem fills up.
> Hopefully, long enough to record events and allow the administrator to
> clean up. That is the ONLY security function it has.
> 
> > mark
> > 
> > 
> > On Tue, May 14, 2002 at 12:53:47PM -0500, Jesse Pollard wrote:
> > > If the root file system is ext2, it does become a security issue since
> > > currently active logs will continue to record log entries until the
> > > filesystem is absolutly filled. I should say, if the log device fills up,
> > > since the log directory is usually /var/log, or /var/adm. Some logs show
> > > up in etc, but that really depends on the configuration. It IS usefull if the
> > > filesystem is "full" due to attacks - daemons tend to terminate themselves,
> > > and their log entry indicates what the problem was. If it is an attack, then
> > > it's a security issue.
> > > 
> > > The only reason it helps fragmentation (subject to actual implementor
> > > statements) is that the filesystem code will use every scavanged block
> > > possible under saturation. When the filesystem gets cleand up later,
> > > these excessively fragmented files will remain, and continue to cause
> > > access delays.
> > > 
> > > Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation.
> > > 
> 
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
> 
> Any opinions expressed are solely my own.

-- 
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/

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

[Pavel Machek]

Hi!

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

I'd suggest you to mail to bugtraq@securityfocus.com; it sounds like
security hole to me, and probably common across many unix variants.

									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

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

[Alan Cox]

> > If this is not a security feature, Documentation/filesystems/ext2.txt
> > needs to be changed.  Eg., 
> 
> I'd suggest you to mail to bugtraq@securityfocus.com; it sounds like
> security hole to me, and probably common across many unix variants.

The original Unix documentation for FFS refers to it only as a performance
oriented reason.

Alan