Re: keyring manager

[Dan Williams <dcbw redhat com>]

On Thu, 2007-03-15 at 11:35 -0400, Jon Nettleton wrote:
> 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

Huh.  That certainly does make more sense :)  So they might be able to
fit in somewhere after all.  I'm still unconvinced they could be used as
a carrier for all the config info NM would put into them, plus we'd
still need a place for VPN and whatnot.  We'll see.

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

I don't think I quite understand the architecture here.  Does the
'similar to ifconfig' tool just ask the info-daemon for the config and
then run the script to activate the config?

In the NM info-daemon case the sysadmin would just make the changes,
either to text files, to LDAP, to GConf, install an RPM, whatever, and
the info-daemon is responsible for noticing those changes and telling
NetworkManager that an update occurred.

The point here of course is that the D-Bus API is the common glue,
doesn't matter what's on the other side as long as it can speak that
dbus api.

Cheers,
Dan

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