Re: keyring manager

[Dan Williams <dcbw redhat com>]

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.

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.

> > 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