Re: keyring manager

[Jon Nettleton <jon nettleton gmail com>]

On Thu, 2007-03-15 at 11:08 -0400, Dan Williams wrote:
> On Thu, 2007-03-15 at 10:42 -0400, Jon Nettleton wrote:
> > On Thu, 2007-03-15 at 09:52 -0400, Dan Williams wrote:
> > > On Thu, 2007-03-15 at 08:46 -0400, Jon Nettleton wrote:
> > > > On Thu, 2007-03-15 at 08:11 -0400, Dan Williams wrote:
> > > > > On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote:
> > > > > > I'm sure this has been asked before.  Are there any plans to make
> > > > > > Network Manager's use of the keyring optional?  I understand the
> > > > > > security issues, and certainly NM should default to using the keyring.
> > > > > >  But an option to turn it off would, I'm sure, be appreciated by many.
> > > > > 
> > > > > Nope!  As you say, that's a security issue.  Instead you'll be able to
> > > > > "publish" a configuration to system settings so that it's available to
> > > > > everyone on the system (or just you if it's single-user) and therefore
> > > > > available for NetworkManager to use when the computer boots up, not just
> > > > > when you log in.
> > > > 
> > > > Random curiosity.  Waht is the planned mechanism for storing the
> > > > published WEP/WPA keys?  I haven't found any documentation online, other
> > > > than the preferences are getting published in the main gconf repo.
> > > 
> > > Well, given the fact that the keys have to be available to the system
> > > when there is no possibility of user-interaction for a
> > > password/passphrase, any necessary authentication information (keys,
> > > certificate passphrases, VPN passwords, etc) will be stored unencrypted
> > > in files owned by and r/w only by root, at least in the stock
> > > implementation.  That's about as good as you can get, since if somebody
> > > has root on your box you're pretty much screwed anyway.  That's the
> > > price you pay not sitting in front of the box when you want the network
> > > to come up.
> > 
> > I find it somewhat amusing that with all the badmouthing of the ifup
> > scripts storing the encryption keys unencrypted on the filesystem, we
> > are right back to the same place.  But like you said above, that is just
> > how it has got to be.  Will this mean that NetworkManager will be
> > accepting patches to extend compatibility with existing network profile
> > storage systems?  I have had a "Configuration" daemon and patches I have
> > been using for months now, that I didn't release because everyone seemed
> > so down on the ideas.
> 
> Perhaps.  The problem is that distros have all sorts of configuration
> littered all over the system in different formats.  The info-daemon
> needs to deliver the information to NetworkManager in a fairly specific
> format, but it doesn't really matter where it gets that information.
> 
> I'll give you an example of the problem on Fedora.  Fedora's network
> config lives in /etc/sysconfig/network-scripts, and each device gets an
> 'ifcfg-X' file that for wireless devices lists things like device type,
> MAC address, and wireless settings including encryption key, SSID, etc.
> 
> That's totally unsuitable for NetworkManager, because it allows only one
> connection to be tied to the wireless device.  It's just not flexible
> enough of a format to contain multiple connections for different
> wireless networks.  So for Fedora, I don't think we'll use
> the /etc/sysconfig/network-scripts files at all, and we'll have to
> create a more flexible format.

This is an interesting misconception.  You can name those scripts
ifcfg-whateveryouwant and they will work fine.  The device variable that
is specified inside the file is really what is important.  Way back when
like 4 years ago, pre-NetworkManager I actually had patches to ifup that
allowed wireless scanning and choosing the proper ifup-device_essid file
as a config.  All configurations were configured and managed through
system-config-network.  

> 
> We may need to have 'backends' for each distro in the system-wide info
> daemon, sort of like we have now for the core NM daemon.  Or
> runtime-loadable GModules or something.  Or, each distro can write their
> own system info-daemon to parse their specific network config into the
> format that NM requires over D-Bus.

So this is how I wrote my hack Configuration/Info daemon, whatever you
want to call it.  I don't actually read any of the scripts directly.  I
have tool similar to ip/ifconfig or iwconfig that that runs on the
commandline and talks over dbus to the info daemon.  This makes it
really easy to adapt whatever backend you have without having to rewrite
code all the time.  As a system administrator it is also nice to be able
to manipulate ip configurations without the need to have a gui.

> 
> > > Technically the info-daemon for whatever desktop you're using will be
> > > able to store the keys as it sees fit.
> > 
> > I would hope that we could move to a point where a system smart card
> > could be used to unlock an encrypted storage system.  It isn't perfect,
> > but you know that if you ditch a hard-drive or old computer your stuff
> > your secrets will be a little more secure.
> 
> Yeah, that would be nice.  And if the distro supports that, I'd expect
> that the info-daemon could easily be extended to work with that.
> 
> Dan
> 
>