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

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: <20110701151827.7061dcda@lxorguk.ukuu.org.uk>
Date:	Fri, 1 Jul 2011 15:18:27 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
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

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


--
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/