integrit-users — mailing list for discussion of issues related to using integrit

[Integrit-users] Re: integrit comilation help

[Ed L C. <ec...@te...>]

(Copied to integrit-users mailing list.  See
http://sourceforge.net/mail/?group_id=15369 to subscribe.) 

alb...@cr... writes:

> Hello Mr Cashin,

Hi!  I am taking a work break.

> I'm very interested to use your program. I found your program by
> Google search.  I'd like to use it in a win32 environment.  I know
> nothing about any computer language and i have some difficulties to
> make your program work.
>
> Integrit has to be compiled ( i understood that :-) ) but i don't
> know what comilation program i need and wich libraries.  Excuse me
> to bother you with this question, i don't want you to teach me unix
> in a nutshell; but i would appreciate much if you could give me this
> "clue".

You are right that integrit (at least as distributed by me) must be
compiled first.  I'll try to give you some pointers that will help you
to find the information you need:

  integrit follows many GNU software guidelines, so building it
  consists of these steps:

    * download compressed tar file

    * un-gzip and un-tar the file using the gzip and tar tools

    * enter the new integrit-2.02 (or whatever) directory

    * read the README and INSTALL files

    * proceed

  The build process is done for you by a script called "configure" and
  the make tool.

  I always compile integrit with gcc and GNU make, so these are some
  tools that you can get and learn about:

    * gcc - the GNU compiler collection; a free set of compilers,
      including a C compiler (integrit is written in the C programming
      language)

    * GNU make - make is a tool that coordinates all of the complex
      steps in building software.  (also free)

  Along the way, texinfo documentation will help you.  If you have
  info installed, you can type the command, "info", to start viewing
  the documentation.  It will tell you about gzip, tar, make, gcc,
  etc. 

> Last but not least : will integrit work in win32 environment ?

I haven't tried it.  Since you aren't familiar with building
UNIX-style software, it might be frustrating to try to build it in
Windows.  There are, however, some people who excel at building UN*X
style tools on Windows:

  http://www.delorie.com/djgpp/

And there's cygwin, which I'm less familiar with but which is gaining
popularity:

  http://sources.redhat.com/cygwin/

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] abort on opendir fail (was Possible issue with integrit)

[Ed L C. <ec...@te...>]

"James.FitzGibbon" <Jam...@ta...> writes:

> I've discovered a way that an attacker might get around integrit.
> 
> When integrit is walking a file tree, it will stop dead if it
> encounters a directory that it cannot traverse:

I don't agree that it's a way an attacker could get around integrit,
but I do think that printing a warning message and continuing might be
more helpful behavior.

What do folks think?  Originally, I thought that integrit would only
be used on system-critical areas of the filetree, and root would
control the permissions on all the files.  I know that people are
using integrit on other areas like /home, so I now think that it would
be better for integrit to warn and continue.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] Possible issue with integrit

[James.FitzGibbon <Jam...@ta...>]

I've discovered a way that an attacker might get around integrit.

When integrit is walking a file tree, it will stop dead if it
encounters a directory that it cannot traverse:

> mkdir home/prod/.A
> chmod 000 home/prod/.A
> integrit -C integrit.conf -c
integrit: ---- integrit, version 2.01 -----------------
integrit:                      output : human-readable
integrit:                   conf file : integrit.conf
integrit:                    known db : integrit.cdb
integrit:                  current db : integrit.cdb.new
integrit:                        root : home/prod
integrit:                    do check : yes
integrit:                   do update : no
changed: home/prod   l(2:3) m(20010725-085631:20010725-085801)
c(20010725-085631:20010725-085801)
Error: cannot open directory (home/prod/.A): Permission denied
integrit (main): Error: walk_file_tree: Permission denied

So if someone is running integrit in some fashion like this:

integrit -C config.file -c -x > foo.xml && parse_xml && mail_output

Then an attacker can prevent integrit reports from being mailed by just
creating a directory in the hierarchy that cannot be traversed.

Granted, any on-the-ball sysadmin would notice that they weren't getting
an integrit report for a given host and check things out, but in a large
environment it's easy to lose one mail and that could give an attacker an
entire day to play around, make the machine a staging platform for further
attacks, then remove the offending directory.

This should be simple just by having integrit continue walking the
tree when opendir() fails instead of quitting.  It might also be advisable
to log this as a change event, but I'm not sure if that truly entails
extending integrit's view of a directory to include its attributes
as well as the ability to cd into it.

