Solaris ssh pam_krb

Nicolas Williams Nicolas.Williams at sun.com
Fri Mar 31 17:00:07 EST 2006


On Fri, Mar 31, 2006 at 04:39:57PM -0500, 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;

Which attacks are we talking about?  Attacks on the /tmp/krb5cc_<uid>
scheme?  Yes, that's weak.  But it is absolutely not the case that all
user-land schemes are inherently subject to that sort of attack; in
fact, modern architectures and operating systems provide lots of
facilities, beginning with MMUs and virtual memory, and including lots
of access controls.

If we cannot design a suitable user-land ccache system then we need to
fix the OS.

>                                                           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, so I'm not too
> worried about size.  Make it one of those adjustable kernel parameters.

I've seen *huge* ccaches (see a thread here some four years ago about
locking and inefficient ccache I/O).

And I disagree with your comments about protection.  Kerberos V assumes
local security, and most modern multi-user operating systems' kernels
purport to provide basic local security even to complex user-land
applications (as long as you are not shooting your foot off; don't do
that).

Nico
-- 



More information about the Kerberos mailing list