help-cfengine
[Top][All Lists]
Advanced

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

Re: Bootstrapping


From: Luke A. Kanies
Subject: Re: Bootstrapping
Date: Wed, 18 Feb 2004 14:37:40 -0600 (CST)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]