Date: Thu, 12 Feb 1998 22:47:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rober+freebsd@cyrus.watson.org 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: <199802122247.PAA02917@usr02.primenet.com> In-Reply-To: <Pine.BSF.3.96.980212133040.1730A-100000@trojanhorse.pr.watson.org> from "Robert Watson" at Feb 12, 98 01:39:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802122247.PAA02917>