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]
Message-ID: <4F8ECED3.5070909@redhat.com>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