On Sat, Apr 24, 2010 at 5:00 PM, Russ Allbery <r...@stanford.edu> wrote: > Douglas Garstang <doug.garst...@gmail.com> writes: >> On Sat, Apr 24, 2010 at 4:27 PM, Russ Allbery <r...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
