config management Re: [nycbug-talk] A couple of security related questions

[George Georgalis]

On Tue, Oct 05, 2004 at 01:57:28PM -0600, Tillman Hodgson wrote:
>On Tue, Oct 05, 2004 at 01:15:08PM -0400, George Georgalis wrote:
>> Which is a decent segue to my present issues.
>> 
>> first off I'm thinking to use CVSup and unison [1] to resolve.
>> 
>> Three problems,
>> 1) for the purpose of NFS, sync /etc/passwd, group and mount points.
>> 2) get "root read only" (and other ownership/perms) files from golden
>>    box to production.
>
>These two I can take a crack at with some pretty simple architecture,
>not up to cfengine snuff but "good enough", assuming that "mount points"
>means "/etc/fstab" ;-)

Ahem, as soon as my dev todo list is below panic level (sound
familiar?), I'll be porting my bike shed to BSD. Actually, I'd be
running a, top of the foodchain, BSD workstation right now, but I couldn't
work out cons25 to linux termcap issues, which was a show stopper for
my last migration attempt. Long as I'm venting, not to happy about this
either: http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.3/0641.html
two of my messages each to linux kernel list _and_ driver authors went
unanswered. my particular SATA disk (seagate 160Gb) is on a blacklist
now that changes performance from ~47MB/sec to ~14MB/sec, yet nobody
seems concerned that it doesn't belong on the black list... I remove
my disk from the driver black list, and put the disk in production.
Blah... 

but for now, yes I'm talking fstab. I'm not pro-cfengine either,
maybe if I was more happy with a stock OS/Distro it'd be an option.

>
>Use rcp and push the critical files from a golden master. No, seriously:
>Kerberized rcp is secure, data session encrypted (with the '-x' switch),
>and can be easily automated from cron with the use of a keytab on the
>golden master in place of a password (without needing to deal with the
>mess of putting matching keys on all the clients machines). Push is
>better than pull in this sort of situation simply because failure
>detection and resolution is centralized.

umm, are you suggesting push passwd et al for NFS, and pull everything
else from the gold master? but doesn't that mean compromise of any host
can lead to compromise of all hosts -- since auth tokens for root on
each, is on each?  Isn't important to use one of push / pull but not
both?  I've always favored push, but after reading infrastructures.org
pushpull, and considering a readonly CVSup, I'm thinking pull from
gold....

kerberos, is sweet, but it's black magic to me, short term I'd rather
maintain ssh keys. (BTW - when a box comes up, you can manually add a
passphrase into ssh-agent then start crond with that environment and
exit; to get passphrase ssh under cron :) )


>
>The script, running on the golden master, can contain all kinds of
>safety checks and can email details of inconsistencies to your cell
>phone or whatever you use for notifications. Heck, if you use something
>like rt3 to track problems you can have the script create a trouble
>ticket for you and dump details into the ticket automatically.

oh good idea, mon scripts submit rt tickets ;-)


>
>You can also use mtree to check ownership/permissions and reset them if
>necesasry. The mtree master file can be rcp'ed in from a golden master
>(and should be, as a local copy is vulnerable to tampering).

never heard of mtree, but it looks like it will "help the hack" I want
to avoid. I would rather make a jail for each client on the gold
master, then the clients can just no passphrase ssh rsync pull their
junk, as root. 

>
>On the golden master use RCS or non-networked Subversion (local
>repository) to track changes to config files that are being pushed out.
>
>Oh, ok, scp with rsa keys would also work. But key management is a pain,
>and I'm a Kerberos nut ;-)

I got the concept of kerberos down, I think, but like I said ssh keys
would be easier for me. I don't know anything about NIS either accept I
understand NIS+ is lame.

But I don't think auth is really an issue here, doesn't it really come
down to auth tokens are on the client or not; and allowing them to get
all the uid/gid/perms but not more than the particular files for the
client.


But let me backup a little, for NFS do I need to sync any other files
than: /etc/shadow /etc/passwd /etc/group

I guess there is no practical (easy) way to have some extra accounts on
a LAN box while keeping the global users from the NFS server synced too?

Ironically, you (I think) recommended infrastructures.org, but I was
really wanting to solve my root read pull only specific config problem;
rsync push to each and every client from gold was never an issue. But
you win a couple drinks anyway. :-)

// George

Dang, Twins played good.



-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george at galis.org