Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751130AbVJFQOR (ORCPT ); Thu, 6 Oct 2005 12:14:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751131AbVJFQOR (ORCPT ); Thu, 6 Oct 2005 12:14:17 -0400 Received: from mail28.sea5.speakeasy.net ([69.17.117.30]:46034 "EHLO mail28.sea5.speakeasy.net") by vger.kernel.org with ESMTP id S1751130AbVJFQOQ (ORCPT ); Thu, 6 Oct 2005 12:14:16 -0400 Date: Thu, 6 Oct 2005 12:14:13 -0400 (EDT) From: James Morris X-X-Sender: jmorris@excalibur.intercode To: David Howells cc: Linus Torvalds , Andrew Morton , keyrings@linux-nfs.org, linux-kernel@vger.kernel.org, Stephen Smalley Subject: Re: [Keyrings] [PATCH] Keys: Add LSM hooks for key management In-Reply-To: <30054.1128611494@warthog.cambridge.redhat.com> Message-ID: References: <29942.1128529714@warthog.cambridge.redhat.com> <23641.1128596760@warthog.cambridge.redhat.com> <30054.1128611494@warthog.cambridge.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2214 Lines: 67 On Thu, 6 Oct 2005, David Howells wrote: > > > Should I expand the permissions mask to include a setattr? > > > > Possibly for setperm and chown. > > For setperm? It changes an attribute of a key, for which you have DAC checks, therefore you could assume that we'd also want MAC checks. > > > > All users of key_permission() need to propagate the error code from the > > > > LSM back to the user. > > > > > > Really? Why? > > > > Because the LSM has final say on the error code returned to the caller. > > If the LSM runs out of memory, for example, it's silly to return -EACCES. > > > > > Note that the fact that key_permission() fails for a key is sometimes > > > ignored, such as when I'm doing a search and one potentially matching key > > > fails, but a subsequent matching key passes. > > > > Ok, that sounds like an internal issue to be resolved, ensuring that if > > you are returning to the caller, the LSM's error code is returned. > > But which LSM error code? > > Let me explain what I mean: [snipped] Thanks for the detailed explanation. Not sure yet how we'll avoid generating spurious SELinux denial messages. > Only if all these fail does the whole thing fail with the highest priority > error. Note that several errors may have come from LSM. > > The error priority should be: > > EKEYREVOKED > EKEYEXPIRED > ENOKEY > > EACCES/EPERM should only really be returned on a direct keyring search where > the basal keyring doesn't have Search permission. Ok, if a failure of this nature is generated by an LSM, we need to return the LSM's error code (e.g. ask the LSM for search permission and it returns -ENOMEM). > The fact that I couldn't find a key because I didn't have permission to find > it probably shouldn't cause an immediate abort of the search with an error, or > any error other than ENOKEY/EKEYREVOKED/EKEYEXPIRED, unless I'm not permitted > to request a new key. Ok. - James -- James Morris - 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/