On Fri, Mar 31, 2006 at 07:07:43PM -0500, Jeffrey Hutzelman wrote: > On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams > <[EMAIL PROTECTED]> wrote: > > >>- Encrypted (local) filesystems > > > >Orthogonal to PAGs. The kernel needs to know keys for encrypting > >objects/filesystems, but access controls are as normal (ACLs, mode bits). > > > >We're planning on per-filesystem (think ZFS) keys, too, so there's no > >per-"session" keys to worry about. > > I was thinking in terms of different users' files being encrypted with > different keys, which would require the kernel to track keys on > approximately a per-PAG basis.
PAGs are not persistent across reboots, so, no, we can't do that. Also, per-file keying is too complex; we may do per-file (object) key derivation, but not per-file keying. > >>- Kernel-mode ticket caches > > > >Circular logic. > > No, it's not. We already established that ticket caches are separate from > PAG management. If you want kernel-mode ticket caches (and some of us do), > then you need kernel-mode access to PAG->appid mappings. "Kernel-mode ticket caches" is not an application. An application is something that would use them. > >>Maybe PAG-based authorization for things like X server or ssh agent > >>connections. In reality, I bet those can be handled in user mode, > >>though an application like that would require some trusted entity for > >>allocating ID's which are unique across the system. > > > >Authorization by PAG requires making changes to lots of things in the > >kernel (e.g., two procs w/ equal cred_t's but for different PAGs should > >not be allowed to trace each other w/o special privilege). > > Well, yes, and in the long run, you'd want that even if there were no > kernel-mode users of PAG's. Right, but in the AFS model PAGs don't provide for access control (though user-mode applications could use PAGs for access control given APIs like door_cred(3DOOR) and getpeerucred(3C)). I think that is a useful simplification. I'd like to keep it. > But I considered the filesystem-driver applications critical. An upcall > for every file access is just not going to be acceptable performance-wise. I don't think you want per-file keys. Do you really want to interact for every file you open? Or every directory? (Never mind POSIX hard links.) Per-filesystem is enough, and PAM modules can "log" you into your filesystems. (With ZFS at the limit you can have every directory be a filesystem, but it'd be madness to have different passwords/tokens per-directory!) > Really, I think the introduction of a new process to keep track of > PAG->appid mappings is just silly. The number of PAG application types in > the system is likely to be quite small, and the mappings themselves are > small as well. Why not just store them in the PAG structure and be done > with it? I'd rather keep the kernel-side of things simple. I do care not to preclude interesting applications, but so far I've seen no real or imagined application that needs more than simple PAGs kernel-side. The encrypted filesystem argument holds no water, IMO. Ken H. agrees that all other kernel-side applications can upcall to do PAG->stuff resolution if need be. What's left? Also, note that we can make the API hide all the relevant details, such that if we ever need multi-app PAG associations in the kernel we can move the whole implementation from user-land into the kernel. Which leaves the argument of where the complexity belongs. You know where I stand on that :) Nico -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
