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 From owner-freebsd-afs Tue Feb 10 11:19:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24060 for afs-outgoing; Tue, 10 Feb 1998 11:19:32 -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 LAA24053 for ; Tue, 10 Feb 1998 11:19:30 -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 OAA26471 for ; Tue, 10 Feb 1998 14:05:38 -0500 (EST) Date: Tue, 10 Feb 1998 14:05:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-afs@FreeBSD.ORG Subject: Re: PAGs for all, PAM for Coda (fwd) 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 Just to put his email in context -- a class at Yale is taking on Coda hacking for student projects. Peter's email discusses the nature of some of the projects (kernel support, PAM support, etc). My feeling is that the concept of a PAG will require some further refinement before any implementation takes place. Issues include garbage collection, call-backs, transition across setuid (syscall, not app) boundaries, etc. 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/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe afs" in the body of the message From owner-freebsd-afs Thu Feb 12 10:39:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA08506 for afs-outgoing; Thu, 12 Feb 1998 10:39:30 -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 KAA08495; Thu, 12 Feb 1998 10:39:22 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id NAA28987; Thu, 12 Feb 1998 13:39:15 -0500 (EST) Date: Thu, 12 Feb 1998 13:39:09 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Charles Owens cc: hackers list FreeBSD , freebsd-afs@FreeBSD.ORG Subject: 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 Other kernel extensions we have been looking at include PAG support in the kernel -- please see recent posts on freebsd-afs for some initial discussion of this. I, also, have been meeting with Peter :). We had a fairly extensive discussion of some authentication features yesterday -- I have not looked at the inode code and as such I have not looked into possible security problems. As I understand it, the inode behavior is for performance reasons only, and as such there are presumably alternatives. I'm leaving for the airport in an our or so, but have a meeting scheduled with Peter for Wednesday of next week to discuss security concerns in various areas, including kernel code, kerberos support, and inter-server communications. My kerberos implementation is essentially complete; addressing PAG-like issues was the concentration for our last meeting. Our long-term goal is to work with various communities (such as FreeBSD, Linux) to come up with a generalized authentication extension available to distributed file systems (such as AFS, CFS) for associating tokens or priveledges with a set of processes, not just with a UID. Those of you familiar with AFS will know that if you have two incoming telnets, one can have rights to the file system while the other does not, depending on whether you have klog'd or not. There are numerous reasons for having such a service -- for example, it would be nice if daemons running as root did not have access to the same file system as a root shell elsewhere, etc. This might have uses in other areas also -- for example, it might interact with management of keys for other services, such as IPsec, where the kernel knows what authentication group each process is associated with, and provides keys as appropriate. It seems like freebsd-afs might be a better location for this discussion, however -- at least until we figure out what the requirements are? 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/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe afs" in the body of the message From owner-freebsd-afs Thu Feb 12 10:53:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10679 for afs-outgoing; Thu, 12 Feb 1998 10:53:33 -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 KAA10641; Thu, 12 Feb 1998 10:53:29 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id NAA29158; Thu, 12 Feb 1998 13:53:28 -0500 (EST) Date: Thu, 12 Feb 1998 13:53:22 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Marca Registrada cc: hackers list FreeBSD , freebsd-afs@FreeBSD.ORG Subject: Re: Coda FS: FBSD port done!, but development favors Linux In-Reply-To: <19980212123955.08290@nyef.res.cmu.edu> 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 On Thu, 12 Feb 1998, Marca Registrada wrote: > I'm also extremely interested in using Coda on FreeBSD, and have offered > as much help as I can to Peter Braam, but CMU keeps their students fairly > busy ;), so the amount of actual codework I can put forth is rather > limited. I'm still waiting for the release of the FreeBSD code so I can > least get started playing with it. I second that on the busy. :) I am about to add the coda client to one of my test machines. I suspect that the FreeBSD release is just a week or two away -- there have been some problems with the BSD port of RVM - Recoverable Virtual Memory (Satyanarayanan - ACM Transactions on Computer Systems, Feb 1994, Vol 12, No. 1, pp. 33-57). I believe these will be cleared up shortly. These problems largely affect the server code, not the client. Feel free to give me a call if you have any questions -- a CMU, my number is x2-2696. I will be installing the client on some of our test machines early next week when I get back from Massachussets. The Coda project test machines I have worked on seem quite stable. > The current Coda release that I know of for FreeBSD is supposed to be for > -stable, so my first project may be to port it to -current (although I've > heard this may be difficult), and it would be easier for me to make light > contributions from time to time to do whatever is necessary when the > -stable-patched are unworkable for -current. The release anticipated for the next week or two is based on 2.2.5-RELEASE. This decision was made on the basis of the stability of the vm interface in -current a month or two ago. Also based on the similiarity to the NetBSD port also to be released shortly. My recommendation to Peter as of last week was that we go ahead with a -current port ASAP. He agreed that this was a priority. I would anticipate progress in this area very soon. All of my development work with the Auth server has been based on -current because of the Kth kerberos support there. While my code will certainly work on all of the other platforms/versions, I have no plans to switch my development machines. :) > I'm totally with you on wanting to get Coda going strong on FreeBSD, and > will lend all the free coding time I have. Some of my free coding time already goes to this -- most of my paid programming time, on the other hand, goes into Coda security issues. Since I've only been with the project for a month or so, it may be a few revisions before my work begins to show up :). > As an aside, you also mentioned AFS. Has that been progressign at all on > the FreeBSD front? I havn't heard anything but light rustle about AFS. I recommend the freebsd-afs mailing list -- there is not much traffic just now, but given recent discussion of Coda, I suspect things will be moving along. :) The main problem with AFS for most of us is licensing. I, myself, don't have AFS source code lying around. On the other hand, given that I work for Coda, this is just as well. 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/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe afs" in the body of the message From owner-freebsd-afs Thu Feb 12 14:48:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18758 for afs-outgoing; Thu, 12 Feb 1998 14:48:03 -0800 (PST) (envelope-from owner-freebsd-afs@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18683; Thu, 12 Feb 1998 14:47:41 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA11282; Thu, 12 Feb 1998 15:47:27 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd011248; Thu Feb 12 15:47:21 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA02917; Thu, 12 Feb 1998 15:47:10 -0700 (MST) From: Terry Lambert Message-Id: <199802122247.PAA02917@usr02.primenet.com> Subject: Re: Coda FS: FBSD port done!, but development favors Linux To: rober+freebsd@cyrus.watson.org Date: Thu, 12 Feb 1998 22:47:09 +0000 (GMT) Cc: owensc@enc.edu, freebsd-hackers@FreeBSD.ORG, freebsd-afs@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Feb 12, 98 01:39:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-afs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Our long-term goal is to work with various communities (such as FreeBSD, > Linux) to come up with a generalized authentication extension available to > distributed file systems (such as AFS, CFS) for associating tokens or > priveledges with a set of processes, not just with a UID. Those of you > familiar with AFS will know that if you have two incoming telnets, one can > have rights to the file system while the other does not, depending on > whether you have klog'd or not. There are numerous reasons for having > such a service -- for example, it would be nice if daemons running as root > did not have access to the same file system as a root shell elsewhere, > etc. Not the least of which is UNIX NetWare and SMB client filesystems, and file and directory level security (password protection). This is a general issue with credentials on UNIX systems, and on the implementation of connection level authentication instead of transaction level authentication in general (protocols developed for single user machines typically do not consider the problem of how to proxy multiple credentials over a single connection). A general implementation requires the ability to have the kernel call back into user space to ask the user questions, like "what is your SMB password?". This is, in fact, the job of a "session manager". A session manager can operate in three modes: 1) Preload. Credential information is preloaded. The session manager registers, and accepts and responds to kernel requests for authentication on behalf of the user. Preload is typically used on async terminal type connections, including telnet, where there is no way for the kernel to establish a covert channel to the user, out of band, to ask for the credential information. Preload does not work well for interactive extension. For example, a mounted SMBFS in the UNIX filespace hierarchy. For old mounts, the mountpoint traversal uses the preloaded credentials. For mountpoints not previously traversed, the information is not available, and the traversal fails for reasons of non-authentication. The Windows 95 and Windows NT Workstation "password cache" is an example of a preload session manager, as is the LANMan "NET LOG" command. 2) Use interaction. Credential informormation is only requested when an action that requires credential information is first attempted. The programs which make first attempts, like the mount program, transiently register with the session manager as an "interactor". They then attempt the action, which causes the kernel to call back to the session manager, and the session manager to call bac to the interactor. Use interaction is typically used where there are formal events that preceed additional interaction requiring the credential. The most obvious interactors would be the mount programs for NetWare and SMB mounts, which would request the NetWare or SMB credentials from the user at the time they were executed. The session manager would cache the information for future reference. Use interaction does not work well with procedurally unwrappered events, like mount point traversal or per file or directory access controls. This is because the shell built-in "cd" can not function as an interactor, and neither can the systemcalls chdir(2) and fchdir(2) function as interactors, so support for legacy programs is impossible. The Windows 95 and Windows NT Workstation "Network Neighborhood" browsing, when descending into a new share with access controls, *approximates* use interaction (the session manager prompts you, but it could as easily be the network browser prompting you). 3) Event interaction. Event interaction means that, when an OS event occurs that requires a credential, the session manager requests the credential from the user on behalf of the kernel via a covert channel. Use of a "covert channel" means that the signalling between the user and the session manager can not be "in band". For example, a user on a Televideo 925 terminal can not be contacted via a covert channel. This is because of the fact that to contact the user will destroy information on the users screen, and that the user may be unable to recover the destroyed information because the application may have been written in such a way as to to not expect to be interrupted. As a result, the application sstate can not be recovered. Even if you can suspend the application and resume it (so that any read it has posted does not interfere with your session manager's read request), the interaction is asynchronus, and prone to user confusion. The most likely candidates for a covert channel are, in order of ease of implementation: o An X session manager associated with the xdm process o A session manager on the console that uses the fact that the system console memory can be read to save and restore application state. o A session manager built into the "screen" program that can use the "screen" program's virtual terminal backing store to save and restore state. o A VMS-style broadcast mecahnism. Like transparent printing, this requires a finite state automaton in the tty driver so that the kernel can know that the terminal is not in the middle of processing an escape sequence when it triggers. Alternately, all applications must be written to ensure atomic escape sequence writes (an unrealistic goal). Typically, you would combine methods #1 and #3 to provide the user with a password cache facility, ala Windows 95. > It seems like freebsd-afs might be a better location for this discussion, > however -- at least until we figure out what the requirements are? Take a look at previous SMBFS discussions on the -hackers and -current lists. This is a well-worn issue. The soloution is well known, but not implemented. At a minimum. for SMBFS, we need at least #2 and per user "mounts". For file and directory level passwords, we need at least #1. A minimal spanning implementation is #1, and a full implementation could wait until later (if it had to). You can look at these discussions in the list archive accessible through www.freebsd.org. I would suggest a common session manager callback API; basically, the session manager would select on a session managemement fd, and when the kernel had requests, the select would come true and the manager would read from the fd. This would let the session manager handle things in the forground as well (like an X user clicking about in its user interface). I would also suggest that a formal standardization of credential implementation take place, so that session managers for a given UNIX credential would configurably be shared and/or share information with other UNIX credentials (ie: one session manager per credential OR multiple session managers that share information between them, such as when one user logs into two X terminals). I'd be happy to help on a reference implementation, though I don't really want to bite the bullet on the X requester; my main interest is for an SMB client FS and file and directory level security. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe afs" in the body of the message From owner-freebsd-afs Fri Feb 13 08:05:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12801 for freebsd-afs-outgoing; Fri, 13 Feb 1998 08:05:04 -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 IAA12740; Fri, 13 Feb 1998 08:04:50 -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 KAA13619; Fri, 13 Feb 1998 10:50:16 -0500 (EST) Date: Fri, 13 Feb 1998 10:50:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Terry Lambert cc: owensc@enc.edu, freebsd-hackers@FreeBSD.ORG, freebsd-afs@FreeBSD.ORG Subject: Re: Coda FS: FBSD port done!, but development favors Linux In-Reply-To: <199802122247.PAA02917@usr02.primenet.com> 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 On Thu, 12 Feb 1998, Terry Lambert wrote: > > Our long-term goal is to work with various communities (such as FreeBSD, > > Linux) to come up with a generalized authentication extension available to > > distributed file systems (such as AFS, CFS) for associating tokens or > > priveledges with a set of processes, not just with a UID. Those of you > > familiar with AFS will know that if you have two incoming telnets, one can > > have rights to the file system while the other does not, depending on > > whether you have klog'd or not. There are numerous reasons for having > > such a service -- for example, it would be nice if daemons running as root > > did not have access to the same file system as a root shell elsewhere, > > etc. > > Not the least of which is UNIX NetWare and SMB client filesystems, and > file and directory level security (password protection). > > > This is a general issue with credentials on UNIX systems, and on > the implementation of connection level authentication instead of > transaction level authentication in general (protocols developed > for single user machines typically do not consider the problem of > how to proxy multiple credentials over a single connection). > > A general implementation requires the ability to have the kernel > call back into user space to ask the user questions, like "what is > your SMB password?". > ... Terry, Thanks for your response. My thoughts on the issue had been somewhat limited to a smaller scope -- those services specifically required for Coda, for example. One issue I have not yet resolved in my mind is how appropriate use of credentials will be determined. This becomes an issue in the case of multi-realm Coda (or AFS) -- which credentials do you present to a realm? - Multi-realm AFS allows remote realm identities to establish a local identity for the purpose of being included in local ACLs, etc. Multi-realm AFS also allows anonymous, unauthenticated access (for situations where a user does not have a local identity). How does the credential manager know which identity(ies) to offer? In the case of Coda/AFS there are some clear possibilities: 1. If you have an identity for realm (x) in your credential cache, provide that to the remote realm. 2. If you have an identity for another realm (y) but not for the realm itself, use that identity. 3. If you have no identity, attempt unauthenticated access. The problem occurs primarily because Authorization requires first Authentication, so you cannot do much with authorizing anonymous users (other than treat them as a class, which is allowed in AFS). Cross-realm tokens in AFS do complicate things. I'd like to try and come up with a fairly clean general solution to that problem in Coda, and am currently still in the brain-storming stage (this is especially the case since there ios no multi-realm Coda as-yet :). The end solution is really to have the user indicate how any credentials may be used, and have a strictly followed set of rules for how they can be used. Especially in the case of SMB/etc it is desirable to avoid sending the wrong credentials to the wrong place :). If a general-purpose credential manager is available, the user must be able to determine how the credentials are used. This is especially true in the event that a password is provided as a credential (as opposed to a token or authenticator). I might wish to indicate a credential was for use with Coda, or for IPsec, etc. This is further complicated by the fact that Coda and AFS both have a user-land daemon, Venus, which actually manages the connections. It maintains a pool of RPC bindings for each authenticated identity (for parallelism). Currently it uses the UID of the process (provided to Venus by /dev/cfs0) to determine which credentials to use (and which bindings, if currently available). In the new arrangement, presumably user-level Venus would (somehow) be provided access to the credentials associated with the PAG of the requesting process, but only those credentials provided for use with Coda. How would one indicate that the Coda-related Venus processes were allowed to have access to those credentials? Possibly through using a specific UNIX uid/gid mapping to protect access to /dev/cfs0, and then a mapping to allow "Coda" credentials to be passed to the Venus userid? Is the PAG an appropriate mechanism for grouping credentials with processes? What are the semantics for a PAG? The ones discussed thus far are similar to process-group semantics in many ways: - By default, a process is in the PAG of its parent - A process may choose to create a new PAG, of which only it is initially a member. - Any process may adjust the credentials of the current PAG (is this desirable?), including destruction of all associated credentials. - PAG is preserved across setuid binary execution, as well as the setuid syscall Presumably a source of PAG credentials could be Kerberos, etc. Both the kernel and user-processes might need access to these credentials. These processes might or might not be in the PAG of the process requiring the service. Examples of interesting processes: SSH Client -- similar to retrieval of user's private key (storing it in a credential manager might be more useful than in a file in their home directory -- especially if they require tokens to get to that file :). The SSH client would be in the PAG. Venus -- to access files using the identity of the user, it would require access to credentials provided specifically for that task, but no other muck up credential-handling. IPsec -- as user-to-user authentication is not forbidden by IPsec semantics, but the kernel provides IPsec services at the protocol level. As such, the kernel might need access to the user's IPsec credentials. SMBfs -- this might be implemented as a user-level process (such as Venus), or as a kernel-level service. In either case, it would have to match credentials for NT domains, specific servers, etc. This is just part of the initial hash-through of the issue thus far. I will go take a look at the back-archives from the smbfs discussion later today. Thanks, 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/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-afs" in the body of the message From owner-freebsd-afs Fri Feb 13 18:35:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06350 for freebsd-afs-outgoing; Fri, 13 Feb 1998 18:35:19 -0800 (PST) (envelope-from owner-freebsd-afs@FreeBSD.ORG) Received: from ricercar.coda.cs.cmu.edu (ASYNC14-8.NET.CS.CMU.EDU [128.2.188.62]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06334; Fri, 13 Feb 1998 18:35:11 -0800 (PST) (envelope-from braam@cs.cmu.edu) Received: from localhost (braam@localhost) by ricercar.coda.cs.cmu.edu (8.8.7/8.8.7) with SMTP id TAA05276; Fri, 13 Feb 1998 19:39:00 -0500 X-Authentication-Warning: ricercar.coda.cs.cmu.edu: braam owned process doing -bs Date: Fri, 13 Feb 1998 19:38:59 -0500 (EST) From: Peter Braam X-Sender: braam@ricercar To: "Matthew N. Dodd" , Eivind Eklund , hackers list FreeBSD , braam@cs.cmu.edu, 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: Coda [ was: RE: Coda FS: FBSD port done!, but development favors ], Linux 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 Hello all, To introduce myself, I suppose I should say that I am more or less in charge of the Coda project now. So you can take this as a bit as our official view (fwiw). First of all: THANK YOU FOR YOUR INTEREST IN Coda! I felt it would be a good idea for me to respond to the flurry of messages coming from the FreeBSD community. I try to read all of them but can't really reply right away to everything. A) Re: Coda FS: FBSD port done!, but development favors Linux ------------------------------------------------------------- This is NOT AT ALL TRUE. I can see how what I said evolved into this statement, here is what I really said (or believe I said): a) the FreeBSD port (2.2.5) is _almost_ done. We have a working client, the servers are playing up a bit. b) we DO NOT FAVOUR LINUX. It is true that our servers start up 3 times faster on Linux than on NetBSD 1.2. It is also true that a fairly large group of students from Yale is helping to implement Linux specific Coda optimizations (which FreeBSD may already have). It is also true that some NetBSD people have been sending me very unfriendly messages about Linux. Finally it is true that a lot of high quality FreeBSD/NetBSD messages have been sent to the Coda lists -- that's great. Please join the linux-coda lists (see www.coda.cs.cmu.edu). Don't engage in OS wars, or irrelevant criticism of other free or commercial operating systems -- if it happens I'll start moderating the list. We are just interested in Coda. The list will probably be renamed reflect its NON-linux status. We hate OS wars, and want Coda on all platforms particularly the free Unices and the Windows platforms -- all using one code base. A lot of work remains to be done -- many features are not reliable enough, performance and scaleability, useability and administration can be much improved. Many good things come out of trying to just use Coda. Use our test server, or set up your own. If you happen to have time, by all means send us patches. Mail about difficulties to the list -- we'll try to help. c) YES, we are making a "CURRENT release for FreeBSD". Bob Baron chose to first do 2.2.5 and will soon start on current (vz. when the server works and some other minor kernel issues have been sorted out). I hope the kernel code of this release can be accepted for inclusion in the FreeBSD kernel. B) Inode calls. --------------- 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. 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). 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-afs" in the body of the message