-- 
j.

James FitzGibbon                       voice/fax 612-761-6121/3148 
Consultant, TTS-3D@TPN7Z               jam...@ta...

[Integrit-users] ANNOUNCE: integrit-2.01 stable release

[Ed L C. <ec...@te...>]

I'll announce it on Freshmeat soon.  The stable release is out.
Thanks to everyone who helped.  This release has mostly fixes and
enhancements to the build process.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] ANNOUNCE: integrit-2.00.00-beta

[Ed L C. <ec...@te...>]

Hi, all.  If anyone here has a debian system, please consider testing
Andras Bali's .deb package for integrit version two, letting him know
how it goes.  Thanks!

Andras BALI <dr...@bi...> writes:

> On Wed, Jun 20, 2001 at 08:10:25PM -0400, Ed L Cashin wrote:
> 
> > This is the initial release of integrit version two.  When this beta
> > has earned its stripes, I'll brag more about what's new, but here's a
> > quick listing, with the one's people asked for listed first.
> 
> Great news! I've packaged it, the .deb is now currently being uploaded
> to <http://pandora.debian.org/~bali/>. I'd like to have the package
> thoroughly tested before uploading it to the main distribution (if
> you know debian integrit users, could you please ask them to test it?).
> 
> I've had to modify the makefiles a bit because they didn't clean up
> everything. I've attached a diff for it.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] Comparisons of Integrit with Tripwire and AIDE

[Ed L C. <ec...@te...>]

Bru...@na... writes:

...
> So basically, in your opinion, what does Integrit do better than the
> other two?

Oh-- and I also find it more convenient because the output is easier
to read quickly and the configuration is simple and easy.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] Comparisons of Integrit with Tripwire and AIDE

[Ed L C. <ec...@te...>]

Bru...@na... writes:

> I've just found out about Integrit and was wondering why I would use it instead
> of Tripwire or AIDE?
> It seems to perform exactly the same functions
> So basically, in your opinion, what does Integrit do better than the other two?

The web page (integrit.sf.net) states the main reasons.  integrit is
for people who need a product that uses less memory at runtime (in
version two of integrit you can even turn off mmap to save more
virtual memory) or is less complex.

Using less memory means that integrit can be used on production
machines, and being less complex means that more of your peers will be
willing to use integrit.  (And you'll need less time to learn how to
use it; and integrit won't be as buggy, since it's simpler ...)

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] Comparisons of Integrit with Tripwire and AIDE

[<Bru...@na...>]

I've just found out about Integrit and was wondering why I would use it instead
of Tripwire or AIDE?
It seems to perform exactly the same functions
So basically, in your opinion, what does Integrit do better than the other two?

__________________________________________________________________________
The information contained in this email communication may be confidential. You
should only read, disclose, re-transmit, copy, distribute, act in reliance on or
commercialise the information if you are authorised to do so. If you are not the
intended recipient of this email communication, please notify us immediately by
email to NA...@na... or reply by email direct to the sender
and then destroy any electronic or paper copy of this message.  Any views
expressed in this email communication are those of the individual sender, except
where the sender specifically states them to be the views of a member of the
National Australia Bank Group of companies.  The National Australia Bank Group
of companies does not represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free of errors,
virus or interference.

[Integrit-users] ANNOUNCE: integrit-2.00.00-beta

[Ed L C. <ec...@te...>]

The following message is a courtesy copy of an article
that has been posted to uga.tech.linux as well.

This is the initial release of integrit version two.  When this beta
has earned its stripes, I'll brag more about what's new, but here's a
quick listing, with the one's people asked for listed first.

I'll update the integrit.sf.net webpages later to reflect the changes.
Here are the links for getting the latest version:

links:

  http://sourceforge.net/project/showfiles.php?group_id=15369  
  http://www.terry.uga.edu/~ecashin/integrit/download/

