Re: Bootstrapping

[John Sechrest]

What would happen if the list of hosts that you want to trust
was distributed in some other tool. A mysql database query?
An ldap query? A file with a list of machines?

Would that be better than 
       TrustKeysFrom = ( 10.0.0.0/8 )
       DynamicAddresses = ( 10.0.0.0/8 )


IE:
       TrustKeysFrom = ( ReadFile (/var/mln/TrustedHosts,10000))
       DynamicAddresses = ( ReadFile (/var/mln/TrustedHosts,10000))

Does that help the process at all?

            
                


"Luke A. Kanies" <luke@madstop.com> writes:

 % On Wed, 18 Feb 2004, Eric Sorenson wrote:
 % 
 % >
 % > On Mon, 16 Feb 2004, Luke A. Kanies wrote:
 % >
 % > Hi Luke, thanks for this great post -- My butcherous snippage is
 % > purely in the interest of brevity and should not be construed as
 % > any comment on the parts thus removed.
 % 
 % Not at all.  I'm always appreciative of snippage. :)
 % 
 % > Environment note:
 % > I'm running cfengine2 across about 700 RedHat-7.3 based systems.
 % > It's used primarily for copy: of CVS-controlled files off the
 % > master server, along with a few miscellaneous tasks (post-OS-install
 % > customisation, mostly). The files are various system daemon configs
 % > that change more rapidly than justifies a new RPM version, but don't
 % > require immediate network-wide propagation.  For instance, nsswitch.conf
 % > and printcap are under cfengine control, but password / uid lookups
 % > point directly at LDAP.
 % 
 % Okay.
 % 
 % > > [ Binaries ]
 % > > This is a classic package management problem.  If you're not using
 % > > cfengine for package management, then use your normal package management
 % > > solution to get the package installed.  If you are using cfengine, then
 % > > you're in an interesting catch-22:  How do I install the package used to
 % > > install packages?
 % >
 % > Not using cfengine for package management. I made a home-rolled RPM
 % > which includes the binaries and the latest update.conf. Part of the
 % > post-install runs 'cfagent -q' so cfenginization happens at RPM
 % > installation time.
 % 
 % So you have a system outside of cfengine which actually installs the
 % cfengine package, then?  That certainly simplifies the bootstrapping
 % problem within cfengine, although I'd imagine it just moves it into the
 % packaging system.
 % 
 % > > [ Server allowing IP access ]
 % > > How are other people solving the 'random list of IP addresses' to import,
 % > > especially with long lists that change regularly?
 % >
 % > Do not have this problem; all my hosts are internal-only
 % > so cfservd on the master has
 % >
 % > control:
 % >   cfservers::
 % >       TrustKeysFrom = ( 10.0.0.0/8 )
 % >       DynamicAddresses = ( 10.0.0.0/8 )
 % 
 % I'm trying to convince myself not to do this, I guess.  It certainly seems
 % like the generically reasonable thing to do on a private, corporate LAN.
 % I've had publicly accessible cfengine servers on which I would not do
 % this, but for most cases...
 % 
 % I also have mixed feelings about doing this when Windows and Unix machines
 % share network space; not that I don't trust the Windows boxes, but I don't
 % trust the Windows boxes.
 % 
 % > > [ Public Keys ]
 % > >
 % > > Trusting both ends of the connection is one mechanism for solving this
 % > > problem, and it might be that it's the best mechanism.  After all, once
 % > > the keys are set through trust on the first connection, trust is no 
longer
 % > > used, so it's probably fine.  Is that what most people are doing?
 % >
 % > See above; yes.  Trust is predicated upon physical access to the LAN.
 % > I don't really trust cfengine's trust models anyway and probably wouldn't
 % > use them even if I had a cfservd outside my firewall. I'd use
 % > router ACLs upstream of the cfservd host and iptables on the box itself
 % > to only permit known-good IPs.
 % 
 % That's an option, but it's not a terribly appealing one.  It moves
 % management of cfengine outside of cfengine, which I have a problem with.
 % One of my main goals in all automation is to make all information
 % accessible to all systems, but using a firewall to do access control
 % requires that you set up two groupings of servers, one in the firewall and
 % one in the cfengine configs.  This will almost definitely have duplication
 % of information, and attempts at normalization of that info will likely be
 % frustrated by any number of factors.
 % 
 % > I guess it all comes down to -- as Morcheeba asked -- "who can you trust?"
 % > What is your exposure if, through public key or DNS spoofing, a baddie
 % > gets to pretend the machine he's on is an authorized cfengine client? If
 % > you have your /etc/shadow file in the copy: payload, pretty high. If
 % > you have server configuration files or processes/tidy type actions, the
 % > worst that will happen is he's got a nicely configured machine.
 % 
 % Yeah, but it generally makes sense to work based on least access, rather
 % than most.  I try to operate that way, anyway.
 % 
 % Similar to the NIS vs. anything else struggle, though, is security really
 % worth the effort in this case, considering how much more effort it is?
 % 
 % > I exaggerate, of course, but seriously -- seems to me the risk is much
 % > higher having unfirewalled, non-chroot/privsep daemons that are
 % > potentially exploitable to get local root shells, than anything happening
 % > within the framework of known-good, expected cfengine actions happening
 % > to stray hosts.
 % 
 % I agree with this.  When possible I plan on allowing clients to make this
 % decision, because it's largely a question of security policy (or lack
 % thereof).
 % 
 % > Look forward to reading the article, thanks for taking the time to do this
 % > survey too. It's helpful to re-examine your underlying assumptions from
 % > time to time to make sure they're, if not totally rational or 'best' in
 % > some objective sense, at least internally consistent in their insanity. :-)
 % 
 % There is a distressing lack of 'best practices' in the cfengine world, I
 % think.  As I've developed my own I am trying to publish them (and my
 % cfengine series will focus much more on best practices than on the
 % technology, since the reference is so good), but (as has been mentioned
 % many times) it'd be great if we as a community could work more on this.
 % 
 % I'm trying. :)
 % 
 % Luke
 % 
 % -- 
 % "I worry that the person who thought up Muzak may be thinking up
 % something else."
 %      --Lily Tomlin
 % 
 % 
 % _______________________________________________
 % Help-cfengine mailing list
 % Help-cfengine@gnu.org
 % http://mail.gnu.org/mailman/listinfo/help-cfengine

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest@peak.org
                                      .   
                                              . http://www.peak.org/~sechrest