Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 03:44:57 PM -0600 "Douglas E. Engert" 
<deengert at anl.gov> wrote:

>
>
> Ken Hornstein wrote:
>
>>> Why store tickets in the kernel, what's the point?  Presumably you'd not
>>> want anything other than TGTs in the kernel, so where do you cache
>>> service tickets?  Or do you want all tickets in the kernel?  (Presumably
>>> in pageable, accounted memory...).
>>
>>
>> Well, actually, I'd rather have the whole ticket cache in the kernel.
>> I have personally seen attacks on the current file cache; right now we
>> don't use a file cache, but the scheme we do use has some issues.  One
>> thing we were planning on doing was use the Linux kernel keyrings
>> if/when they become suitable ... but of course those would only work
>> under Linux.  I know that putting the ticket cache in the kernel isn't
>> 100% protection, but I think it's the best we can probably do on a
>> multi-user Unix system.  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.
Charge the space against the user, or the PAG, like Linux keyrings do.
In fact, now that I think about it, a similar approach can be used for 
kernel PAG->appid mappings.  Simply impose a limit on the number of such 
mappings which can be associated with any given PAG.  Each mapping is 
nothing more than an application type and application ID, both of which are 
integers.  You need an mapping between application type names and their 
ID's, but _that_ can be managed in user space.  And if you find you need 
more apps per PAG, then change the system parameter - it doesn't even have 
to require a reboot, depending on how you allocate the storage.

But the issue of ticket storage is tangential to the question of PAG 
management.  In fact, as far as PAG management is concerned, ccaches are 
just another application, whether their contents are kept in the kernel or 
in some user-mode daemon or whatever.

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.




-- Jeff