Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> On Fri, Mar 31, 2006 at 04:56:27PM -0500, Jeffrey Hutzelman wrote:
>> On Friday, March 31, 2006 03:44:57 PM -0600 "Douglas E. Engert"
>> <deengert at anl.gov> wrote:
>> >>                          The caches I see are tiny,
>> >
>> > Unless the the KDC is Windows, and the tickets have PACs.  A tgt is
>> > 2000 bytes, but could go as high as 14k.
>>
>> Even 14k is still tiny.
>
> If you're using Kerberos V for authentication in remote administration
> protocols and have, say, 30,000 hosts to look after

Then you're atypical, and can't use an in-kernel ccache, because the kernel 
is going to limit your ccache use to, say, one page.


> Sorry, tickets don't belong in the kernel.  Even with pageable kernel
> memory, and proper accounting.

So, where do you store them now?  /tmp ?



>> Even if you store tickets and other credentials in user land, there are
>> still kernel-mode applications like filesystem drivers that need to know
>> not only what PAG a process is in, but also which PAG's map to the same
>> application-level identifier.  If a user creates a new PAG to break the
>> association with a single application (say, Kerberos ccaches), then it
>> is  _not_ OK for other applications to be forced to re-fetch cached data.
>
> Ok, this is such an argument.  I'd like to have some idea of what
> kernel-land applications actually would need PAG facilities directly, as
> opposed to indirectly through upcalling to daemons like gssd.
>
> NFS clients don't need direct PAG access -- see gssd.

Does your NFS client do caching?  How does it decide when it is OK to allow 
a process to access cached data?  I suppose the answer could be "based on 
the uid, gid, and groups", but UID/GID namespaces might be different 
between client and server.


> NFS servers don't either -- same thing.

I don't think NFS servers need to know anything about PAG's, except that 
each nfsd thread may need to be in its own PAG, if your nfsd communicates 
credentials to exported filesystems by changing the credentials of the 
server process, as Linux does.


> What about CIFS clients and servers?

I haven't a clue.

> AFS?

AFS servers run in user mode, where a fileserver belongs.  Talk about 
extraneous complexity in the kernel!

AFS clients cache both file contents and metadata.  When a process wants to 
access a file which is in the cache, the cache mangager determines whether 
the request is permitted by examining cached information about what access 
rights that process has on that file.  This information is indexed by PAG, 
so different processes in the same PAG share the same cached access rights. 
Without this, the cache manager would have to make an RPC for _every_ file 
access to determine whether the access should be permitted, which would 
sort of defeat the purpose of caching.

Similarly, connections to fileservers are shared among processes with the 
same credentials.  If a request does require going to the server (for 
example, reading data not in the cache), then we need to find a cached 
connection with the right credentials, if there is one, and again, cached 
connections are indexed by PAG.


> What about KINK?  Would you implement KINK in the kernel?  Or in
> user-land?  IKE in Solaris is implemented in user-land, why should KINK
> not be implemented in the same fashion?

I assume you would do KINK in user-land, same as with IKE.


> What about kernel-land TLS (RFC2712?  Ick) accelerators, do they need
> direct PAG access, or can they afford to upcall to resolve the location
> of relevant certs/private keys/tokens?

I assume a kernel-land TLs accelerator would depend on the user-mode 
process for the initial handshake, and be handed the relevant keys.  So, it 
wouldn't need long-term credentials, but it _would_ need the keys used to 
protect the connection.  However, that data is per-channel, not per-PAG, 
and so not relevant to the current discussion.

> What other kernel-land applications can you think of or imagine that
> fundamentally needs direct multi-application PAG support in the kernel
> and can't upcall?

- Encrypted (local) filesystems
- Kernel-mode ticket caches
- iscsi?

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.

-- Jeff