Re: 2 questions...

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.

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.

>> Who said anything about requiring users to "SysAdmin type things"?  I 
>> never did.
> You said:
> "Meanwhile, storing network passwords in a place that only root/NM
> can get to it?"
> I interpreted that as requiring a root password to change.

Nope.  The NM service runs in the root context.  It can store data
wherever it wants in a way that only "root" can read it.  That is
perfectly sufficient for my wants and needs, and does not require
anyone to type a root password or do any sysadminy-like things to

>> I've ALWAYS said that NM should remember the preferences globally instead of
>> storing them in nm-applet.  
> I don't think we want to do that as we do want to support the multiuser
> laptop case.  Imagine a family with a father and a daughter.  The father
> takes the laptop to work and logs into the corporate wireless network
> and VPN.  The daughter wants to use the laptop at home.  The daughter
> really likes to install lots of random software from the internet.
> If the networks are per-user, malware installed in the daughter's
> account can't email the father's network passwords and VPN configuration
> to the world.  So I think we should keep strong separation between users
> wherever possible, and in this case, we can.

First, I'm really only talking about 802.3 and 802.11; I don't really
care about VPNs (at least in the context of auto-connect).  Indeed, I
don't think NM will autoconnect to VPN in any situation, so let's
ignore that for now.  I'm still perfectly happy with VPNs being

Next, let's examine your scenario.  Daughter installs software..
Well, let's assume sweat-pea doesn't know the root password, so
anything the malware could do it could only read the things that she
could.  The network passwords would still be owned by a root-only
config, so which the NM service could read them, sweat-pea can't.  So
the malware running as sweat-pea can't get the network passwords.  So
your threat is still averted because the passwords aren't available to
the malware.  Indeed, the passwords should be "write-only" from
nm-applet into NM.

Now, also keep in mind that if Daddy was connected to his work VPN and
then logged out without disconnecting, the VPN will still be active
when Daughter logs in.  NOW the malware has access to the VPN!

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.


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord MIT EDU                        PGP key available

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]