From owner-freebsd-afs Tue Feb 10 10:43:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17777 for afs-outgoing; Tue, 10 Feb 1998 10:43:15 -0800 (PST) (envelope-from owner-freebsd-afs@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17767 for ; Tue, 10 Feb 1998 10:43:08 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id NAA26191 for ; Tue, 10 Feb 1998 13:43:07 -0500 (EST) Date: Tue, 10 Feb 1998 13:43:07 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-afs@FreeBSD.ORG Subject: PAGs for all, PAM for Coda (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-afs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I met with Peter yesterday and last week to discuss issues relating to Coda authentication and credential management for processes -- we managed to hash out a process authentication group mechanism that it later turned out was almost identical to an existing AFS/DFS "PAG" concept. Peter's email recapping discussion we had had as well as discussions between him and Ted Tso (and others). This issue will be important in integration of various file systems (including AFS) into FreeBSD. We'd like to use a general mechanism applicable to all of these, not one specific to Coda. I have a more kernel-managed approach, whereas Peter wants the work to lie more in the Venus code, but we generall agree on functionality. We would appreciate all recommendations and discussion in an attempt to come up with a consistent and general solution to the problem. Just a quick summary of the issue for those who are not familiar with it: BSD (and other Unices) impose most authorization restrictions on the basis of a processes UID and groups. Coda (and other distributed file systems, including AFS and DFS) uses "tokens" similar to Kerberos tickets to identify the principal requesting file system access. The user-land cache and connection management code (known as Venus in AFS and Coda) is passed these tokens via the kernel's CFS interface (using pioctls, etc). The problem is that associating tokens with UIDs has many limitations. A single user may wish to aquire two different sets of tokens in different xterms, and see appropriate behavior. Also, an NFS server gatewaying between CFS and NFS might wish to have different processes with different Coda identities associated with it. The solution employed in AFS implementations associates all processes with Process Authentication Groups (PAGs) which have tokens associated with them. login, su, etc, form new pags similar to session behavior. Calls to clog (or kclog, the kerberized version I am in the process of implementing) modify the tokens of the current PAG, but do not switch PAGs. We would like to generalize this approach some, and have consistent features across unices. Implementation may, of course, vary from platform to platform, but there are similar requirements, so discussion seems to be in order? Anyhow, Peter's email is attached below. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Tue, 10 Feb 1998 13:22:17 -0500 (EST) From: "Peter J. Braam" To: yale-pam-project , eric.n.friedman@yale.edu, rivka.spivak@yale.edu, yale-pag-project , john.hartman@yale.edu, matthew.hiller@yale.edu, Michael Callahan , robert@watson.org, Elliot Lee , linux-coda@TELEMANN.coda.cs.cmu.edu, shadow@dementia.org, tytso@mit.edu Subject: PAGs for all, PAM for Coda Please find my project description for the "session" (now PAG) and PAM projects. I will want to submit an edited version of the PAG discussion to linux-kernel and Linus to see if we can mainstream this. I welcome comments. - peter - Process Authentication Groups ----------------------------- Coda as well as other system services want to implement a stricter form of protection and authentication. Unix authorizes processes based on their uid -- the uid defines a partition of the set of processes. Kerberos based software generally find this partition into protection groups based on uid too weak; the sets of processes it wants to authorize should be smaller. For example, root is not to be trusted lightly but can change its uid easily. A second worry arises when telnetd is serving two sessions for the same uid, Coda (or something like it) finds it necessary to ask each of these sessions to authenticate. The smaller group of processes for which authentication should give access is called a PAG, a process authentication group. Hopefully it is correctly described by the following: - Every process should belong to a pag. - Pag's are inherited by fork - at boottime init has a zero pag - the setuid system call causes the process to continue its life in a new PAG, but setuid(SAVED_IDS) restores the PAG. - when a process executes a login related operation (preferrably through a PAM module) this login process would execute a "setpag" system call which places the process in a new PAG. - any process can execute setpag and thereby leave an authentication group of which is was a member - the kernel can return a list of PAG's in use (a la "ps") so that processes holding resources indexed by PAGs can garbage collect resources for PAGS that have gone away. This list will include the pags found under "SAVED_IDS". PAG's are different from process groups and session groups. These change more often and are meant for job control. PAGs are totally independent of Coda and require a system call "setpag" to join a new PAG and a facility to list all PAGs known to the system. The could be implemented as a 32 bit integer in the process structure. How would Coda use PAGS? ------------------------ When a system call reaches the Coda kernel code, Coda queries Venus for access by giving it the PAG as part of the Coda credentials of the process. Venus checks if it has a token for this pag and bases access on this. To get a token a process in the same PAG would use the "clog" (Coda login) program. This negotiates a session key with the auth server (perhaps using Kerberos) and asks the kernel to pass Venus the key and PAG. Related issues -------------- A) session keys for root There are a few interesting issues which relate to PAGS. Since PAGS are inherited by fork, it would be very dangerous for a root process to have a session key. Imagine that root has a session key and starts a deamon process. The deamon process would inherit the permissions root has through it's PAG and session key and possibly pass such permissions to any user process requesting service from the daemon. In contrast with this, it is highly desirable that root can start processes which have session keys: however we don't want to give the current PAG those session keys since that could be risky. We propose the following solution: 1) clog will not acquire token for the root user without a further argument. 2) clog can be given a "-e" (for execute) flag. If one were to execute: clog braam -e program Clog would: fork in the child: setpag get a session key exec(program) If roots wants a Coda authenticated shell with a key for user moose she would execute: clog moose -e bash B) weaker authentication for special programs Imagine that we are running an NFS server on machine A, and that A is a coda client. We want this nfs server to export /coda to machine B, which is NOT a Coda client. We assume that the nfs server is well behaved and changes its fsuid to that of the user on behalf of which it is servicing a request. To make this useful we would want a user U on B to telnet to A and create a "sloppy" session key there with "clog -s U". A session key would be given to Venus with a sloppy flag which enables the following: When Venus decides access permissions to serve a request coming from the NFS server, it fails to find a PAG key for the PAG passed by the NFS server. It continues searching for a sloppy key matching the fsuid of the NFS server and grants permissions based on that. PAG project ----------- You should look at the process structure in the Linux (2.1) kernel. Add a PAG field. Write a setpag system call which assigns a new PAG (just take an ever increasing integer -- for SMP safeness get a lock before you increase the value). Make sure that setuid, setfsuid etc. change the PAG of the process as above. Build the PAG into the CodaCred structure (replace the session id). Look in linux/include/linux/coda.h and linux/fs/coda/ and search for "cred and CodaCred". Modify the process utilities like "ps" to get a list of PAGs which are in use. Finally you'll have to modify Venus to take this into account, we'll do that later. I will be contacting Linus Torvalds -- after some further review by friends -- to see if he will "buy" our PAGs. Perhaps this will lead to some new thoughts. Your stuff might end up in the kernel! PAM project ----------- As you have probably gathered this is closely related to the PAG story. We want two PAM modules -- one which does a setpag whenever a process logs in (be it from the terminal, through telnet, su or ssh). All of these can hopefully call the same PAM module. You can build this entire module and plug in the setpag call when your colleagues above have constructed it. The other PAM module tries to acquire Coda tokes when you log in: this module MUST run after the setpag call has been made. It might prompt you for a Coda username and Coda password (after it fails to use the previously entered username and password perhaps). This module would be very similar to the clog program in the coda sources: look at coda-src/login/clog.c. Documentation about PAM can be found in /usr/doc/pam-???/html/index.html on your Linux machine. I know many of the PAM people personally, but I am not really an expert. You should unpack the sources to PAM from the RedHat src.rpm and try to understand some of the modules, and then mimic that. I think this will be a lot of fun and the end effect would be totally smooth Coda authentication! Good luck. Contact me for help if you need any. - Peter - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe afs" in the body of the message