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