Solaris ssh pam_krb
Ken Hornstein
kenh at cmf.nrl.navy.mil
Fri Mar 31 17:17:10 EST 2006
>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
More information about the Kerberos
mailing list