list of notable changes:

  Added feature: non-inherited checksets.  Now if there's a directory
  (like /etc on RedHat) that requires special treatment that doesn't
  percolate into the directory's files and subdirectories, you can
  prefix the rule with a dollar sign to signify that the rule does not
  cascade.  You can have both a cascading and a non-cascading rule for
  any given directory.

  Added feature: now known and current databases can be specified on
  the command line, overriding the settings in the configuration file.
  This feature is for sysadmins who want to use the same configuration
  file on many similar hosts.

  Removed cdb-0.75 from integrit.  integrit now uses its own cdb
  routines and some modified versions of DJB's public domain source
  files.  This eliminates some hairy licensing issues without
  effecting integrit's operation.

  New feature: lowering the verbosity level with "-q" eliminates the
  pre-amble in the human-readable report.

  integrit's use of openssl has been removed.  integrit now uses md5
  and sha1 checksums adapted from those of gnupg-1.0.6.
  
  Added build feature: you can change the maximum file size that will
  be mmap'ed with a configure option.  Specifying a maximum of zero
  means that mmap won't be used.  You can conserve virtual memory this
  way.

  The build process is more sophisticated.

  Added build feature: configure option for specifying install script
  to use if autoconf finds one that doesn't really work (e.g., Stata's
  "install" program was in my path once).  Updated hashtbl's "make
  install" stuff to use install.

  The hashtbl library: two related new features: a "foreach" feature,
  where a callback can be executed on each element in the hash table,
  and an optional "destroy item" callback.

  The callback for destroying items allows the caller to store complex
  data structures in the hash table and then pass a pointer to a
  specialized cleanup routine to hashtbl_free.

  Auxiliary tools now build properly with leak detection turned on.

Solaris users please read the README.Solaris file if you have trouble
during "make".

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] integrit version two plans

[Ed L C. <ec...@te...>]

This message is an update on upcoming changes to integrit.

CDB:

Andras Bali, the maintainer of the integrit debian package, has been
talking to the Debian folks about some licensing issues.  It seems
that the vague license that Dan J. Bernstein put on his CDB package
(the package integrit uses to read and write databases) is problematic
for those who would distribute integrit packages.

The problem is that the package is kind of a "derived work", and
integrit's GPL specifies that works derived even partially from
integrit must be distributed under the GPL.  

The debian folks noticed that integrit wasn't compiling on the GNU
hurd platform because of a bug in CDB, and so far there's been no
response from Dan Bernstein about the bug.  That means that Andras
Bali would like to patch cdb as part of the build process, but
that leads to even more licensing hairiness.

The good news is that key parts of cdb are "public domain", so I can
use those parts in integrit, writing whatever extra code is necessary
to fill in the gaps.  This will make integrit free from licensing
issues from the packagers' point of view.

OPENSSL:

The GNU Privacy Guard, gnupg, has free (GPL'ed) implementations of MD5
and SHA-1, so integrit version two should no longer depend on openssl
for its crypto code.  

Not requiring a properly-installed static openssl crypto library is a
big win, since this was a major stumbling block for many users
(including me, on occasion!)

FEATURES:

If I have time, I may add a couple features: the "no-cacading" option
and maybe command-line database specification.  But who knows.  I'm
trying to be really minimal in the features camp, but the no-cascade
option is going to be a big help.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] Re: Integrit

[Ed L C. <ec...@te...>]

Darrell Golliher <da...@cx...> writes:

> Date: Tue, 5 Jun 2001 16:08:28 -0400
> From: Darrell Golliher <da...@cx...>
> X-Mailer: Mutt 1.0.1i
> To: int...@li...
> Subject: grep -v
> 
> 
>   There are a number of patterns of files that I don't care about in
>   the report from integrit.  The simple solution for me is to run the
>   output of integrit through grep -v which is akin to what
>   logcheck.ignore does for logcheck.
> 
>   Seems a lot easier to me that excluding every user's ~/.bash_history
>   file with it's own !/home/jsmith/.bash_history line in the integrit
>   config file.
> 
>   I was wondering how the rest of you deal with excluding patterns of
>   files as opposed to specific files or whole directories.

So far I've found that those kinds of problems don't usually occur
when you're checking the system.  If you know that your system
binaries, "find", "ls", etc., haven't been trojaned, then there's
usually no need to check home directories, web document trees, etc.

But, yes, grep is the kind of thing I was *expecting* users to have
and use.  It keeps integrit simple.  You can even put your "ignore"
regular expressions in a file and do this in procmail (untested):

  :0 :hosty-reports.lock
  * ^Subject: hosty integrit report
  | grep -v -f hosty.ignore > mail/hosty-reports

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] Integrit: Small Fast Checks & Small Conf Files?

[Ed L C. <ec...@te...>]

Marc Wallman <ma...@so...> writes:

