Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030229AbXALUIf (ORCPT ); Fri, 12 Jan 2007 15:08:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030243AbXALUIe (ORCPT ); Fri, 12 Jan 2007 15:08:34 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]:56825 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030229AbXALUIe (ORCPT ); Fri, 12 Jan 2007 15:08:34 -0500 In-Reply-To: <20070111143537.GB6843@ucw.cz> To: Pavel Machek Cc: akpm@osdl.org, Christoph Hellwig , kjhall@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, safford@watson.ibm.com MIME-Version: 1.0 Subject: Re: mprotect abuse in slim X-Mailer: Lotus Notes Release 7.0.1P Oct 16, 2006 Message-ID: From: Mimi Zohar Date: Fri, 12 Jan 2007 15:08:32 -0500 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V80_M3_10312006|October 31, 2006) at 01/12/2007 15:08:34, Serialize complete at 01/12/2007 15:08:34 Content-Type: text/plain; charset="US-ASCII" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1782 Lines: 38 Pavel Machek wrote on 01/11/2007 09:35:37 AM: > Hi! > > > SLIM implements dynamic process labels, so when a process > > is demoted, we must be able to revoke write access to some > > resources to which it has previously valid handles. > > For example, if a shell reads an untrusted file, the > > shell is demoted, and write access to more trusted files > > revoked. Based on previous comments on lkml, we understand > > that this is not really possible in general, so SLIM only > > attempts to revoke access in certain simple cases. > > Are you saying that SLIM is useless by design because interested > parties can work around it? > Pavel Sorry that we were unclear about what happens in the case revocation is not possible. In those cases, the unsafe requested read or exec that would normally trigger the demotion/revocation is denied, so there is no way around the integrity model. The goal of the low water mark integrity model is to be as transparent as possible to the user. If the user asks for something to be done, we allow it as much as possible, demoting the process as needed for security. If there is something that would need to be revoked, which can't safely be revoked, then we deny the read/exec request, which is secure, but possibly visible/annoying to the user. Fortunately in our testing, there are only a few cases where this happens, and the overall result is a model which is still much more transparent than other models which don't allow demotion at all. Mimi Zohar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/