From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/201 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: some fixes to musl Date: Sun, 24 Jul 2011 08:56:44 -0400 Message-ID: <20110724125644.GJ132@brightrain.aerifal.cx> References: <20110721170255.GA7352@albatros> <20110721182101.GB132@brightrain.aerifal.cx> <20110721191643.GA29045@albatros> <20110722020820.GD132@brightrain.aerifal.cx> <20110724093911.GB6076@albatros> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1311512859 5318 80.91.229.12 (24 Jul 2011 13:07:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 13:07:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-285-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 24 15:07:35 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QkyP7-0002SE-Rr for gllmg-musl@lo.gmane.org; Sun, 24 Jul 2011 15:07:33 +0200 Original-Received: (qmail 7853 invoked by uid 550); 24 Jul 2011 13:07:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7841 invoked from network); 24 Jul 2011 13:07:31 -0000 Content-Disposition: inline In-Reply-To: <20110724093911.GB6076@albatros> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:201 Archived-At: On Sun, Jul 24, 2011 at 01:39:11PM +0400, Vasiliy Kulikov wrote: > > It should be obvious that a bogus LSM will create gaping security > > holes if it's allowed such power. > > I don't say such handling is perfect, just want to show it can be > somehow justified: > > Most of LSM hooks maintain some security context associated with > file/task/socket/etc. Some actions may require (re)allocation of this > context. If the allocation fails (e.g. OOM), it's wrong to allow the > task to continue the work with the object, which has an outdated context > (not updated against some recent activity). So, unexpected ENOMEM is > returned. Are you saying that all operations on the associated object (file/task/socket/etc.) are automatically first subjected to an LSM hook? Or just that the LSM module author might set up a hook? In the latter case, I would say it's a bug and potential gaping vulnerability for a module to install a hook on any resource-deallocation function. If it's the former, I would say it's a bug and gaping security hole in the whole LSM architecture. Failure to account for dependence of a critical operation on resource allocation is a classic programming error. To fix it, I would imagine the allocation either needs to be moved to the action that caused (re)allocation to be needed, or LSM hooks need to be skipped for resource deallocation functions, or LSM hooks need to fallback to success rather than failure when resource (re)allocation fails during a resource deallocation operation. But since I'm not familiar with the LSM architecture, this is only speculation. In short, I think you've raised really good points, and LSM probably needs an audit... > I totally agree with you that injecting such faults where a program doesn't > expect it is wrong, but sometimes it can be not obvious for kernel > developers that it breaks something. Not being aware that you're breaking something isn't a very good excuse. In any case, following a principle of "deallocation cannot fail" should not be too hard, and it's required for C++ RAII apps to work anyway (what can you do if an operation fails during a destructor?!) > Even if they don't want to > introduce such cases, it can be unintendedly introduced by a bug > (e.g. sendmail setuid vulnerability). Such bugs may be tricky to catch > and may appear in very rare situations. Trying to catch such cases would > make the program much more robust against kernel bugs/changes (unless the > error handling code complicates the whole logic and/or is not well > tested). I agree that it's better to check for failure and handle it where you can. What bothers me is the creation of error cases that are usually impossible to handle. Rich