Solaris ssh pam_krb

[Ken Hornstein]

>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