Solaris ssh pam_krb

[Nicolas Williams]

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 
> <Nicolas.Williams at sun.com> 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
--