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 -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos