Re: some fixes to musl

[Vasiliy Kulikov <segoon@openwall.com>]

On Thu, Jul 21, 2011 at 22:08 -0400, Rich Felker wrote:
> On Thu, Jul 21, 2011 at 11:17:04PM +0400, Vasiliy Kulikov wrote:
> > On Thu, Jul 21, 2011 at 14:21 -0400, Rich Felker wrote:
> > > > fdopendir():
> > > > - POSIX defines EBADF if fd is invalid.  I suppose it is OK
> > > >   to assume fd is invalid if fstat() failed.
> > > 
> > > fstat will already set errno to EBADF if appropriate.
> > 
> > I think it's wrong.  *stat(2) calls LSM hook, which may fail and return
> > arbitrary error.  I wish there were *explicit* rules of LSMs what
> > restrictions hooks have got.  But I don't know any similar documentation
> > :(  So, I assume the theoretically worst case - any LSM hook may return
> > arbitrary error.  Yes, it might break many implicit assumptions, etc.
> 
> It should be obvious that a bogus LSM will create gaping security
> holes if it's allowed such power.

I don't say such handling is perfect, just want to show it can be
somehow justified:

Most of LSM hooks maintain some security context associated with
file/task/socket/etc.  Some actions may require (re)allocation of this
context.  If the allocation fails (e.g. OOM), it's wrong to allow the
task to continue the work with the object, which has an outdated context
(not updated against some recent activity).  So, unexpected ENOMEM is
returned.

Such allocation may be a result of e.g. asynchronous logging or
statistics update.


I totally agree with you that injecting such faults where a program doesn't
expect it is wrong, but sometimes it can be not obvious for kernel
developers that it breaks something.  Even if they don't want to
introduce such cases, it can be unintendedly introduced by a bug
(e.g. sendmail setuid vulnerability).  Such bugs may be tricky to catch
and may appear in very rare situations.  Trying to catch such cases would
make the program much more robust against kernel bugs/changes (unless the
error handling code complicates the whole logic and/or is not well
tested).

Thanks,

-- 
Vasiliy