> I'm new to integrit so please excuse me if this question is a newbie
> one (I tried to do my research before posting, really).
> 
> I'd like to frequently run a small check on a few files/directories
> (e.g. /etc/passwd, /etc/hosts.allow, /etc/hosts.deny, /usr/bin/, 
> /usr/sbin/,...).  Because I'm forced to specify a root directory that 
> recursive checking starts from, I've found I need to create a really 
> big config file with alot of !'s and ='s to prevent integrit from
> recursing to directories I don't want checked.
> 
> Is there a way to explicitly specify only those files/dirs I want
> checked so I can create a small conf file? Perhaps I'm missing
> something here. 

You can run integrit more than once, using a different config file for
each root you want checked.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] Integrit: Small Fast Checks & Small Conf Files?

[Marc W. <ma...@so...>]

I'm new to integrit so please excuse me if this question is a newbie
one (I tried to do my research before posting, really).

I'd like to frequently run a small check on a few files/directories
(e.g. /etc/passwd, /etc/hosts.allow, /etc/hosts.deny, /usr/bin/, 
/usr/sbin/,...).  Because I'm forced to specify a root directory that 
recursive checking starts from, I've found I need to create a really 
big config file with alot of !'s and ='s to prevent integrit from
recursing to directories I don't want checked.

Is there a way to explicitly specify only those files/dirs I want
checked so I can create a small conf file? Perhaps I'm missing
something here. 
--

Marc Wallman
Academic Computing Services
University of California at Berkeley
ma...@so...

[Integrit-users] Re: Integrit: How to check just the md5?

[Rene D. <rdu...@ho...>]

There's a man page?  oops :)

Thanks for your reply.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

[Integrit-users] Re: Integrit: How to check just the md5?

[Ed L C. <ec...@te...>]

"Rene Dudfield" <rdu...@ho...> writes:

> Hi,
> 
> Just a integrit question...

(I'm sending a copy of this message to the integrit-users mailing
list.  See: http://sourceforge.net/mail/?group_id=15369)

> Can I get integrit to tell me if an md5/checksum of a file has changed?

No.  One of the design decisions was to stick with SHA-1 because
that's all that's necessary to do what integrit has to do: record and
verify what a file is like.  

You do get an MD5 sum at the end of the integrit report, but that's
for convenience, since most people have the tool "md5sum" or can use
"openssl md5" to find an MD5 checksum for a given set of files.  

> I've got a backup of when the computer was installed(just using tar).
>
> Is there a way I can get integrit to tell me if a file has a different
> checksum from the one in my backup?

I don't think integrit is the tool you're looking for.  You could
probably do something like this, if the backup is a tar:

  tar xf /dev/tape filename | openssl md5

  tar cf - /path/to/file | tar xf - | openssl md5

Test it out, though.  A little test I just did shows that technique
might work:

  ecashin$ echo test > /tmp/testfile
  ecashin$ echo test > /tmp/testfile2
  ecashin$ cd /
  /$ tar cf - tmp/testfile | tar xf - tmp/testfile | openssl md5
  d41d8cd98f00b204e9800998ecf8427e
  /$ tar cf - tmp/testfile2 | tar xf - tmp/testfile2 | openssl md5
  d41d8cd98f00b204e9800998ecf8427e
  /$ chmod 640 tmp/testfile
  /$ tar cf - tmp/testfile | tar xf - tmp/testfile | openssl md5
  d41d8cd98f00b204e9800998ecf8427e


> I'm not real sure how to read the output of integrit.
> 
> What do each of the sections mean?  Looked through the doco, and
> couldn't find an explanation.

The web docs and the man page go into the output syntax in detail.
Did you do "man integrit"?

> Here's one of the output lines:
> 
> changed: /home/rene/durweb/usr//bin/fdumount   i(993695:32332)
> m(20010605-123126:20010502-180639) c(20010605-123126:20010502-180639)
> 
> i(...:...) is inode?

That's a good guess, and is correct.

> m(...:...) is md5??
> No idea what c(...:...) is.

Modification time and change time respectively.  Find that man page!
  :)  You're looking for the part that says, "Here's a table of
letters and the corresponding checks/options."

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] cannot install coreldraw-win32 ...?

[willow <sla...@zg...>]

Have a 233 Mhx,64 Ram,win98SE
Cannot install Corell,photoshop

THANKS!

[Integrit-users] Re: "Generating / creating state databases"

[Ed L C. <ec...@te...>]

Angisetty Eswar Prasad <aep...@us...> writes:

