Puppet users - Apr 2010 - Pushing a file only if another does not exist.

I am trying to write a module for tripwire. I need to push out the
twcfg.txt and twpol.txt files only if the tw.cfg and tw.pol files do
not currently exist.

How can do I this with File{}? I''m can''t seem to find a way to
do it.
In general times, how can you deploy file A only when file B does not
exist?

And... tripwire... what a mess. I am trying to use push out the site
key, then use several Exec{}''s to generate the local key, and encrypt
tw.cfg from twcfg.txt and tw.pol from twpol.txt. Hence the need to
only deploy the source files only if the encrypted files are gone.

No matter what approach I take, they all seem to be ugly. If I want to
make it as automated as possible, and run several Exec{} statements on
the client, you need to pass the pass phrases on the command line to
twadmin. This obviously isn''t good. I don''t think twadmin lets
you
pass pass phrases from a file.

On the other hand, if the local key generation is done on the puppet
master, then it has to be a manual process that''s done whenever a new
system is deployed. Not scalable. Since the client key is also
generated on the master, it means that the tw.cfg and tw.pol files
need to be encrypted on the master as well. Also not scalable.

Ugh. my head hurts. Stupid friggin PCI compliance.

Doug.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> How can do I this with File{}? I''m can''t seem to find a
way to do it.
> In general times, how can you deploy file A only when file B does not
> exist?
use a fact indicating that file A exists.

cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvTei4ACgkQbwltcAfKi39MIACgmPmp6GF0mqeEmtnq5zPFLzva
rqkAnjkfSaKLja+DKHgsrOMeyOq+bnf4
=qTi5
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Douglas Garstang <doug.garstang@gmail.com> writes:
> I am trying to write a module for tripwire. I need to push out the
> twcfg.txt and twpol.txt files only if the tw.cfg and tw.pol files do not
> currently exist.
> How can do I this with File{}? I''m can''t seem to find a
way to do it.
> In general times, how can you deploy file A only when file B does not
> exist?
> And... tripwire... what a mess. I am trying to use push out the site
> key, then use several Exec{}''s to generate the local key, and
encrypt
> tw.cfg from twcfg.txt and tw.pol from twpol.txt. Hence the need to only
> deploy the source files only if the encrypted files are gone.
I think that if you''re installing Tripwire policy files on local disk,
I
would take a step back and see if you have a better design available.
Tripwire is the poster child for something that really wants a read-only
network file system.  You want to only be able to update the files in one
place that requires secure access, and then have all your systems read the
signed database files from that one place but not have the ability to
change them.

You can simulate most of the protection that you get from that by having
Puppet actively monitor things like the local keys and warn you if the
attacker just changes keys so that they can initialize a new database, but
I think it''s easier to just put it on a network file system in the
first
place.

Doing Tripwire properly is generally hard anyway, since you need a way of
doing the system verification run that the attacker can''t just replace
with a cron job that mails you a copy of a clean report, although to some
extent you can rely on lazy attackers who don''t find things like that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Apr 24, 2010 at 4:27 PM, Russ Allbery <rra@stanford.edu>
wrote:
> Douglas Garstang <doug.garstang@gmail.com> writes:
>
>> I am trying to write a module for tripwire. I need to push out the
>> twcfg.txt and twpol.txt files only if the tw.cfg and tw.pol files do
not
>> currently exist.
>
>> How can do I this with File{}? I''m can''t seem to find
a way to do it.
>> In general times, how can you deploy file A only when file B does not
>> exist?
>
>> And... tripwire... what a mess. I am trying to use push out the site
>> key, then use several Exec{}''s to generate the local key, and
encrypt
>> tw.cfg from twcfg.txt and tw.pol from twpol.txt. Hence the need to only
>> deploy the source files only if the encrypted files are gone.
>
> I think that if you''re installing Tripwire policy files on local
disk, I
> would take a step back and see if you have a better design available.
> Tripwire is the poster child for something that really wants a read-only
> network file system.  You want to only be able to update the files in one
> place that requires secure access, and then have all your systems read the
> signed database files from that one place but not have the ability to
> change them.
A read-only network file system... Well, all I can think of there that
would be appropriate would be sshfs. Having never implemented it, I''m
not sure what''s involved in that. I''m not sure why a read-only
file
system is required though. What''s wrong with puppet managing the
files?
>
> You can simulate most of the protection that you get from that by having
> Puppet actively monitor things like the local keys and warn you if the
> attacker just changes keys so that they can initialize a new database, but
> I think it''s easier to just put it on a network file system in the
first
> place.
Still don''t understand why a network read-only file system is better
than puppet.
>
> Doing Tripwire properly is generally hard anyway, since you need a way of
> doing the system verification run that the attacker can''t just
replace
> with a cron job that mails you a copy of a clean report, although to some
> extent you can rely on lazy attackers who don''t find things like
that.
PCI compliance doesn''t go into details. The whole thing is a crock of
shit really. Installation of tripwire was one of the requirements on
the list of 10,000 or so, so that''s what I am trying to implement.
Then again, so was anti-virus software on Linux...

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Douglas Garstang <doug.garstang@gmail.com> writes:
> On Sat, Apr 24, 2010 at 4:27 PM, Russ Allbery <rra@stanford.edu>
wrote:
>> I think that if you''re installing Tripwire policy files on
local disk,
>> I would take a step back and see if you have a better design available.
>> Tripwire is the poster child for something that really wants a
>> read-only network file system.  You want to only be able to update the
>> files in one place that requires secure access, and then have all your
>> systems read the signed database files from that one place but not have
>> the ability to change them.
> A read-only network file system... Well, all I can think of there that
> would be appropriate would be sshfs. Having never implemented it,
I''m
> not sure what''s involved in that. I''m not sure why a
read-only file
> system is required though. What''s wrong with puppet managing the
files?
If I''m an attacker, and I want to fool Tripwire once I''ve
taken over the
system, I change the Tripwire keys and then reinitialize the database.
Tada, now there are clean Tripwire reports.

