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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2012 10:25:23 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
CC:	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

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

-- 
Doug Ledford <dledford@...hat.com>
              GPG KeyID: 0E572FDD
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


Download attachment "signature.asc" of type "application/pgp-signature" (899 bytes)