[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110305212535.GX372@outflux.net>
Date: Sat, 5 Mar 2011 13:25:36 -0800
From: Kees Cook <kees@...ntu.com>
To: Dan Rosenberg <dan.j.rosenberg@...il.com>
Cc: oss-security@...ts.openwall.com, Ludwig Nussel <ludwig.nussel@...e.de>,
security <security@...ntu.com>, security@...ian.org,
secalert@...hat.com, security@...e.de
Subject: Re: Suid mount helpers fail to anticipate RLIMIT_FSIZE
Hi Dan,
On Sat, Mar 05, 2011 at 01:57:41PM -0500, Dan Rosenberg wrote:
> This is all good to know, but what do we think is the best way to
> actually fix this specific issue for all the systems supported by
> distros that are using older versions of util-linux, or for various
> other reasons can't get rid of /etc/mtab?
>
> Fixing every suid mount helper individually seems a bit tedious, but
> there might not be a way around it.
> [...]
> There are a few possible options We could patch glibc to try to
> raise the rlimit in addmntent(). Or we could fix every suid mount
> helper to raise the rlimit or have proper error handling for the case
> when addmntent() fails. This final option requires that mtab editing
> be done in a temporary file and aborted on failure, which isn't the
> case for all helpers.
It seems like fixing glibc to either raise the rlimit or correctly handle
the error condition is the way to go (as you already mentioned). I share
the concern of the helpers maybe not checking addmntent() return codes,
though. If they all do, I would think that just correct error handling
in glibc would be accepted upstream. Whatever the fix, it really feels like
it should be in glibc. It is what is responsible for actually writing to
the file...
-Kees
--
Kees Cook
Ubuntu Security Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
