Shawn M Emery wrote: > Nicolas Williams wrote: >> [Removing psarc-ext since we're now dwelling on design.] >> >> On Tue, Jan 20, 2009 at 03:54:47PM -0700, Shawn M Emery wrote: >> >>>> Either remove those words, add the missing facility, or block on a >>>> future case that should provide it. >>>> >>> I purposely specified "will allow", "support", and "helpful" in regards >>> to sessions. As the applications still have an interface for designing >>> specific forms of session. If the scope of the project is to define a >>> system level or SPI then I believe that this warrants a separate case as >>> it impacts many applications and not necessarily specific to Kerberos. >>> >> >> But telling people to use KRB5CCNAME now will make life more difficult >> later. Also, not solving the NFS problem doesn't get you far in solving >> the cron process problem. >> > > Actually I'm solving the cron problem with the CCAPI by creating a > mechanism for storing multiple default credentials. This instead of > using some file naming scheme using file ccache types. > >>>> Without a kernel-side hook these credentials will not be available for >>>> secure NFS on a per-session basis. Therefore this is insufficient and >>>> incomplete. >>>> >>> Currently, gssd uses the principal to map to the local user. I believe >>> >> >> No, it uses the UID of the process that triggered the upcall. That's >> already the local user, and then it does a setuid() (or, rather, fakes >> one). >> > > Ah, I see the uid messaging in the kgss_init_sec_contexts up-calls now. > >>> that this is still useful and could be used in order to lookup a special >>> CCAPI entry and to fall-back to file stores created by initial login. >>> >> >> That's not an improvement over the current situation, though the CCAPI >> > > The current situation not being able to do this (at least through gssd) > vs actually being able to do this? > >> may well have other benefits (e.g., perhaps it has better performance >> when the ccache is large and there is contention for it -- does it?). >> > > Well, the MIT implementation does maintain state for iterations. > >>>>> Yes, as it affects the FMRI, but I haven't done away with gssd yet :) >>>>> >>>> Why should the FMRI change? >>>> >>>> >>> If gssd goes away then the FMRI goes from being defined to that which is >>> not :) >>> >> >> gssd is not going away. Its FMRI therefore is not either. >> >> To begin with there's the gssd for the system itself in each zone. That >> MUST have its own FMRI. Then there will be the per-user gssd, which is >> a slightly different story. >> >> gssd could fork() the per-user gssds, and each per-user gssd should >> setuid() to the correct UID (not a fake setuid(), but a real one), just >> like per-user nscd does. Having PAM start per-user gssds might work >> too, just be careful to use ctrun(1) to make sure they are restartable, >> and, of course, they have to register with the system gssd or otherwise >> fattach() a door where kgssapi might find it (in /var/run, not in /tmp). >> >> One nice thing about the per-user nscd model is that the per-user daemon >> instances can be started and reaped as needed. That's fine for gssd, >> not so fine for ccd unless ccd is restartable without losing track of >> the cached credentials. >>
You are still hung up on the UID rather then a session job or some other form of separation of processes on a machine. The UID (other then if is is 0, is really used as a credentials to access local files systems. The main issue may be that caches are normally stored in a local filesystem using UID for ownership and therefore accessible to an process running under the UID that owns the cache. This might be solved if the caches are owned by root, not be uses, or are stored in the kernel. So having a gssd for each UID might not be the issue, the issue is having the cache stored where is is accessible to only the process that "own" it. Good to see you are talking about PAGs below! The AFS PAG in effect does this, by storing the AFS tokens in the kernel, and a process is in a PAG. A process can start a new PAG but has no credentials. Credentials can be obtained by using existing credentials, which in AFS case, is via the aklog program, that uses Kerberos, where the cache in a file is owned by the UID. But once the AFS token is created and stored in the kernel, it can only be changed by processes in the same PAG. pam_afs_session is used by login or sshd to create a PAG and to call aklog to get the token using delegated credentials. > > This is one of the debates, whether there is a backing store of the > credential cache or keeping the store in memory only: > > disadvantage (memory only): > increased memory resources > no recovery from daemon restart > > advantages (memory only): > performance related: > no encryption of store on disk > no re-forking of process > if daemon crashes, should be considered a bug > >> Some of these are implementation details, but some are not. For >> example: what starts the per-user gssds is an important architectural >> detail. >> Requiring a per-user gssd is only needed if you continue to store caches where access is controled by UID. Please consider having the cache owned by root or in memory to avoid useing UID. > > I don't envision them being started by the user or administrator manually. > >> So is where the doors live, if they are fattach()ed, though the actual >> door names would likely be simple implementation details. E.g., putting >> well-known/guessable door names in /tmp won't do. Putting them in >> /var/run requires a privileged process to create the right directory >> structure. >> > > I wasn't looking at storing the door files in /tmp and the initial login > processes are already running as a privileged process as they have to > compare passwords in shadow files, etc. So if we want to iron out the > door file location now, though administrators won't really care, I propose: > > /var/run/ccapi/<uid> > >>>>> http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX >>>>> >>>> That has implementation details, but strongly implies a UI and/or API. >>>> Those missing interfaces need to be described. (Surely the protocol >>>> described in the linked page is not intended for _users_ to execute >>>> through netcat or some such, right?) >>>> >>>> >>> Hmmm, locking down specific things like timing on process reaping might >>> paint oneself in the corner in a requirements document. >>> >> >> If there are things users must do, then those things require UIs. If >> there are things developers might do, then those require APIs. >> >> Simple protocol documentation won't do, and is an implementation detail >> (unless interop with other CCAPI implementations on the same host is >> desired, and it well might be). >> > > Hmmm, using a simple tuple, uid and session id, seems sufficient to me. > As long as the API provides this type of granularity as it was not my > intention to second guess the purpose of the session identifier on an > application basis. > > In the future, an example application using gic_keytab from a PAM module > might specify: > > 'API:Initial default ccache through keytab' > > when phasing out initial auth: > > `API:Initial default ccache` > > which is what Mac OS X uses. When initializing credentials (set_cred) > through keytab via a new PAM module the first session referenced would > be 'API:Initial default ccache through keytab', if failure, the second > would be the traditional 'FILE:/tmp/krb5cc_<uid>' (later phased to > `API:Initial default ccache`). > >>>> How will the daemon know when no long-running processes require it any >>>> longer? >>>> >>> Not to paint myself in corner, x minutes. >>> >> >> That means it could well exit too soon! Or did you mean "x minutes >> _after such and such event"? If so, what event(s)? >> > > The latter, of course, if there is a backing store, then this is not an > option. > Inactivity: in which there is no access to the ccache entry. > >>>> I believe this case is incomplete as it stands. Were I an ARC member >>>> I'd ask you to address these issues and update the materials, else >>>> derail. I hope an ARC member does as much. >>>> >>> I certainly think that the session id SPI is a much needed project, >>> however I don't think that it should be lumped into the CCAPI project. >>> >> >> I didn't say it should be. (Let's call that feature "PAGs" for now to >> avoid confusion.) Good!!! >> >> And let's keep in mind that while PAGs would help solve some of the >> problems you face, they aren't absolutely necessary. >> >> For example, if we had a way to get notifications of "last process >> running under UID xyz exited" then you could keep the ccache of each >> user around for as long as they have bg processes, and you could >> coordinate with cron to detect if there are any scheduled cron/at jobs >> between the time of last user process exit and the time of hard TGT >> expiration, and then decide whether to keep the credentials around and >> keep renewing them. >> > > cron specific credentials will be initialized from a separate module > (application) that is not affected by other processes currently running > on the system, see above. > >> Of course, we don't have such a mechanism. But one can be cobbled >> together if need be, e.g., out of auditing. >> >> Yes, we could add PAGs; see a thread I started last week on >> security-discuss at opensolaris.org. IMO we should, but I'm not telling >> you that this project should wait for PAGs. >> > > I would definitely be interested utilizing this SPI in the future, but > for now the scope was designed to help cron and long running processes. > >>> I can't decide on my own that CCAPI would block on a session id project, >>> but I will certainly argue on both sides. >>> >> >> I propose that you work on what you can now, and that you identify the >> blocking dependencies and prioritize accordingly. >> > > Yes, I'm currently porting the 1.7 alpha code for this (along with some > portions of the Mac related logic, as it is closer than the Windows logic). > >> Per-user gssd is eminently doable _right now_. So take that on first. >> > > I just wanted to complete the CCAPI mech and server portions first. The > session naming construction should not change this portion. > >> CCAPI without any notion of "session" is also eminently doable right >> > > Yes, I see this is as a phased approach. Which reminds me that the last > minute addition of the system krb5.conf::cache_type should not be > specified until the CCAPI is phased with a agreed upon session name > construction. > >> now, but with shortcomings similar to those of FILE ccache today: >> >> - can't reliably detect last reference exit -> no auto-destruction >> > > Those would be separate at this phase (see above), but would need to be > considered as it becomes the default ccache type. > >> - global ccache is needed, so a well-known, per-user location is needed >> > > Yes, as the current default would be FILE with the long-running and cron > using the specific CCAPI store that I mention. > >> - HOWEVER, since this is a daemon to be started by pam_krb5 at logon >> time (i.e., with all zone privileges asserted), you can make sure >> that the well-known, per-user locations for CCAPI daemons are in >> /var/run/... instead of /tmp, and thereby close off one significant >> vulnerability we have with FILE ccaches >> > > Yes, however this has already been addressed for FILE: > > 6691206 pam_krb5's store_cred should always store new credentials if a > previous auth pass was successful > >> (But then, of course, the same sort of fix could be done for FILE >> ccaches: mkdir() /var/run/krb5/ccache/$PAM_USER in >> pam_krb5:pam_sm_setcred() and put the ccache there, and perhaps we >> ought to do something like that too!). >> >> (Or perhaps secure scratch areas in /var/run for this sort of purpose >> ought to be created by pam_unix_cred(5):pam_sm_setcred(), since >> surely Kerberos will not be the last thing needing them.) >> > > I would rather focus on getting CCAPI, given that this is what the > default, eventually, should be. > > Shawn. > -- > > > ------------------------------------------------------------------------ > > _______________________________________________ > kerberos-discuss mailing list > kerberos-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
