>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.
I agree that you can design a user-land scheme that's a lot better than a simple file, but there are enough tools available for grovelling through a user-level daemon's memory that I would prefer to have something better. Again, it's not 100%, but it's all a matter of degree. >If we cannot design a suitable user-land ccache system then we need to >fix the OS. Hasn't this whole discussion been about how hard it is to get the vendor to fix their OS? :-) >I've seen *huge* ccaches (see a thread here some four years ago about >locking and inefficient ccache I/O). I don't doubt they exist ... but like I said, make a default limit that's adjustable. That's really just a SMOP. If the space really concerns you, I guess putting the ticket in userspace and the session key in the kernel would be fine (which I guess was one of your earlier suggestions). I don't view any of these things as showstoppers. >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). All I can say is that what operating systems provide today is NOT enough in a modern security environment; I have learned that the hard way. Google for "appcap" to see the sort of thing that we're facing today. To be fair, a PAG/kernel thingy would not be enough to protect against appcap, and currently it only works on Linux so it's not relevant to Solaris. I have a relatively simply scheme that protects against appcap, so it's not really my point; my point is that today we're getting more sophisticated attacks, and I think we're going to need more sophisticated kernel support to keep things like Kerberos credentials secure. I could easily envision a program to grovel through a userspace daemon's memory looking for a Kerberos credential cache. That's really what I'm interested in protecting against. Is that worth the additional cost of placing the whole ticket cache in the kernel? Well, I guess that's where we disagree. --Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos