Date: Fri, 13 Feb 1998 10:50:16 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Terry Lambert <tlambert@primenet.com> Cc: owensc@enc.edu, freebsd-hackers@FreeBSD.ORG, freebsd-afs@FreeBSD.ORG Subject: Re: Coda FS: FBSD port done!, but development favors Linux Message-ID: <Pine.BSF.3.96.980213101454.12337F-100000@fledge.watson.org> In-Reply-To: <199802122247.PAA02917@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980213101454.12337F-100000>