Proposed changes following beta 0.1.0

[cboldt]

As typical, once a project is put out, the author finds things that ought to change. Putting this project on git/sourceforge caused quite a bit of tripwire detection activity on my system (that's a good thing), as I made a folder off the /usr/local/sbin directory as my local git repository for the project.

Rather than see this activity, I thought adding an IGNORLST[] for /usr/local/sbin/mktwpol, in a mktwpol.cfg file, would be in order. It is in order, but re-reading the manpage for twpolicy, I see that the "!" ignore prefix is called a "stop point." Stop points can act on individual files, but they also act on directories and directory trees.

The phrasing in the script, that an IGNORLST[] covers files, is misleading as to the effect of a stop point. I added an item in the TODO list, to rename the IGNORLST[] variable (to STPPOINT) and change the remarks pertaining that variable. Changing the variable name would be a radical change if there were many instances of the variable in external mktwpol.cfg files. My belief is that nobody has created an external mktwpol.cfg file that contains an IGNORLST[] variable assignment, and this change can be made with nothing more than a passing remark.

[cboldt]

Substantive changes from release 0.1.0 to 0.1.1:

• the IGNORLST variable was changed to STOPLIST
• the release tarball unpacks in its own (mktwpol-0.1.1) directory. My apologies for having the 0.1.0 tarball unpack in the parent directory

In addition to adding any packagenames, changes that will appear in a future 0.1.2 release are:

• tidying up a few comments in the script files
• removing repetetive date indications in the CHANGELOG
• clarifying information in the example mktwpol.cfg in the README file
  • accomodating distributions other than Gentoo is only possible with the mktwpol-generic.sh script
  • include as an example, the use of STOPLIST in the "OS Bin and Lib Directories" rule as: STOPLIST[25]="/usr/local/sbin/mktwpol/.git"

[cboldt]

Many changes going from 0.1.1 to 0.1.2, mostly adding twsetup.sh, a script to nstall tripwire from a Gentoo installation and defaults. twsetup.sh was changed substantially going from mktwpol.sh-0.1.2 to 0.1.3 (twsetup.sh has its own revision level, confusing, I know), and views the possibilities of a tripwire installation as ranging from literally nothing (no directories, let alone an instllation and set-up that provides suggested tripwire config file, etc.), to stepping in to revamp/correct/modify a preexisting installation. Installing into a partially set-up situation (as most distributions provide) is somewhere between those two extremes. Plenty of possible set-up permutations involved in that range. I tried to anticipate and test all of them, although I'm sure I missed some. Found a few by accident, running the script to test one feature, and it choked because it failed to accommodate a fairly likely system precondition.

I tested the exotic possibility of using twsetup.sh to make multiple tripwire set-ups on one system. twsetup.sh had to be changed considerably to knock out the twadmin and tripwire errors that crop up when tripwire assumes default config location (/etc/tripwire/tw.cfg). twsetup.sh has switches to make it easy to set-up in non-standard/non-default directories, for anybody so inclined. I don't see any purpose in that, and probably made the script that flexible "just because." I assume most users will just go with the tripwire defaults.

twsetup.sh has a couple of undocumented command line parameters too, undocumented becuse they can't be recommended. One, "debug sub_routine", was useful as different parts of the script were being tested. The other is "null_passphrase" which makes for a relatively insecure tripwire installation, but also skips past the usual "Input Passphrase" prompts from twadmin and tripwire.

I considered making the "-r" switch the default condition. That would have twsetup.sh delete the plain-text config and plain-text policy files after encrypting them. Might as well delete them because they are easy to recreate from the encrypted working files. On the other hand, some users would wonder where those file were/went, and I eventually decided that the default should be to leave them in place. Anybody who is installing tripwire knows how to use the rm command.

Barring bug reports or confusion on the part of users or constructive criticism, I don't see a 0.1.4 release in the near future.

[cboldt]

Well, there was a 0.1.4 release pretty soon after 0.1.3. Most changes are in twsetup.sh, and accommodate use of twsetup.sh -without- resort to a plain-text policy generator. That might be useful for a person or distro that wnts to use a plain text policy configuration without using mktwpol.sh. I used the "-b" switch in twsetup.sh (bypass plain-text policy generator) to test a few different plain-text policies shipped with the tripwire tarball. twsetup.sh was modifed to gracefully handle error reports from twadmin, if the plain-text policy file has fatal errors.

mktwpol.sh was modified to notice it is not on a Gentoo system, and tells the user that it can't find the installed packages database, to seek out mktwpol-generic.sh, and that it (mktwpol.sh) is going to resort to the latest plain-text policy file found in the tripwire install directory, usually /etc/tripwire, for processing.

NOW I think the package is in reasonably good shape. I have made some wordsmithing changes since releasing 0.1.4, but nothing substantive. A 0.1.5 won't come out any time soon unless a bug is discovered.

[cboldt]

And, a massive bug was discovered. Discussed over in "Bugs" forum, but generally, uses of mktwpol.cfg to set any RULE changes are doomed. Pondering that mktwpol.sh (and twsetup.sh) "source" the config files, I became concerned that somebody could insert random commands into the config file, and the random command would be run. I tried it, inserted an ls command, and it ran just like it was supposed to.

So, the scripts now insist that the mktwpol.cfg file be permissions 600, and owned by root. No help if your box has been rooted, but it should prevent the locals from causing mayhem. I assumed that the directory where the config files were stored is NOT secure (although it should be) because I know that at least Gentoo has 755 permissions on /etc/tripwire.