[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TrustKeysFrom .. a host netgroup?
From: |
Mark . Burgess |
Subject: |
Re: TrustKeysFrom .. a host netgroup? |
Date: |
Sat, 11 Jan 2003 10:40:10 +0100 (MET) |
Ok, I hear you. The main reason for using IP addresses is that
you normally want to trust a whole subnet at a time when setting
up the keys. After that you switch off trust and be done
with. I can add support for name lookup, but I have no use
for it myself.
I disagree with Luke -- I think DNS is much easier to spoof than IP
addresses.
M
On 10 Jan, Marion Hakanson wrote:
>> Why would you want to trust DNS ?
>>
>> M
>
> Mark,
>
> Luke spoke (typed) my mind before I got a chance to. I trust DNS here
> because it makes sense to do so. There are certainly circumstances
> where it does _not_ make sense to trust DNS, but there are other things
> to weigh when making that decision, and having cfengine's author make
> the decision for me is suboptimal, in my opinion.
>
> For us, it's convenient, it's one source of information, and the consequences
> of DNS being compromised are not so terrible when it comes to cfengine, as it
> is used here. For example, we do not run cfengine continually, nor
> automatically. We use it at OS install time, and manually when configuration
> changes are made. Maybe someday we'll trust cfengine and our own cfengine
> programming enough that we'll turn it loose on its own, but not just yet.
>
> What irks me is when I have to make my code more complex in order to avoid
> keeping the same piece of information in multiple places, a situation which
> experience has shown causes problems far more often than we've ever had DNS
> compromises to deal with. And if I don't want to trust DNS, I can enter
> IP addresses everywhere that hostnames are accepted -- most network utilities
> work this way.
>
> For those of you who want to use host names in this particular situation,
> here's what I've come up with. Note that the ${policyhost} macro and the
> "policyhost" class get setup in a globally shared file that is imported
> right before this bit of code gets imported into cfservd.conf:
>
> control:
>
> linux::
> policyhostip = ( ExecResult(/bin/sh -c "host ${policyhost} | grep address
> |
> awk '{print $4}'") )
> !linux::
> policyhostip = ( ExecResult(/bin/ksh -c "nslookup ${policyhost} | egrep
> '^Ad
> dress:' | tail -1 | awk '{print $2}'") )
>
> any::
> TrustKeysFrom = ( "$(policyhostip)" )
> AllowUsers = ( root )
> cfrunCommand = ( "$(cf_workdir)/bin/cfagent" )
>
> policyhost::
> AllowConnectionsFrom = ( 192.168.10-20.* )
>
> !policyhost::
> AllowConnectionsFrom = ( "$(policyhostip)" )
> . . .
>
>
> Above, we are trusting a shell and three utilities along with DNS.
> I'll leave it to the reader to decide if that mess of code is more or
> less error-prone than it would be to simply trust DNS alone.
>
> Why do I do this? Because I use ${policyhost} (a _name_) in other
> clauses, e.g. in update.conf and all over cfagent.conf to tell the client
> where to find the latest config files. Cfengine trusts DNS and accepts
> a hostname _there_ (in "server=$(policyhost)" options of "copy" clauses),
> why not in cfservd.conf?
>
> Representing the same piece of information in two different locations,
> in two different ways, is just asking for trouble. They _will_ get out
> of sync and lead to problems. Way more often than DNS is compromised.
> Give me a simple and consistent user (programmer) interface any day.
> Please!
>
> Thanks and regards,
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272 Email: Mark.Burgess@iu.hio.no
Fax : +47 22453205 WWW : http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~