kernel-hardening - Re: [RFC] ipc: introduce shm_rmid

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <20110703193808.GA17797@elte.hu>
Date: Sun, 3 Jul 2011 21:38:08 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Vasiliy Kulikov <segoon@...nwall.com>, solar@...nwall.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	kernel-hardening@...ts.openwall.com,
	Randy Dunlap <rdunlap@...otime.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge E. Hallyn" <serge.hallyn@...onical.com>,
	Daniel Lezcano <daniel.lezcano@...e.fr>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC] ipc: introduce shm_rmid_forced sysctl


* Alan Cox <alan@...rguk.ukuu.org.uk> 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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.