From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Date: Sun, 3 Jul 2011 21:38:08 +0200 From: Ingo Molnar Message-ID: <20110703193808.GA17797@elte.hu> References: <20110622152514.GA9521@albatros> <20110629151436.9be479fb.akpm@linux-foundation.org> <20110701112534.GG20990@elte.hu> <20110701113533.GA19945@albatros> <20110701120453.GA28008@elte.hu> <20110701151827.7061dcda@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110701151827.7061dcda@lxorguk.ukuu.org.uk> Subject: [kernel-hardening] Re: [RFC] ipc: introduce shm_rmid_forced sysctl To: Alan Cox Cc: Vasiliy Kulikov , solar@openwall.com, Andrew Morton , kernel-hardening@lists.openwall.com, Randy Dunlap , "Eric W. Biederman" , "Serge E. Hallyn" , Daniel Lezcano , Oleg Nesterov , Tejun Heo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org List-ID: * Alan Cox wrote: > > As we really prefer working systems over non-working ones (and lots > > of unattached shm segments can clearly result in a non-working > > system) we can only accept the "this will break stuff" argument if > > it's *demonstrated* to break stuff and if the failure scenario is > > carefully described in the commit. > > > > It would take a serious breakage to override a "system locks up > > swapping itself to death" failure scenario. > > Ths shared memory interface is defined to be persistent for good > reason and all sorts of apps rely upon that so no you can't just > ignore that. As a configurable alternative it makes sense (indeed > many SYS5 admins used to run shared memory segment sweepers to > clean up long idle ones) > > However if it's locking the machine up and not being properly > handled by resource management then > > a) your resource management is broken so fix that instead > b) if your resource management is busted or you are not properly > tracking resource commits then the user is going to be able to achieve the > same result by other means (eg a unix domain socket bomb) > > If you've got no overcommit set you shouldn't be able to swap to > death, it may be the sysv shared memory objects need to be > accounted for specifically somewhere but that would be the right > thing to fix and the mechanisms to do it exist. But the majority of systems have overcommit enabled - that is our default. This is a simple extension of the OOM killer being able to ... kill things on OOM, ok? 'to kill' implies 'to break'. Thanks, Ingo