On Tue, 2005-07-26 at 18:20 -0400, Derek Atkins wrote: > Colin Walters <walters verbum org> writes: > > >> Because I don't want my kerberos password cached.. Anywhere.. Anytime. > > > > What is the threat, exactly? Laptop theft? In that case, since the > > password is only cached in memory, as soon the thief reboots the laptop, > > the password is gone. Note also that we could clear the password from > > the memory cache on suspend; when you unsuspend the screensaver comes > > up, and we regenerate the memory cache from that. > > Um, if it's only cached in memory then that doesn't solve the bootup > problem. You're still stuck if you bootup on a wireless network. You > can't login because you're not on the network, and you can't get on > the network because you can't login. If the creds aren't cached on > disk, then you lose. It does seem to me the very first time you log in you need to be on the network, in order to get the credentials cached. Maybe the credential caching is the wrong idea entirely, and we should drop pam_krb5 from the gdm auth component and instead just use it in the password section (so you get local password changes when you change your kerberos password). Then to get the ticket you use krb5-auth-dialog. > What is the threat? Laptop theft is certainly high on my list. My > tickets are only valid for a short period of time. My password is > valid until I change it. Sure, and I think we can address the laptop theft threat by clearing the memory cache on suspend, and logout. > So doing it your way is no more secure.. In fact, I would argue it's > even LESS secure, because the malware could read out the daughter's > passwords whereas in my scenario it couldn't, because network > passwords would be write-only from nm-applet! So, my approach is even > more secure than yours against user-installed malware. That's a good point; but I think we should still be concerned about integrity and not just confidentiality; i.e. daughter's malware shouldn't be able to overwrite/destroy the VPN/wireless configuration of the father. As a side note I would like to get GConf enhanced to act as a SELinux "userspace object manager"; what this means is it would do access control based on the security context of the process requesting a preference key, so we could e.g. ensure that only nm-applet can read/write the wireless config keys and prevent a compromised firefox from accessing them. This way we get equivalent security to what you were suggesting of having the keys be stored in a write-only fashion to the user session. Also, having the wireless/VPN config system instead of per-user makes it more difficult to fix the bug (and it is a bug, IMO!) that when the father logs out the system is still on the VPN.
Attachment:
signature.asc
Description: This is a digitally signed message part