linux-kernel - Re: [Patch 5/8] mqueue: revert bump up DFLT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2012 15:33:12 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Doug Ledford <dledford@...hat.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, kosaki.motohiro@...il.com,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Amerigo Wang <amwang@...hat.com>,
	"Serge E. Hallyn" <serue@...ibm.com>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: [Patch 5/8] mqueue: revert bump up DFLT_*MAX

Quoting Doug Ledford (dledford@...hat.com):
> On 4/17/2012 11:22 PM, Serge E. Hallyn wrote:
> > Quoting Doug Ledford (dledford@...hat.com):
> >> From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> >>
> >> Mqueue limitation is slightly naieve parameter likes other ipcs
> >> because unprivileged user can consume kernel memory by using ipcs.
> >>
> >> Thus, too aggressive raise bring us security issue. Example,
> >> current setting allow evil unprivileged user use 256GB (= 256
> >> * 1024 * 1024*1024) and it's enough large to system will belome
> >> unresponsive. Don't do that.
> >>
> >> Instead, every admin should adjust the knobs for their own systems.
> > 
> > Would you be terribly averse to having a higher limit in init_ipc_ns,
> > and the lower values by default in all child namespaces?
> > 
> > Sorry it sounds from the intro like you've already had quite a bit of
> > discussion on this...
> > 
> > Of course I realize the values can just be raised by distro boot
> > scripts...
> 
> The default maximums this patch put into place were in fact in place
> from 2008 until my earlier patch in this same series, so in that regard
> this is merely restoring an already established default maximum.  It

Then never mind :)

(My ack stands)

> *could* be raised, yes, but as Motohiro pointed out, this is pinned
> memory that any user can allocate, so the smaller the default amount the
> better.  The sysadmin can make changes as they see fit.

Thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/