From owner-freebsd-afs Sun Feb 15 10:48:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07223 for freebsd-afs-outgoing; Sun, 15 Feb 1998 10:48:28 -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 KAA07217; Sun, 15 Feb 1998 10:48:26 -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 NAA09833; Sun, 15 Feb 1998 13:31:21 -0500 (EST) Date: Sun, 15 Feb 1998 13:31:20 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-hackers@FreeBSD.ORG, freebsd-afs@FreeBSD.ORG Subject: PROPOSAL: Process Authentication Groups (PAGs) (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 This is a formalization of some of the issues Peter and I (and others) have previosly discussed. For the purposes of Coda, this PAG architecture should be sufficient for our requirements (and is similar to the AFS concept of PAG, albeit with different implementations). I would like to try to come up with a more general architecture (which meets some of the requirements laid out by Terry and myself), but as long as the PAG behavior is a compatible subset, working with these goals should be fine from now. One of these days (read: in the next 9 months or so) I want to try implementing some ideas I've had about alternate authentication and authorization structures under FreeBSD on a kernel test machine or two. In the context of distributed systems, integration of Kerberos (and other systems) of distributed security really only work with UNIX as hacks (such as the concept of a ticket file, ssh-agent, etc). If there is sufficient interest out there, I'd like to set up a mailing list to discuss the integration of alternative systems into standard UNIX -- both methods taken by others and possible new ones. Please email me if this is of interest to you? 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: Sun, 15 Feb 1998 09:04:21 -0500 (EST) From: Peter Braam To: linux-kernel@vger.rutgers.edu, robert@watson.org, tytso@mit.edu, yale-pag-project , john.hartman@yale.edu, matthew.hiller@yale.edu, Michael Callahan Subject: PROPOSAL: Process Authentication Groups (PAGs) 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. Coda finds this partition into protection groups based on uid too coarse; the sets of processes it wants to authorize should be smaller. For example smbfs and ncpfs need subsets of processes to allow more than one authenticated session to an NT or Novel server, much like Coda. Another example, is that root is not to be trusted lightly but can change its uid easily -- systems based on the Kerberos model don't like this. A further worry arises when telnetd is serving two sessions for the same uid, it is good practice 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 defined by the following: - Every process should belong to a pag - Pag's are inherited by fork - at boottime init has a zero pag - when process executes a login related operation (preferrably through a PAM module) this login process would execute a "newpag" system call which places the process in a new PAG. - any process can execute newpag 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. History ------- The Andrew project used PAGs for AFS authentication. They were "hacked" in the sense that they used 2 fields in the groups array. Root can fairly easily change fields in the group array on some systems -- so this doesn't look so nice. I have no idea what the second field was used for. They called the system call "setpag", but "newpag" seems to better convey semantics. Finally there was/is a special value of pag which was meant to be ignored. I haven't seen the need for this. Implementation -------------- The simplest is to assign a PAGid just like the pid when newpag is executed. This costs one "int" field in the process structure. The PAG can be made increasing and will always be new. Newpag will be a simple system call increasing a global variable maxpag and assigning this to the PAG field in the process structure. We could use /proc/pags to hold a list of pags. One may argue that kernel subsystems may want to hold data related to a PAG and that using a pointer to some kernel data structure - which we can extend as need arises - is more efficient. The worry I have about this is that this pointer may be re-used for a different PAG and that it might be difficult to update all user level processing holding data related to a PAG. How would Coda use PAGS? ------------------------ The following discussion summarizes our ideas about using PAGs for Coda. 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 session key and PAG -- from this moment Venus associates a PAG with a session key. A) session keys for root There are a few interesting issues which relate to root and PAGS. Since PAGS are inherited by fork, it could 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: newpag get a session key exec(program) If roots want 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. 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 an "unsafe" session key there with "clog --unsafe 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. - Peter Braam - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-afs" in the body of the message From owner-freebsd-afs Mon Feb 16 11:12:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25408 for freebsd-afs-outgoing; Mon, 16 Feb 1998 11:12:10 -0800 (PST) (envelope-from owner-freebsd-afs@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25272; Mon, 16 Feb 1998 11:11:51 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA04386; Mon, 16 Feb 1998 11:09:43 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004383; Mon Feb 16 11:09:34 1998 Date: Mon, 16 Feb 1998 11:05:42 -0800 (PST) From: Julian Elischer To: Peter Braam cc: "Matthew N. Dodd" , Eivind Eklund , hackers list FreeBSD , Damon Permezel , rvb@cs.cmu.edu, freebsd-afs@FreeBSD.ORG, robert@watson.org, henry@cs.cmu.edu, linux-coda@TELEMANN.coda.cs.cmu.edu, tytso@mit.edu Subject: Re: Coda [ was: RE: Coda FS: FBSD port done!, but development favors ], Linux In-Reply-To: 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 > B) Inode calls. > --------------- It should be a relatively simple thing to add a VFS layer'ed IFS that sites on top of a standard FS to give direct inode access. Also one Adrian Chadd recently implemented direct inode access mode for UFS. > > For scalability these calls are desirable. In fact we probably only need > iopen, istat, idelete and I'll try to remove iinc and idec (used for copy > on write vnodes). These inode calls are only used by the cache manager and > the servers and don't compromise security of the system, since they should > be restricted to root. > > Ted Ts'o indeed said that Linus is probably against plain "iopen" -- and > rightly so. Using the special names like 'I'N'O'D'E we can let it work > right with the VFS and dentry's etc while retaining most of the benefits > of speed. For Coda this will just become an optionally supported > partition type. I believe this is the way Adrian did it but with a slightly less likely string. > > It should indeed be a mount option, or better perhaps something set with a > utility in the superblock, so that fsck knows about it too. (see the > messages of myself and Ted on linux-coda). > > C) Ext2 vs FFS vs Coda > ---------------------- > > Coda needs much larger vnodes to deal with replication servers (among > others). We also run in user space -- mostly and use proper RVM > transactions to guarantee (on all platforms) very high consistency on > metadata. Effectively we are a transactional, log based system on servers. > We use file storage only for file data not for metadata. > > On clients we also have transactions, but we don't flush them right away. > > We hope to implement write back caching where large groups of transactions > can reach the server and improve performance by eliminating many > transaction related fsyncs. > > It is unwise to speculate about the consistency guarantees which ext2fs > might offer to Coda versus ffs -- without considering RVM. The Coda meta > data will be treated identically through RVM, on all platforms. The file > data might be slightly more at risk in ext2fs (although I believe that ffs > and extfs mostly differ in the handling of metadata). With the addoption of the Ganger/Patt Dependeancey tracking code in the FreeBSD FFS (implemented by Kirk mcKusick), you will find the behaviour of the FFS extremely different to what you are used to. possibly the implementation of a central file-locking mechaninsm (for use by nfs, ufs, samba and netatalk) might also be of interest to you. > > I hope this clarifies some of the recent discussions. > > Thank you very much for all your enthusiasm -- that makes us very happy of > course. > > - Peter Braam - > Senior Systems Scientist > Coda Project, SCS, CMU > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-afs" in the body of the message