> Hi,

> I have compiled and installed integrit version 1.06 on solaris 2.6/
> sparc . I would like to know how I could generate or create the
> state databases.

> I tried using the following commands but without much help. I am
> sure, that i might be doing something wrong and could not find much
> documentation on it. I will appreciate if you could send me some
> samples of how the state databases are generated.
>
> #integrit -C known=/usr/local/database/known_state.cdb -u
> integrit (options_set): Error: opening conf file: No such file or directory
> 
> #integrit -C /usr/local/database/known_state.cdb -u
> integrit (options_set): Error: known database unspecified

Oh, you are close, but it looks like you have misinterpreted the docs
a bit.  From the integrit manpage:

       integrit -C conffile [-x] [-u] [-c]

...

       -C       Specify  conffile  as  the configuration file for
              integrit.

 
... so the argument to the -C option should be the filename of your
configuration file.  The known and current database names are set
*inside* that configuration file.

The command will look something like this:

  # integrit -C /mnt/cdrom/integrit-boop.conf -u

... where integrit-boop.conf is your configuration file on a CD-ROM. 

Feel free to subscribe to the integrit-users mailing list:

  http://sourceforge.net/mail/?group_id=15369

It's a very low-traffic list, and there are more integrit users there
to help you if you need it.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] Re: integrit suggestions

[Ed L C. <ec...@te...>]

(copied to integrit-users, see sourceforge.net/projects/integrit for
subscription information)

Andras BALI <dr...@bi...> writes:

> Hi,
> 
> during the packaging of integrit into Debian I discovered a few
> imperfections in the application and I'd suggest you to put these
> on the todo list:

Hi, I appreciate your suggestions, but I decided against doing those
things at integrit's inception.  integrit is an alternative to
software that tries to do everything.

> * specificiation of the path using regular expressions is really
>   missing, since it's now nearly impossible to make configuration
>   files that are both secure and usable on all systems;

With integrit you don't use regular expressions.  In aide, I found
that the regular expressions didn't work, and in real life, I find
that I don't need regular expressions at all.  It might mean using a
couple of lines instead of one, but it's not really something I would
wish for.

> * perhaps the database could be compressed so it wouldn't take up
>   that big disk space;

I looked into that.  The solution was a compromise: to use cdb, which
makes databases that are much smaller than Berkley databases.  

> * the human-readable output should be a bit more human readable (and
>   the lines do not need to be prepended with "integrit").

The current form is the most easy to scan that I've seen.  I worked
with other folks in finding this form.  If you look at the output,
only some of the lines have the prefix "integrit:" others have
different prefixes like, "changed: ", as documented in the man page.

I did consider switching from showing numerical user and group ids to
showing the textual name, e.g., "ecashin", instead of "500", but it
wasn't as readable.

Thank you for your input.  A couple of things that *are* on the todo
list: 

  * make a configuration file syntax for checksets that are not
    inherited.  This will help with rules for ignoring directory
    modification and change times without affecting the subdirectories
    and files under that directory.

  * provide command line options for specifying the databases,
    overriding the configuration file

  * implement MD5 and SHA-1 to get rid of openssl dependency.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] Re: integrit

[Ed L C. <ec...@te...>]

"Cott Lang" <co...@in...> writes:

...
> That would save me at least 80 config files while still letting me
> have every machine use an identical command line/script. :)

Yes, the convenience is significant in your case.  I'm sure there will
be many similar cases.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] Re: integrit

[Ed L C. <ec...@te...>]

"Cott Lang" <co...@in...> writes:

...
[ed writes]
> > What do the others think?  Is it worth making the command-line options
> > more complex in order to accomodate cases like this where the
> > configuration would be identical save the database specifications?
>
> Why would it make the command line more complex unless the user
> desired this functionality?

The command line is an interface between the user and integrit.  By
adding two options, we make that interface 33% fatter.  That is the
complexity I was referring to.  The fatter interface makes integrit
more difficult to learn.

Even if the user doesn't want to use or learn the options, when they
open up the man page, they see lots of options, and they have to take
the trouble of discerning the options they need from the rest.

The extra code to support the options is another thing: code
complexity, and it makes integrit just a wee bit less simple and
maintainable.  That's the issue in a nutshell.

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

[Integrit-users] Re: integrit

[Cott L. <co...@in...>]

