[linux-security] Re: simple perl script bypasses limits

[R E Wolff BitWizard nl (Rogier Wolff)]

Scott Doty wrote:
> Regarding that patch to sys_mremap()...
> 
> I sent it to Alan Cox, who suggested some extra checks:
>   * RLIM_INFINITY (as in sys_brk)
>   * same check in do_mmap()
> 
> Thinking that over, it also appears shm_map() may need the same
> treatment, and maybe the do_mmap() check needs to make sure it
> applies only to real RAM (not mmap'ed files).
> 
> However, it seems easier to just copy the RLIMIT_DATA field to
> RLIMIT_AS as an interim fix.  Dean indirectly pointed that
> out...
> 
> On Tue, Nov 24, 1998 at 08:49:52AM -0800, Dean Gaudet wrote:

> > Both the current situation (which has been noted a dozen times on
> > linux-kernel), and your patch violate the single unix spec.  Single
> > Unix specifies that RLIMIT_DATA affects malloc, sbrk, brk; and
> > RLIMIT_AS affects those plus mmap and automatic stack growth.  Linux
> > libc uses mmap() to acquire memory for malloc -- which is arguably
> > where the bug is, but it's a nice feature.

I'd like to interpret the spec as saying that brk and sbrk are
affected RLIMIT_DATA, and that "mmap" is counted into RLIMIT_AS.  The
remark about "malloc" could be taken as "normally, malloc
implementations would use brk, so it should be counted under RLIMIT_DATA".

However, I don't know if the spec would allow this interpretation. 

> > The correct fix is to add a non-standard mmap()
> > flag which indicates that the request should be applied against the
> > RLIMIT_DATA limit in addition to the RLIMIT_AS limit.  That way folks
> > expecting the Single Unix behaviour of mmap() vs. RLIMIT_DATA will
> > get it.
> 
> > bash-2.0 supports RLIMIT_AS.
> 
> The problem:  most shells don't appear to support it, and I daresay
> most Linux systems, with untrusted users, allow the user to select
> a shell.
> 
> I suppose you could make sure login, sshd, httpd, etc. set the
> RLIMIT_AS properly, but it's easier to make it work in the kernel.

But as you have the sources, it would be best if you just went along
and fixed the applications that need fixing. If your patches are
clean, they will be incorporated into the standard versions, and then
the world is a better place....

> > Linux libc uses mmap() to acquire memory for
> > malloc -- which is arguably where the bug is,
> 
> I personally don't care where the bug is, I simply want to correct
> an insecure situation.  Or, if you prefer, I want to correct
> deficiencies in the shells, libraries, etc. by heading off the
> weird behavior at the choke point.

Sometimes, the easiest way to fix things is not the right way to fix
it. That's true this time. 

Linus, correctly holds the opinion that you'd rather fix things 
once and for all.

> > Both the current situation (which has been noted a dozen times on
> > linux-kernel), and your patch violate the single unix spec.
> 
> We run production Linux systems with untrusted users.  I'm sure
> there's more than one of those users who would cackle with glee at
> the opportunity to kill our systems.  Without some action, those
> systems would be dead in a matter of days, perhaps hours.
> 
> I doubt if the rest of our users would care much that our
> dead systems adhered to the single unix spec.
> 
> > Oh and I think it's a pretty dumb part of the spec too... but specs
> > are specs.
> 
> Specs are useless on dead systems.  I think the priorities should
> be "Secure, Reliable, Rapid" -- in that order.
> 
>  -Scott
> p.s.  And I sure wish vger's listserv would talk to me -- is there something
> wrong with it?
> 


-- 
My pet light bulb is a year old today.   \_________  R E Wolff BitWizard nl
That's 5.9*10^12 miles. Your mileage will NOT vary.\__Phone: +31-15-2137555
--(time <-> distance can be converted: lightspeed)--  \____ fax: ..-2138217
We write Linux device drivers for any device you may have! \_______________