Of course, you may have other ways of detecting that Puppet isn''t
running
regularly if the attacker stops it, in which case Puppet has a chance of
detecting that the keys have been changed (although even that can be a bit
tricky).

If the database is in a location that''s read-only from the perspective
of
the system running Tripwire, then there isn''t any way to just quietly
update the database without your knowledge.  This is why the Tripwire
documentation recommends a write-protected floppy disk.  I find a network
file system like a read-only NFS export to be a lot easier to manage than
read-only floppy disks.  Of course, I''m spoiled by having AFS available
everywhere, and if you don''t already have any network file system
handy,
setting one up may be more trouble than it''s worth.
> PCI compliance doesn''t go into details. The whole thing is a crock
of
> shit really. Installation of tripwire was one of the requirements on the
> list of 10,000 or so, so that''s what I am trying to implement. 
Then
> again, so was anti-virus software on Linux...
Welcome to the wonderful world of PCI.  Have fun with password lockout!  I
love security standards that require you to turn an unsuccessful
compromise attempt into a successful denial of service attack.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Apr 24, 2010 at 5:00 PM, Russ Allbery <rra@stanford.edu>
wrote:
> Douglas Garstang <doug.garstang@gmail.com> writes:
>> On Sat, Apr 24, 2010 at 4:27 PM, Russ Allbery <rra@stanford.edu>
wrote:
>
>>> I think that if you''re installing Tripwire policy files on
local disk,
>>> I would take a step back and see if you have a better design
available.
>>> Tripwire is the poster child for something that really wants a
>>> read-only network file system.  You want to only be able to update
the
>>> files in one place that requires secure access, and then have all
your
>>> systems read the signed database files from that one place but not
have
>>> the ability to change them.
>
>> A read-only network file system... Well, all I can think of there that
>> would be appropriate would be sshfs. Having never implemented it,
I''m
>> not sure what''s involved in that. I''m not sure why a
read-only file
>> system is required though. What''s wrong with puppet managing
the files?
>
> If I''m an attacker, and I want to fool Tripwire once I''ve
taken over the
> system, I change the Tripwire keys and then reinitialize the database.
> Tada, now there are clean Tripwire reports.
>
> Of course, you may have other ways of detecting that Puppet isn''t
running
> regularly if the attacker stops it, in which case Puppet has a chance of
> detecting that the keys have been changed (although even that can be a bit
> tricky).
>
> If the database is in a location that''s read-only from the
perspective of
> the system running Tripwire, then there isn''t any way to just
quietly
> update the database without your knowledge.  This is why the Tripwire
> documentation recommends a write-protected floppy disk.  I find a network
> file system like a read-only NFS export to be a lot easier to manage than
> read-only floppy disks.  Of course, I''m spoiled by having AFS
available
> everywhere, and if you don''t already have any network file system
handy,
> setting one up may be more trouble than it''s worth.
What about the script that mounts the file system? That could be
compromised. This seems somewhat like security via obscurity to me.
Your security is only as good as it''s weakest link, and the script
that runs every day would be the weakest link. Therefore, there
doesn''t seem to be much point in going into an extra level of effort
to secure other parts of tripwire if the script is still a
vulnerability.