> This was a concious trade off between complex convenience and
> simplicity.  The current solution is, as you guessed, to have twenty
> configuration files -- looks messy but is trivial to generate with
> UN*X tools like sed, awk, perl, sh, etc.

But not as trivial as changing an optional command line option. :)

> What do the others think?  Is it worth making the command-line options
> more complex in order to accomodate cases like this where the
> configuration would be identical save the database specifications?

Why would it make the command line more complex unless the user desired this
functionality?

>   /mnt/secsrv/integrit -C /mnt/secsrv/general.conf \
>     -k /mnt/secsrv/known-`hostname`.cdb \
>     -n /root/current.cdb
>
> ... since "-c" is already taken, the "-n" (for "new") option would
> specify the location of the current-state database.
>
> That's eight command-line options total.  Databases would be required
> in config files only if not listed on the command line.  Command line
> database options would override config file database specifications.

That would save me at least 80 config files while still letting me have
every machine use an identical command line/script. :)

thanks!

Re: [Integrit-users] Re: integrit

[<lie...@pa...>]

I would prefer multiple configs myself...

On 14 Mar 2001, Ed L Cashin wrote:

> (Cc'ed to the integrit-users mailing list.  To join, see:
> http://sourceforge.net/mail/?group_id=15369)
> 
> "Cott Lang" <co...@in...> writes:
> 
> > First let me say - excellent program. :)  I've been wanting an open source
> > Tripwire like program for a while, but don't have much free time to
> > implement one.  Integrit works great!
> 
> Thank you very much for the input.  :)  
> 
> > I have only one suggestion.
> > 
> > I maintain large farms of servers... and to me, unless I'm missing
> > something, there's one major shortcoming. That's specifying the database
> > names INSIDE the config file.  That way, you just use the same config file
> > for every machine in a 20 machine farm with separate databases.  If there
> > was just some way to specify
> > known and current databases on the command line instead of the config file,
> > this would work perfectly. :)
> > 
> > Please tell me if I'm an idiot and am missing a way of making this work in
> > the current rev... :)
> 
> No, you are correct, if you mean that because each host must read from
> its own database then each host must have a separate configuration
> file.
> 
> This was a concious trade off between complex convenience and
> simplicity.  The current solution is, as you guessed, to have twenty
> configuration files -- looks messy but is trivial to generate with
> UN*X tools like sed, awk, perl, sh, etc.
> 
> What do the others think?  Is it worth making the command-line options
> more complex in order to accomodate cases like this where the
> configuration would be identical save the database specifications?
> 
> My initial reaction is always conservative, since the two main design
> goals are simplicity and a small memory footprint, and since UN*X
> tools can provide the flexibility that might otherwise be achieved by
> making integrit more complex.  
> 
> The assumption is that the simplicity will naturally lead to
> convenience, since integrit is a new tool to learn, but users will
> already know perl, Bourne shell, or awk ... that's my first reaction,
> but just thinking ...
> 
>   /mnt/secsrv/integrit -C /mnt/secsrv/general.conf \
>     -k /mnt/secsrv/known-`hostname`.cdb \
>     -n /root/current.cdb
> 
> ... since "-c" is already taken, the "-n" (for "new") option would
> specify the location of the current-state database.  
> 
> That's eight command-line options total.  Databases would be required
> in config files only if not listed on the command line.  Command line
> database options would override config file database specifications.
> 
> With that many command-line options, long-style options might be
> necessary.  
> 
> -- 
> --Ed Cashin                   PGP public key:
>   ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/
> 
> 
> _______________________________________________
> Integrit-users mailing list
> Int...@li...
> http://lists.sourceforge.net/lists/listinfo/integrit-users
> 

[Integrit-users] Re: integrit

[Ed L C. <ec...@te...>]

(Cc'ed to the integrit-users mailing list.  To join, see:
http://sourceforge.net/mail/?group_id=15369)

"Cott Lang" <co...@in...> writes:

> First let me say - excellent program. :)  I've been wanting an open source
> Tripwire like program for a while, but don't have much free time to
> implement one.  Integrit works great!

Thank you very much for the input.  :)  

> I have only one suggestion.
> 
> I maintain large farms of servers... and to me, unless I'm missing
> something, there's one major shortcoming. That's specifying the database
> names INSIDE the config file.  That way, you just use the same config file
> for every machine in a 20 machine farm with separate databases.  If there
> was just some way to specify
> known and current databases on the command line instead of the config file,
> this would work perfectly. :)
> 
> Please tell me if I'm an idiot and am missing a way of making this work in
> the current rev... :)

