from the top # Policy file for Red Hat Linux # # # V1.2.0rh # # # August 9, 2001 # # and there are multiple references to file locations found only in Redhat distro such as /usr/share/grub/i386-pc/e2fs_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/fat_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-RedHat/ffs_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-RedHat/minix_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-RedHat/reiserfs_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-RedHat/stage1 -> $(SEC_CRIT) ; /usr/share/grub/i386-RedHat/stage2 -> $(SEC_CRIT) ; /usr/share/grub/i386-RedHat/vstafs_stage1_5 -> $(SEC_CRIT) ; when these lines should read (for Gentoo) /usr/share/grub/i386-pc/e2fs_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/fat_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/ffs_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/minix_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/reiserfs_stage1_5 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/stage1 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/stage2 -> $(SEC_CRIT) ; /usr/share/grub/i386-pc/vstafs_stage1_5 -> $(SEC_CRIT) ; On emerging tripwire, and doing an init, I had 290 some odd instances of the file referenced not being in gentoo at all, or in a different place. I'm just going through the twpol.txt now - the grub stuff I mentioned above is the only stuff I've fixed so far. Obviously the sample twpol.txt can't be tailored to everyone's needs, but I think it could use a little tweak here and there :) Reproducible: Always Steps to Reproduce: 1.emerge tripwire 2.3.1.2 2.run twinstall.sh 3.run tripwire --init Actual Results: Multiple File system errors in report, which indicate reduced effectiveness of tripwire as a security tool Expected Results: twpol.txt should be tailored to more closely match gentoo specific file paths
Thats the example policy file included with the tripwire distribution, creating a "one size fits all" policy file for gentoo is going to be tough. Maybe i'll create one for just the software available in a default base system, any patches welcome ;)
Created attachment 21520 [details] edited twpol.txt, that runs on my x-less gentoo server at home
Created attachment 45412 [details, diff] better default policy file for gentoo This is a diff between the twpol.txt installed when emergeing tripwire, and a twpol.txt file that is more tailered for gentoo. I focused mainly on config files in /etc and added the basic /etc/init.d scripts plus emerge. I did not change too much about binaries, other than to comment out the ones that caused error. I have tried to make this file work with a new install of gentoo, but cannot gaurantee it will run without errors because I installed a few packages before installing tripwire. It will ceratinly get people up and running faster than the 'redhat' policy file. Cheers. To make the patch I ran: # diff -U3 twpol.txt twpol.txt.gentoo > twpol.txt.patch I am not sure if that is the correct command, if not just let me know...I'll add myself to CC list.
Is there any progress on this. I tried to use the patch, but couldn't figure out how to use it. plus my tripwire says v1.2.0 config and this was for 1.0.0 (and is nearly five years old!)
Hi there, please progress on this bug.
Created attachment 96211 [details] New complete policy file Well, I went ahead and created an even better default policy file. I changed the structure of the original completely. I realized that with Gentoo the better approach is to organize the files/rules based on the package that installs them, rather than by their function as in the Redhat default. This way, if you don't have a certain package installed you can quickly comment out the entire block of files that that package installs. They are delimited thusly: # # The diffutils binaries # /usr/bin/cmp -> $(SEC_CRIT) ; /usr/bin/diff -> $(SEC_CRIT) ; /usr/bin/diff3 -> $(SEC_CRIT) ; /usr/bin/sdiff -> $(SEC_CRIT) ; # # The ''findutils' binaries # [...] These show the binaries that the diffutils package installs. They obviously end when the next package begins. Also, because a few packages install files that include a version number, I have created a few global variables, namely GCCVERSION and BINUTILSVERSION. You will have to edit these to the version number on your system. Be warned, I created this policy file for _my_ system. It has many more rules than a vanilla Gentoo install, so you will still have to do some tweaking, but it should be painless now. I am still working on this, and in the next few days I will add rules for commonly installed programs such as syslog-ng, vixie-cron and the like, as well as common servers/daemons such as apache, mysql, named, PHP and so on. If you want to check my latest version have a look at http://badcomputer.org/unix/tripwire.pol.gentoo I will leave these new additions commented out, so you only have to add what you need. Hope this helps some people...
Any movement on this old, old bug?
Created attachment 253369 [details] Bash script to generate a twpol.txt file from lists of gentoo packages and lists of files Tinkering with tripwire, ran into this bug, and resulting script builds from Darren Kirby's file; and elsewhere, a perl snippet that commented in/out, depending on file existence. Method of script should be clean on inspection. I have no idea if the resulting policy file is too verbose, etc. But the policy file passes the tripwire parse test, etc.
The mktripwire.sh script has undergone substantial change since 2010-11-06. Revised policy-generator scripts are located at http://bugs.gentoo.org/344577
Assigning to new maintainers / proxies.
*** Bug 344577 has been marked as a duplicate of this bug. ***
Created attachment 269983 [details] Bash script to generate a twpol.txt file from lists of Gentoo packages and lists of files This attachment is Gentoo-centric. A generic version also exists, with the generic version being adaptable to other Linux distributions.
Created attachment 270715 [details, diff] Patch to run the script in bash and to see verbose messages Thanks for posting the last version of the script. I had to use this patch in order to run the script. Otherwise, the script worked correctly in my box.
(In reply to comment #13) > Created attachment 270715 [details, diff] > Patch to run the script in bash and to see verbose messages > > Thanks for posting the last version of the script. > > I had to use this patch in order to run the script. Otherwise, the script > worked correctly in my box. There must be something different between our two environments. The way you have the "checking for bash" logic arranged, if $BASH includes the string "bash", then the script announces a failure, then exits. As for the "verbose" differences, those workings don't affect the ultimate object of making a decent twpol.txt file. On my box, I can obtain several different presentations on invocation, and have tested all of the permutations, I think. mktwpol.sh by itself outputs what could be a twpol.txt file, but the output has to be redirected in order to make that file. "mktwpol.sh -u" shows a terse progress message while it creates a date-named twpol.txt file; "mktwpol.sh -u -q" causes absence of any progress display while the date-named twpol.txt file is generated, and "mktwpol.sh -u -v" shows the twpol.txt file on screen at the same time it is being written to a date-named twpol.txt file. The "-q" and "-v" switches have no effect, unless the "-u" switch is present on the mktwpol.sh command line.
Comment on attachment 270715 [details, diff] Patch to run the script in bash and to see verbose messages You are right, something got rotten in my environment (fixed now). Anyway, if I run the script without the -u option, I guess the -v flag does not work as expected. Without the -v option, the script shows the "Processing rule X of N rules" message. This message is not shown if the -v option is added. That's the reason of the second fix of the (now obsoleted) patch. We are going to include a reference to this script in the tripwire ebuild. Thanks again for your work.
(In reply to comment #15) > Comment on attachment 270715 [details, diff] > Patch to run the script in bash and to see verbose messages > > You are right, something got rotten in my environment (fixed now). Anyway, if > run the script without the -u option, I guess the -v flag does not work as > expected. Without the -v option, the script shows the "Processing rule X of N > rules" message. This message is not shown if the -v option is added. That's > the reason of the second fix of the (now obsoleted) patch. > > We are going to include a reference to this script in the tripwire ebuild. > Thanks again for your work. Glad it will find some use helping people who want to try or run tripwire. Just to describe the current (intended) logic: The "-v" switch has no function without "-u." The help screen tries to make a terse summary of the command line, and groups the "-v" and "-q" switches as mutually exclusive options under the "-u" switch (automatic creation of policy text file followed by automatic invocation of processing that text file). Without the "-u" switch, the script outputs the tripwire policy to STDOUT, and right now, the intention is to have nothing appear on STDERR. Without the "-u" switch, the user is expected to direct the output to whatever file the user wants, then work from there. With the "-u" switch, the script provides three modes of viewing progress. "-q" is quiet, nothing shows up, no switch gives the "Processing rule X of N" progress messages, and "-v" has all of the text "tee"d to terminal, while being written to a filename created by the script. With all the text flying by, I figured "Processing Rule X of N" wasn't necessary to inform the viewer that progress was occurring. That set of options isn't carved in stone, and as far as I'm concerned, the script could be simplified by eliminating "-q" and "-v" progress options altogether. Either run without "-u" and send STDOUT to a filename of your choice, or run with "-u." The brief progress message could be sent to STDERR, making it visible either way. I didn't want to make the default behavior the "-u" behavior, because I thought the user ought to have to make an affirmative decision to write the output to a file, either "-u" or redirect STDOUT to a file.
Hi all, and thank you for your work on this thus far. Can a recent version of the script to generate the twpol file be attached? I see the last version was from 2011-04-14 and I'm willing to bet bugs have been found and squashed since that time. Also, I was looking through the latest tripwire ebuild (tripwire-2.4.2-r1) and saw no reference to this tool. Can you guys progress on this script to the point where it's mature enough to be mentioned in the ebuild? Regards.
Created attachment 301867 [details] Bash script to generate a twpol.txt file from lists of Gentoo packages and lists of files # Added "Include Executables" command line switch # Added some, corrected some, shuffled some package names # Terse progress report appears on STDERR unless -q switch is invoked # 110501 Rearranged Property Mask Aliases part of hardcoded header # 110522 Grouped "Boot, Kernel and Init" and added material for openrc # 111116 Added cyrus-sasl to "Security Related Programs" packages
(In reply to comment #17) > Hi all, and thank you for your work on this thus far. > > Can a recent version of the script to generate the twpol file be attached? > > I see the last version was from 2011-04-14 and I'm willing to bet bugs have > been found and squashed since that time. Thanks for the thanks. The latest/current version, as it runs on my system, is now attached to the bugreport. The last time changes were made was 16 November 2011. The attachment message summarizes the changes to the Gentoo-centric script. See too, forum chatter from September last year: http://forums.gentoo.org/viewtopic-t-851805-highlight-tripwire.html
Bumped tripwire version to 2.4.2.2. Includes reference to this bug. Sorry for the long delay. +*tripwire-2.4.2.2 (29 Mar 2012) + + 29 Mar 2012; Chema Alonso <nimiux@gentoo.org> +tripwire-2.4.2.2.ebuild, + +files/tripwire-2.4.2.2-buildnum.patch: + app-admin/tripwire version bump. Included reference to bug #34662 wrt policy + file generator script posted by <c.cboldt@gmail.com>. +
The mktwpol.sh seems to be a wonderful tool, but it does have a small issue with regards to slotted packages. I have postrgresql-server 8.4 and 9.1 installed on my system, and this causes the line /etc/pam.d/postgresql to be entered twice into my twpol.txt file. This causes a redefinition error when doing the twadmin -m P /etc/tripwire/twpol.txt call. Since the file was called twice in the same ruleset, maybe the mktwpol.txt can watch for that, and not include it twice?
(In reply to comment #21) > The mktwpol.sh seems to be a wonderful tool, but it does have a small issue > with regards to slotted packages. I have postrgresql-server 8.4 and 9.1 > installed on my system, and this causes the line /etc/pam.d/postgresql to be > entered twice into my twpol.txt file. This causes a redefinition error when > doing the twadmin -m P /etc/tripwire/twpol.txt call. > > Since the file was called twice in the same ruleset, maybe the mktwpol.txt > can watch for that, and not include it twice? I've made a change here, but would like you to test it before I post the modified script. Somewhere around line 633, in the process_packagename () routine, you'll find the line commented out below - substitute (or add) the line just below that includes the pipe through tr, sort and uniq commands. # for targetfile in ${tmp_array[@]}; do for targetfile in `echo ${tmp_array[@]} | tr ' ' '\n'| sort | uniq` ; do I don't have any slotted packages, but the modification should remove duplicate entries when processing any single packagename (and processing any single packagename will, I think, process multiple packages if they are slotted). I have slotted python here, FWIW, and never got a dupe entry. But the script logic does not check for dupe filenames, and you aren't imagining the dupes on your system. Thanks for the report.
(In reply to comment #22) > I've made a change here, but would like you to test it before I post the > modified script. Somewhere around line 633, in the process_packagename () > routine, you'll find the line commented out below - substitute (or add) the > line just below that includes the pipe through tr, sort and uniq commands. > > # for targetfile in ${tmp_array[@]}; do > for targetfile in `echo ${tmp_array[@]} | tr ' ' '\n'| sort | uniq` ; do > > I don't have any slotted packages, but the modification should remove > duplicate entries when processing any single packagename (and processing any > single packagename will, I think, process multiple packages if they are > slotted). I have slotted python here, FWIW, and never got a dupe entry. > But the script logic does not check for dupe filenames, and you aren't > imagining the dupes on your system. Thanks for the report. Sorry for the late reply, but I wasn't on the CC list before now. Anyway, I tested your one line change and it seems to be working well. Testing the slotting is easy by just installing postgresql-server:8.4 and postgresql-server:9.1 as they both have a file in /etc/pam.d/ that is named the same. With your fix the duplicate line went away.
Created attachment 313109 [details] Bash script to generate a twpol.txt file from lists of Gentoo packages and lists of files # 120330 Added `tr | sort -u` to process_packagname to remove slotted dupes Also added a few packagenames to RULENAME[11], Security Related Programs Thank you for confirmation that the fix worked. Implementation is different from my suggestion, using sort's -u switch, rather than piping through `uniq`. The packages appearing in the various lists could be expanded, and I do so as I notice pagckaes appearing in my tripwire reports, that are both in the nature of a service or security rleated function (in other words, the lists deliberately don't contain programs like browsers, irc clients, and so forth) that aren't assigned to any particular rulename.
Great script, c.cbolt. Would be nice to have this included in Gentoo's tripwire package by default.
Thank you for the kind words, and I hope you find the script useful. The script has undergone a few changes since it was last uploaded. About 50 packagenames have been added. Executable files from packages that aren't listed are still checked, as they show up in catchall inspection of the /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, /usr/local/sbin, and a few other directories. Adding packagenames to the script simply causes reportable changes to appear in a section of the tripwire report other than "OS Bin and Lib Directories" or "User Bin and Lib Directories." One expansion of inspection has been made: 120904 Added /opt/bin to "User binaries" catchall rule. There is a subroutine that can automatically respond to tripwire's "site passphrase:" and "local passphrase:" prompts. The tripwire passphrases are stored in the optional mktwpol.cfg file. Obviously an insecurity, even if mktwpol.cfg is owned by root and is only readable by root. The trigger for files installed in the /etc directory (and subdirectories) has been tightened for for a few groups of packages: Security, MTA, WWW, Database, Shell, Logging and IRC/P2P. That was done by adding "ETC_SEC[#]='ReadOnly'" to the several groups of packages mentioned.
Are you referring to attachment 313109 [details] or did you refer to a newer script? Maybe you forgot to attach it. I think it would be convenient for me and others if you can make a repository on github for instance.
(In reply to Marckus J. from comment #27) > Are you referring to attachment 313109 [details] or did you refer to a newer > script? Maybe you forgot to attach it. I think it would be convenient for me > and others if you can make a repository on github for instance. I was referring to the version that is my system, which I modify as the mood strikes me. The "current" version (last changed yesterday, added a few packagenames) wasn't attached to this bug report. That was not an oversight, just didn't think the changes were important. I'll attach the current version straightaway, and keep my fingers crossed that it doesn't contain any new mistakes.
Created attachment 357106 [details] Bash script to generate a twpol.txt file from lists of Gentoo packages and lists of files Added about 50 packagenames; added /opt/bin to the catchall "User bin" ruleset; added a subroutine to automate response to tripwire's password prompts.
(In reply to Marckus J. from comment #25) > Great script, c.cbolt. Would be nice to have this included in Gentoo's > tripwire package by default. Yeah indeed, good one :-) I'd suggest to put the versions of the script into some public VCS. This way we could create a new gentoo package, let's say app-admin/mktwpol and make app-admin/tripwire RDEPEND on it. The new package could be proxy maintained by c.cbolt if (s)he wants to, or directly by me.
(In reply to Chema Alonso from comment #30) > (In reply to Marckus J. from comment #25) > > Great script, c.cbolt. Would be nice to have this included in Gentoo's > > tripwire package by default. > > Yeah indeed, good one :-) > > I'd suggest to put the versions of the script into some public VCS. This way > we could create a new gentoo package, let's say app-admin/mktwpol and make > app-admin/tripwire RDEPEND on it. > > The new package could be proxy maintained by c.cbolt if (s)he wants to, or > directly by me. I've put the two scripts on sourceforge. The "generic" one has been maintained in parallel with the gentoo-centric one as far as packagename lists and added features goes, but hasn't been "out in the wild." Besides being adaptable to other distributions and package managers, the generic script has a few more bells and whistles, mostly aimed at a new installation of tripwire. For example, it has a subroutine for installing or modifying a logrotate configuration file. https://sourceforge.net/projects/mktwpol/ I'm a git newbie, and this is the first project I've put up at sourceforge, so you may have to tolerate some mistakes as I climb onto the learning curve.
(In reply to c.cboldt from comment #31) > (In reply to Chema Alonso from comment #30) > I've put the two scripts on sourceforge. Nice, Can I contact you by email to setup all this?
(In reply to Chema Alonso from comment #32) > (In reply to c.cboldt from comment #31) > > (In reply to Chema Alonso from comment #30) > > I've put the two scripts on sourceforge. > > Nice, Can I contact you by email to setup all this? Yes, you may.
Nice work Chuck, thanks a lot for sharing this. :)
(In reply to Marckus J. from comment #34) > Nice work Chuck, thanks a lot for sharing this. :) My pleasure, and thank you for the compliment. It was your suggestion to get this to be part of a tripwire package install, so all the recent changes / improvements / new bugs (resulting from putting the mktwpol package on a CVS, which evolved into adding a separate tripwire install script) are partly on your hands. I'm thinking that the last script posted here ought to be marked obsolete. The obsoleted scripts can be gotten even though marked obsolete. The resolution for Gentoo users will soon be to re-emerge tripwire (with the "tools" USE flag enabled, if it isn't on by default). For now, they can keyword and emerge mktwpol. I still LOL at myself for putting in a "Do you want to update tripwire?" prompt, to a user who bothered to use the "-u" (update tripwire) switch. Can you tell I wrote the script with myself in mind ;-)
I have to say that the extra prompt is also suitable for types like me who sometimes, late at night, decide to do administrative tasks when we shouldn't be doing them. Heh heh. :) I think there is one bug in twsetup; in step 5 the script ought to run mktwpol.sh, which it does, but I'm not sure if it uses the proper parameters: Step 5 - Generating plain-text policy file: /etc/tripwire/twpol-130921-1655.txt ... This is mktwpol.sh version 30MAR12 A Gentoo-oriented Tripwire Policy Text Generator Usage: mktwpol.sh [-c configfile] [-u[-r][-q|-v]] [-s] [-x] [-h|-V] [debug [#]] So I will run mktwpol.sh with -u manually. One more question - should a file like /root/.viminfo be added to STOPLIST or FILELIST? Cheers!
(In reply to Marckus J. from comment #36) > I have to say that the extra prompt is also suitable for types like me who > sometimes, late at night, decide to do administrative tasks when we > shouldn't be doing them. Heh heh. :) > > I think there is one bug in twsetup; in step 5 the script ought to run > mktwpol.sh, which it does, but I'm not sure if it uses the proper parameters: > > Step 5 - Generating plain-text policy file: > /etc/tripwire/twpol-130921-1655.txt ... > > This is mktwpol.sh version 30MAR12 > A Gentoo-oriented Tripwire Policy Text Generator > > Usage: mktwpol.sh [-c configfile] [-u[-r][-q|-v]] [-s] [-x] [-h|-V] [debug > [#]] > > So I will run mktwpol.sh with -u manually. > > One more question - should a file like /root/.viminfo be added to STOPLIST > or FILELIST? > > Cheers! I got rid of that extra prompt. If you want mktwpol to update the policy file and database, use "-u", if you don't want that, then don't use "-u". I tried to get rid of as much noise as practical, still leaving enough prompts the user knows what is going on. I know exactly what your bug is. The integration of mktwpol with twsetup demands that mktwpol run in STDOUT mode, even if the user has, in a mktwpol.cfg file, told mktwpol to use the "-u" switch. To surmount this, a "-f" switch was added to mktwpol.sh, to "force" it to send output to STDOUT. So, twsetup is sending a "-f" switch to mktwpol. The 30MAR12 version of mktwpol does not have this switch (twsetup wasn't even a thought), and mktwpol.sh is witten so that if it is passed a switch that is not on the list, it recites its help message. So, twsetup.sh is sending "mktwpol.sh -f" and 30MAR12 mktwpol.sh is going "Huh?" The packaged mktwpol-0.1.5,tar.gz and mktwpol-0.2.0.tar.gz have compatible mktwpol/twsetup programs. I'd put /root/.viminfo in a STOPLIST. The mktwpol.cfg file facilitates easy addition / change of the default rules. STOPLIST[28]+=" /root/.viminfo" Notice the "+=", which adds one more item to the existing list of files/paths to ignore, and the leading space, which keeps the addition from concatenating with the last item on the default list. I'll add /root/.viminfo the default rules file (which is a separate file under mktwpol-0.2.0 - package lists will change more than the script that processes them), and if by chance the default list and your "customized" additions contain a duplicate (which tripwire will balk at), the script finds the dupe, and tells the user what package and/or filenames appear more than once.
(In reply to Marckus J. from comment #36) > So I will run mktwpol.sh with -u manually. One other remark ... if you have tripwire setup already, meaning you have the key files and a tw.cfg file and have made a tripwire database (defaults to /var/lib/tripwire/$HOSTNAME.twd), then you probably have no need for twsetup.sh. twsetup.sh is for a first time tripwire setup. It would also be useful for a user who wants to change passphrases, or deviate from the triwpire default configuration directory and file names, but generally, twsetup.sh is a "use once then forget you ever had it" proposition. It won't do any harm to run it, it just has a longer cycle and repeats steps that are unnecessary once tripwire has been setup. I've run it a few hundred times here, on a machine that is "clean of tripwire," but that was to debug the thing. I run "tripwire --update" (using an alias that finds the correct report file) as often as I add and update packages. Happens to be each Sunday, because I emerge-sync and emerge -uDN world on Saturdays. Once in awhile a package will remove a file, and I'll get the tripwire WARNING message, file not found. Then I run mktwpol.sh -u to generate a fresh policy and database. I tried tripwire's "update policy" function, and it fails. That's why mktwpol.sh just uses tripwire's --init (new database) function. So, quick summary of rate of usage expectations: tripwire --update ... most often. Whenever there is a flagged change that you know the cause of. mktwpol.sh -u ... not very often. Only when tripwire throws a WARNING about file not found (and you know the cause of the file being removed) twsetup.sh ... one shot. If you have no key files, no encrypted tw.cfg, and no tripwire database, use this to get started.
(In reply to c.cboldt from comment #38) > (In reply to Marckus J. from comment #36) > > > So I will run mktwpol.sh with -u manually. > > One other remark ... if you have tripwire setup already, meaning you have > the key files and a tw.cfg file and have made a tripwire database (defaults > to /var/lib/tripwire/$HOSTNAME.twd), then you probably have no need for > twsetup.sh. I've changed the twsetup.sh logic for the next release. When it finds a tw.cfg (implying that tripwire keys exist and have been used to make the encrypted tw.cfg file), and tw.cfg is newer than twcfg.txt (implying that the user has not decided to change the tripwire configuration), twsetup.sh asks the user if he wants to update tripwire (vs. install tripwire the first time or with a new tripwire configuration). If the reply is "Y", then twsetup.sh skips the "make keys" and "encrypt tw.cfg" steps, and continues similar to invoking 'mktwpol.sh -u`. This way, a user who has a working tripwire setup and remembers the twsetup.sh command can get to the outcome most likely desired, without having to type `mktwpol.sh -u` at the command line. I've pondered methods for detecting mktwpol/twsetup mismatches, like the one that caused the behavior you reported, but so far have not come up with a good solution. Did you by chance have two versions of mktwpol.sh on your system? Or did you grab a twsetup.sh from the "code" section of SourceForge, rather than from a tarball release package?
No I grabbed the tar.gz (version 0.1.5 at the time) and ran twsetup.sh on a fresh tripwire installation and mktwpol.sh on a server that had tripwire configured previously. I'll send you an email so that we can take this off the bug tracker, we've digressed heavily from the original 10 year old bug report. :-)