And... this doesn''t help with my key issue anyway. Lets say that the
client system mounts /etc/tripwire every day so that it can run it''s
check. This means that puppet has to put the client side key on the
network file server, which means it''s still not running on the same
machine as the puppet master, which is essentially the same
configuration in the first place. Puppet still has to push out the
site key file to the network file server, the source cfg and policy
files, cause the client to generate a local key (for the network file
client no less which makes the entire thing even more complicated!),
encrypt the cfg and policy files, and then remove the source files.
So... we are back to my original question of how I get puppet to push
out twcfg.txt and twpol.txt if tw.cfg and tw.pol are missing.
>
>> PCI compliance doesn''t go into details. The whole thing is a
crock of
>> shit really. Installation of tripwire was one of the requirements on
the
>> list of 10,000 or so, so that''s what I am trying to implement.
 Then
>> again, so was anti-virus software on Linux...
>
> Welcome to the wonderful world of PCI.  Have fun with password lockout!  I
> love security standards that require you to turn an unsuccessful
> compromise attempt into a successful denial of service attack.
We already know it''s going to be hell on earth. Oh hey... Stanford..
you''re around the corner...

Doug

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Douglas Garstang <doug.garstang@gmail.com> writes:
> What about the script that mounts the file system? That could be
> compromised. This seems somewhat like security via obscurity to me.
> Your security is only as good as it''s weakest link, and the script
that
> runs every day would be the weakest link. Therefore, there doesn''t
seem
> to be much point in going into an extra level of effort to secure other
> parts of tripwire if the script is still a vulnerability.
I was assuming you''d leave the file system mounted all the time.
> And... this doesn''t help with my key issue anyway. Lets say that
the
> client system mounts /etc/tripwire every day so that it can run
it''s
> check. This means that puppet has to put the client side key on the
> network file server, which means it''s still not running on the
same
> machine as the puppet master, which is essentially the same
> configuration in the first place.
Right, but you''re only putting it on one system that has write access
to
it, namely the file server, and you can lock that system down much more
completely.  That one system holds all the keys for all your Tripwire
databases, server and site.

At that point, it''s not clear that you need to use Puppet to manage the
database and keys on the file server, since they''re just data that
lives
in one place at that point.  (Well, you might want a backup.)  Of course,
if you want to treat them as configuration, then yes, you have a Puppet
issue still -- I didn''t mean to say it''s not a reasonable
question.  But I
think you''re in a better spot for the client systems.

But yes, you need to ensure that the attacker can''t just unmount the
file
system and replace it with local directories with a new database, etc.
The normal way that one does this is that one puts the checking binary on
the network file system as well, compiles a cryptographic key into the
checking binary, and then has the binary checksum itself and then sign its
report with that key.  You then need infrastructure to check that the
report is signed with a valid key, and also that you get a report every
day, and that it''s not a replay of the previous day''s. 
Samhain does some
stuff like this.

In practice, most people stop some point short of this, since after all, a
sophisticated attacker may be able to load a kernel module that will
prevent Tripwire from seeing that binaries have changed.  It''s all just
moving the problem, and it''s a question of how much you want to defend
against.  I just like network file systems for this stuff because if you
have them handy, it''s an easy way to make the database part more
robust.

(For the record, we put our Tripwire databases in AFS so that they''re
read-only and put the Tripwire binary in AFS, run it from cron on each
server, mail the results to a central collection point, and check for
servers that aren''t sending reports.  We don''t defend against
replacing
the cron job with just mailing out a clean report, and we don''t use
cryptographically signed binaries, although we keep thinking about a
project to do both of those.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/04/10 10:00 AM, Russ Allbery wrote:
>> PCI compliance doesn''t go into details. The whole thing is a
crock of
>> shit really. Installation of tripwire was one of the requirements on
the
>> list of 10,000 or so, so that''s what I am trying to implement.
Then
>> again, so was anti-virus software on Linux...
> 
> Welcome to the wonderful world of PCI.  Have fun with password lockout!  I
> love security standards that require you to turn an unsuccessful
> compromise attempt into a successful denial of service attack.
> 
I also love the fact that "compliance" to the standard is going to
give a lot of enterprises the excuse to say "We are secure because
we''re PCI DSS compliant".

/me puts head in hands at the victory of "standards" over risk
management.

Regards

James Turnbull

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS9QGdyFa/lDkFHAyAQJIxwgA0uI228dK8mHS3kQFlbpkWINs5Rde7dVk
MTzQcIrM2rd9O8k7jz7JuysFoOC538ySsAQzAQa/5zT+S0LI7P2aEDnrqpfYAN90
VKeqDMw2eKpCas+kaquRA+m+zIKV287SjLEI8UmNgA2wxdPsiKrY1VOZcL/Qu/IN
xmksJjfJELbJnGX+VrYTkcrPQ7lg5mmahmBrRBTSv314Tn12OD05nUgljsI8M/gh
oUTwJoWCPxqMk7al7amwiNmDtiiVhVGePIYywsxEUVrI8JBo7dJ6fmvlqIt0hWku
2r0HbxWjOn429DZQR98ad8nMGsb4IQNSFd2lAgf4qGXTnm89V83EoA==/r1z
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.