From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263818AbUHGRpf (ORCPT ); Sat, 7 Aug 2004 13:45:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263824AbUHGRpf (ORCPT ); Sat, 7 Aug 2004 13:45:35 -0400 Received: from mx1.redhat.com ([66.187.233.31]:44488 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S263818AbUHGRpc (ORCPT ); Sat, 7 Aug 2004 13:45:32 -0400 From: David Howells In-Reply-To: <1091869155.4373.28.camel@lade.trondhjem.org> References: <1091869155.4373.28.camel@lade.trondhjem.org> <6453.1091838705@redhat.com> To: Trond Myklebust Cc: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, arjanv@redhat.com, dwmw2@infradead.org, jmorris@redhat.com, greg@kroah.com, Chris Wright , sfrench@samba.org, mike@halcrow.us, Kyle Moffett Subject: Re: [PATCH] implement in-kernel keys & keyring management User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Sat, 07 Aug 2004 18:45:06 +0100 Message-ID: <11350.1091900706@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Trond Myklebust wrote > > - Two std keyrings per user: per-user and default-user-session > > So what *is* the reason for the "per-user" and "default-user-session" > keys? Well, Linus wants a user keyring. Originally I was going to just include this in the "search path" for keyring search. However, it has become obvious that it's necessary to be able to exclude the user keyring from the search path under certain circumstances, so I thought why not add it to the session key, so that it is accessible via keyring nesting. However, I think it's still necessary to show some separation between the session and the user keyrings, and unless PAM or something is made use of, you won't get that if each process uses the user keyring as its session by default. It also allows me to add a facility by which a process can duplicate its session keyring and subscribe to the new one instead, whilst retaining a link to the real user keyring. Of course, this is open to negotiation. I'm not entirely convinced I need it, but it seemed right at the time. > In a strong authentication model, a setuid process should not normally > find itself automatically authenticated to a new set of keys. This only happens when a process subscribed to the root default-user-session keyring sets the UID to something non-zero. Execution of a SUID binary does not change the session keyring. The idea was that non-root users will probably want their own session keyring, not root's. I can think of several other ways of dealing with this: (*) Let userspace (PAM) determine the session. (*) Start with no session keyring set on any process, and only attach a process to the default-user-session when someone tries to access their session keyring if there isn't one set, or when a setuid() is performed (or maybe setsid()?). (*) Have an init-specific session keyring as well. David