Slashdot Mirror
Tripwire Going GPL
Johnath writes: "Maybe it's a little early to break out the party hats, but after noticing that a new version of Tripwire had been released, I checked up on their site and noticed they are going to open source it. Supposed to open it up this fall, and under the GPL no less." There are a lot of people who swear by Tripwire, it'll be nice to see this come to fruition. One thing that's odd - This only applies to Tripwire for Linux.
I don't mean to say that OSS is bad or anything, but I don't think your statement is necessarily substantiated.
I went to a talk given by the Tripwire author, and half the talk was about his thoughts on how tripwire relates to open source. He made a couple points (I don't remember his whole talk, sorry, it was a very good one)...
His first point was that, basically, they hadn't gotten a lot of help from the open source community (on the non-commercial version). There was one programmer who regularly sent in updates, and there were maybe 20-30 people who contributed from time to time, and then a few odd updates from other people. This was a very small percentage of the open source user base. He showed how much the opportunity cost was for openning the source. He then compared that to the price of paying his own programmers to fix bugs. He found (in his case, so this doesn't necessarily apply to anything else) that it was cheaper to keep it closed, and more bugs were found by the paid programmers. And it wasn't for lack of an audience, OSS tripwire is pretty dang popular. His opinion was that OSS lets more eyes see it, but those eyes weren't very productive, even given that not every OSS tripwire user is a coder.
Secondly, he didn't wanna piss the linux people off.
Guess which point won out?
--
Tripwire is a security tool. That having been said, these sorts of tools have quite commonly become *much* better by being open source utilities, since there are definitely a lot of people running around on lists like Bugtraq who go into a positive frenzy over making security related patches. Tripwire is also one of the few integrity checkers that many people are familiar with using, and while a skilled system administrator who can code in C could probably come up with something very similar in a few weeks, it's not really all that feasible. Anywhere where this sort of integrity checking would be _demanded_ to ensure certain policy requirements, the system administrators are likely to not have the time necessary to develop such a tool (at least in most companies, time for R&D is pretty limited). GPL or no, it's these same companies that are most likely to be looking for a support contract for such a tool, because places that have policies requiring this level of attention to detail are also quite likely to have made it standard operation procedure to get support contracts for every possible piece of software they use, no matter how small. (This all falls under "assurance" guidelines by my book)
GPLing this code will make it more friendly to the freelance security consultants, as well as those who aren't so freelance because now they'll have a chance to exercise their paranoia and examine the code themselves to see for sure that it's good and solid.
...not to mention that Tripwire has recieved a great deal of help from the hacking community in the way of pointing out potentially weak implementation methods, and generally just making things tidier.
So I don't see making the code GPL making any serious dent in the company's profit model, especially with more companies starting to get used to being able to obtain support contracts for software they didn't have to actually pay anything for. It's only recently that you could even think of being able to obtain support contracts for software that wasn't backed by a company whose profit model was based on the sale of the software, which makes the whole trick of making certain there are experts that can be called on in a flash to help solve problems when something goes wrong highly improbable, if not impossible.
I know it might sound silly trying to obtain a support contract for Tripwire, but at the last company I worked for, such a thing would not only be desired, but not too terribly hard to get upper management to sign off on. (For some reason the bigger a company gets, the less likely they are to want to trust the word of their own employees alone... but then again, that quickly falls under the umbrella of assurance in a good set of security policies.)
Lemme tell you something.
I'm really, really, really starting to like the concept of, at minimum, setuid binaries failing to execute unless they pass an MD5 test executed by the kernel before an execve().
Microsoft is already working with signed drivers and signed packages, and SecureBSD(a new *BSD variant) is advertising binary hashing out-of-the-box. I'm curious what the rest of you think about the kernel attempting to rely on the trust imbued in the first version installed to authenticate future executions of that version.
Best problem I can come up with is that a successful setuid hack could allow the root to reconfigure the kernel to ignore a specific file's changes...at that point, I'm thinking of some form of shared "setuid compile" secret that gets appended to the application for hash purposes...then, all apps get hashed as if they had the secret appended...come in as root and attempt to compile something such that it'll setuid, attempt to install into the kernel DB...and poof. You fail, because you're not consistent with the kernel hash secret.
Thoughts?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Do you know what it does? It calculates checksums for all files. These sums can then be stored on read-only media, such as a CD. Then a simple check is all that is nec. to detect modifications to system files.
This is a very complete list of security software for UNIX machines.
I was wondering about the changes to Tripwire, so I scrubbed the FAQ and found the following gem:
Will the open source version of Linux Tripwire be as secure as other versions of Tripwire? Explain the risks and advantages for an open source security solution.
An open source solution provides the user and the systems administrator the instructions that allow them to examine it for security holes, Trojan horses and trap doors. It provides an enhanced sense of security for those who would like to have the source code to examine.
Corporate IT managers and security administrators use good judgment everyday by deploying best-of-breed security products. Good security policy dictates that one purchases software or downloads software from the actual security vendor's site and not from "spurious sites" on the Internet. By taking the appropriate steps to create a solid security framework, the security community and the users of Tripwire vastly reduce any risks of the code being modified intentionally for wrongdoing.
--
Corporate IT managers and security administrators use good judgment everyday by deploying best-of-breed security products. Good security policy dictates that one purchases software or downloads software from the actual security vendor's site and not from "spurious sites" on the Internet.
Actually, this isn't technically correct.
They're essentially arguing that a "single point of failure increases security". In some practical senses, it does, because then attacks are always detected and have own group that owns stopping them. When the job is distributed, no single group can track the attacks.
But ahhhh, no single group can independantly attack either. Consider the situation where you have ten previous versions "out there". Distributing the load of archiving old versions means that you can't infect old versions yourself, and that (assuming the source and two mirrors) any attack that hit only one site would be detected and "outvoted" by the other two--for past, present, and future revisions. Total control in the hands of the original authors does imply a single point of attack, trojanization, and hash coverup.
Of course, the tools aren't available to cross check hashes against multiple sites...I'd love to see install-ssh retrieve ssh from one of ten sites, and then download hashes from two others. This changes the attack profile to within my perimeter(can spoof the content of all hosts) instead of from the central server's perimeter(which I have no control of.)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com