No, you are correct, if you mean that because each host must read from
its own database then each host must have a separate configuration
file.

This was a concious trade off between complex convenience and
simplicity.  The current solution is, as you guessed, to have twenty
configuration files -- looks messy but is trivial to generate with
UN*X tools like sed, awk, perl, sh, etc.

What do the others think?  Is it worth making the command-line options
more complex in order to accomodate cases like this where the
configuration would be identical save the database specifications?

My initial reaction is always conservative, since the two main design
goals are simplicity and a small memory footprint, and since UN*X
tools can provide the flexibility that might otherwise be achieved by
making integrit more complex.  

The assumption is that the simplicity will naturally lead to
convenience, since integrit is a new tool to learn, but users will
already know perl, Bourne shell, or awk ... that's my first reaction,
but just thinking ...

  /mnt/secsrv/integrit -C /mnt/secsrv/general.conf \
    -k /mnt/secsrv/known-`hostname`.cdb \
    -n /root/current.cdb

... since "-c" is already taken, the "-n" (for "new") option would
specify the location of the current-state database.  

That's eight command-line options total.  Databases would be required
in config files only if not listed on the command line.  Command line
database options would override config file database specifications.

With that many command-line options, long-style options might be
necessary.  

-- 
--Ed Cashin                   PGP public key:
  ec...@te...       http://www.terry.uga.edu/~ecashin/pgp/

Re: [Integrit-users] Re: Inheriting of options in integrit is causing me a problem

[Matt H. <ma...@ni...>]

> So far, switches go at the right and special treatment directives go
> at the left, like this:
> 
>   =/var/somedir CM
> 
> To be consistent, the new token should go before the filename.
> 
> ...

My thinking for my suggestion was: Under unix tho' "." refers to the
directory node, which is why I thought that if you used "/var/somedir/."
it would be clear(ish) that it referred to the directory precisely
(given you can refer to a directory like that).

The = and ! modifiers are clear in terms of what they do... From my
"external users" perspective, I'd not find a . prefix to be so clear.
Maybe it's worth canvassing some other opinions on which they find
clearer :). I'm not too bothered either way, as if it's documented I can
understand it, just thought I'd explain the thinking behind my
suggestion.

Matt

Re: [Integrit-users] Re: Inheriting of options in integrit is causing me a problem

[Ed L C. <ec...@co...>]

Matt Hoskins <ma...@ni...> writes:

...
[ed writes]
> > I was wondering how long it would take for someone to remark upon this
> > inconvenience.
> 
> Pesky users, eh?

;) No, two of the last few comments have been things that I remarked
upon myself but didn't want to fix until I knew the need was not
confined to just me.

> > I agree that this feature would merit the increased complexity of an
> > additional token in the config file syntax.  A dot at the beginning of
> > a rule could mean, "don't inherit -- rule applies to this file
> > (specifically, directory) only".

I meant like this (using your example below):

  /var/somedir SP
  ./var/somedir pCM
  /var/somedir/somefile p

I like that the dot already means "this directory", but now that I
look at it, I don't like the fact that it looks like it would be
"`pwd`/var/somedir".  Some other token would work better.  

A dollar sign is good in that it means "the end" in ed, vi, sed, etc.,
and in regular expressions, so it would be natural to associate with a
rule that doesn't descend further into the file tree.

  /var/somedir SP
  $/var/somedir pCM
  /var/somedir/somefile p

> If you had some options you also wanted inherited tho', that needs
> to be accounted for. Another syntax possibility that springs to mind
> is to use a .  in the pathname to specify an override for the
> directory... so you could have (in a slightly contrived example):
>
> /var/somedir SP
> /var/somedir/. pCM
> /var/somedir/somefile p

So far, switches go at the right and special treatment directives go
at the left, like this:

  =/var/somedir CM

To be consistent, the new token should go before the filename.

...
> I'd heard of tripwire, and did have a glance at that (as well as
> another alternative, which I think might have been aide). I found
> integrit more accessable tho' (ie easier/quicker to get up an
> running with).

One good thing about tripwire is that the docs impress a really good
sense of paranoia on you that tends to help you notice security
problems more easily.  So even if you're an integrit user you might
benefit from giving the tripwire docs a read.

-- 
--Ed Cashin                    integrit file verification system
  ec...@co...          http://integrit.sourceforge.net/