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

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

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

> (Cc'ed to integrit-users mailing list.  See URL for subscription info:
> http://sourceforge.net/mail/?group_id=15369)

Now subscribed.

> I was wondering how long it would take for someone to remark upon this
> inconvenience.

Pesky users, eh?

> 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".

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 the /var/somedir itself inherits the options specified by the first line,
but they can be overridden for just the directory by the explicit reference
(and the file on the third line inherits from the first line o' course, as
with the old style).

> It was worth it to get to use it!  ;)  But I'm glad other people get
> to use it too, and I'm glad that you like it.

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).

Matt

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

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

(Cc'ed to integrit-users mailing list.  See URL for subscription info:
http://sourceforge.net/mail/?group_id=15369)

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

> I've installed integrit on a debian box, and have got several
> configuration files for covering parts of the directory
> structure. The one I'm having problems with is the one that checks
> /etc. The reason is that I want to ignore changes to mtab (so I can
> remount the floppy read only, and a couple of other root users can
> do nfs mounts if they need to) without me getting warned about it. I
> put in !/etc/mtab, which is all well and good... However
> mounting/unmounting on this machine uses mtab~ and mtab.tmp as a
> lock file and temporary file, which causes the "file info change
> time" and "modification time" of the directory itself to change. So
> I'd like to not do those checks just for the /etc directory. My
> reading of the config file format implies tho' that I can't easily
> do that. If I set the switches on /etc to not do these checks, these
> switches will then be inherited by all the files and subdirectories
> under etc, which is not what I want.

You are quite correct.  This was a tradeoff based on my own
experience.  I like the inherited rules, but the price is that in
cases like the one you mention, you have to explicitly list the
exceptions, and some benign changes on directory "m" and "c" show up
in the report.

I was wondering how long it would take for someone to remark upon this
inconvenience.  

> If I'm correct in what I've said above (and haven't missed something
> obvious), it would be nice if there were a way to additionally
> specify flags which are just for the directory node which aren't
> inherited (in addition to ones which are), so I can get around this
> problem (it would probably be useful in general for directories
> which get temporary files created in as part of processes).

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'll look into adding that feature for version two, which probably
won't be too long in coming ... and won't depend on openssl, one way
or another.

> Other than that, it works a treat! Thanks for putting the effort
> into making it :).

It was worth it to get to use it!  ;)  But I'm glad other people get
to use it too, and I'm glad that you like it.

Thanks very much for the valuable feedback.

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

Re: stat to open race condition (was Re: [Integrit-users] Re: integrit)

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

lumpy <lu...@9m...> writes:

> Probably, the only reason i said its not SO important is that if the
> file that its link to changes, itll still report an error. at most
> youre wasting the time to read the file to make the checksum.  Other
> than that, your program will basically work the same, because if
> youre statting the destination of the link, youll know if hte link
> has changed. make sense?

I don't want to ever follow symlinks.  If a sysadmin says, "don't
check /proc" or "don't check /mnt/remote_hosts", then integrit
shouldn't go there, even via a symlink.  integrit treats symlinks in
/home/foo as symlinks in /home/foo, not as files in some random place.
It's the natural thing to do.

In order to avoid following symlinks, lstat is necessary.  

> btw, i forgot to say, this project kicks ass. rock on.

Thanks!  I agree.  :)  And I was already going to say that I forgot to
thank you for pointing out an interesting and real race condition that
could hang integrit.  

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

Re: stat to open race condition (was Re: [Integrit-users] Re: integrit)

[lumpy <lu...@9m...>]

Probably, the only reason i said its not SO important is that if the file
that its link to changes, itll still report an error. at most youre
wasting the time to read the file to make the checksum.  Other than that,
your program will basically work the same, because if youre statting  the
destination of the link, youll know if hte link has changed. make sense?

btw, i forgot to say, this project kicks ass. rock on.

 On 20 Feb 2001, Ed L Cashin wrote:

> lumpy <lu...@9m...> writes:
> 
> > If instead of the double stat, you opened it and passed a
> > descriptor, you would get around the race, although, you would still
> > have to do another check if the file was a symlink (if you cared,
> > but, thats really not so important in this particular scenario)
> 
> Yeah, you have to do the lstat first so that you don't follow
> symlinks. 
> 
> -- 
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/
> 

Re: stat to open race condition (was Re: [Integrit-users] Re: integrit)

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

lumpy <lu...@9m...> writes:

> If instead of the double stat, you opened it and passed a
> descriptor, you would get around the race, although, you would still
> have to do another check if the file was a symlink (if you cared,
> but, thats really not so important in this particular scenario)

Yeah, you have to do the lstat first so that you don't follow
symlinks. 

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

Re: stat to open race condition (was Re: [Integrit-users] Re: integrit)

[lumpy <lu...@9m...>]

I am concerned about it - lets say youre checking /tmp and someone has a
regular file there, then, on the second run the file is switched with a
fifo, integrit will hang, no?

I thought the whole point of an integrity checker was to run to see if
files have changed.

If instead of the double stat, you opened it and passed a descriptor, you
would get around the race, although, you would still have to do another
check if the file was a symlink (if you cared, but, thats really not 
so important in this particular scenario)

On 20 Feb 2001, Ed L Cashin wrote:

> lumpy <lu...@9m...> writes:
> 
> > are you saying that youll never be checking any files that have an
> > ownership other than root, then?
> 
> No, it's just that checksums are only done on regular files.  I just
> checked and fifos do not test as regular files on FreeBSD.
> 
> > Im on freebsd, but, the i think its a general rule.  if you stat the
> > file, and then do an open on it, theres that race, meaning you can
> > swap between a fifo and a regular file.  causing integrit to hang
> > could allow the attacks to go on without it reporting anything.
> 
> Oh, I see now what you mean now: an attacker could mv a fifo to the
> filename that we just did a stat on.  This is what I was talking about
> when I said that on a compromised machine integrit (or any similar
> tool) may not run properly.  There are a zillion ways to undermine a
> running process when you have root, and it's not really helpful to try
> to fight that reality.
> 
> Using fstat as a second stat on every regular file would eliminate the
> race condition, but I don't think it's worth it to go down that road:
> 
>     lstat 
>     if regular file {
>     	    fd = open
>     	    fstat fd
>     	    if old inode != new inode {
>     		    warn
>     	    }
>     	    if regular file {
>     		    read for checksum
>     	    }
>     }
> 
> It's impossible to thwart a root user who wants to cripple a running
> process unless you're using a specialized kernel on specialized
> hardware, so I don't think it's worth making integrit slower by doing
> the two stats.
> 
> On the other hand, DOS attacks aside, you could say this as an
> opportunity to make integrit more robust.  e.g., What if a daemon
> replaces a regular file with a fifo right after our "lstat" and before
> "open"?  What do others think?  If there's interest I could implement
> the fstat technique and benchmark it.
> 
> -- 
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/
> 

stat to open race condition (was Re: [Integrit-users] Re: integrit)

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

lumpy <lu...@9m...> writes:

> are you saying that youll never be checking any files that have an
> ownership other than root, then?

No, it's just that checksums are only done on regular files.  I just
checked and fifos do not test as regular files on FreeBSD.

> Im on freebsd, but, the i think its a general rule.  if you stat the
> file, and then do an open on it, theres that race, meaning you can
> swap between a fifo and a regular file.  causing integrit to hang
> could allow the attacks to go on without it reporting anything.

Oh, I see now what you mean now: an attacker could mv a fifo to the
filename that we just did a stat on.  This is what I was talking about
when I said that on a compromised machine integrit (or any similar
tool) may not run properly.  There are a zillion ways to undermine a
running process when you have root, and it's not really helpful to try
to fight that reality.

Using fstat as a second stat on every regular file would eliminate the
race condition, but I don't think it's worth it to go down that road:

    lstat 
    if regular file {
    	    fd = open
    	    fstat fd
    	    if old inode != new inode {
    		    warn
    	    }
    	    if regular file {
    		    read for checksum
    	    }
    }

It's impossible to thwart a root user who wants to cripple a running
process unless you're using a specialized kernel on specialized
hardware, so I don't think it's worth making integrit slower by doing
the two stats.

On the other hand, DOS attacks aside, you could say this as an
opportunity to make integrit more robust.  e.g., What if a daemon
replaces a regular file with a fifo right after our "lstat" and before
"open"?  What do others think?  If there's interest I could implement
the fstat technique and benchmark it.

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

[Integrit-users] Re: integrit

[lumpy <lu...@9m...>]

are you saying that youll never be checking any files that have an
ownership other than root, then?  Im on freebsd, but, the i think its
a general rule.  if you stat the file, and then do an open on it, theres
that race, meaning you can swap between a fifo and a regular file.  
causing integrit to hang could allow the attacks to go on without it
reporting anything.

On 20 Feb 2001, Ed L Cashin wrote:

> (Cc'ed to integrit-users list: http://sourceforge.net/mail/?group_id=15369)
> 
> lumpy <lu...@9m...> writes:
> 
> > appears to choke on fifos, allowing for a denial of service attack.
> > to test, create a fifo (with mkfifo) and try to check its checksum.
> > note that there is a race between your stat and your open.
> 
> Thanks much for the feedback!  
> 
> Before trying to do a checksum, integrit tests to see whether the file
> is a regular file or not.  On my Linux 2.2.14 system, fifos are not
> treated as regular files (and they shouldn't be, since they're fifos),
> so such an attack would fail.  What system are you running (CPU and
> OS)?
> 
> To address the issue of DOS, if such a DOS attack is happening, then
> the machine has been compromised.  If integrit suddenly does not run
> correctly, that is a sign that the host has been compromised.  This is
> the same as with any similar product like aide or tripwire.
> 
> If the host has been compromised, then the only safe way to check the
> damage is unfortunately to mount the affected drive on a trusted host
> and investigate there.  Obviously, it's better to prevent breakins.
> 
> BTW, fifos are not the only way to trip up integrit if you've got
> root.  You could also turn off the machine or allocate all of its
> memory, or damage the filesystem, or load your own kernel modules
> ... integrit and products like it are not designed to accomodate such
> situations.  They are not panaceas but specific tools to be used as
> part of a comprehensive security policy.
> 
> -- 
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/
> 

[Integrit-users] Re: integrit

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

(Cc'ed to integrit-users list: http://sourceforge.net/mail/?group_id=15369)

lumpy <lu...@9m...> writes:

> appears to choke on fifos, allowing for a denial of service attack.
> to test, create a fifo (with mkfifo) and try to check its checksum.
> note that there is a race between your stat and your open.

Thanks much for the feedback!  

Before trying to do a checksum, integrit tests to see whether the file
is a regular file or not.  On my Linux 2.2.14 system, fifos are not
treated as regular files (and they shouldn't be, since they're fifos),
so such an attack would fail.  What system are you running (CPU and
OS)?

To address the issue of DOS, if such a DOS attack is happening, then
the machine has been compromised.  If integrit suddenly does not run
correctly, that is a sign that the host has been compromised.  This is
the same as with any similar product like aide or tripwire.

If the host has been compromised, then the only safe way to check the
damage is unfortunately to mount the affected drive on a trusted host
and investigate there.  Obviously, it's better to prevent breakins.

BTW, fifos are not the only way to trip up integrit if you've got
root.  You could also turn off the machine or allocate all of its
memory, or damage the filesystem, or load your own kernel modules
... integrit and products like it are not designed to accomodate such
situations.  They are not panaceas but specific tools to be used as
part of a comprehensive security policy.

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

Re: [Integrit-users] poll: integrit source distro size and BeeCrypt

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

lie...@pa... writes:

> You have my blessing. If openssl doesn't need to be installed in
> order to compile integrit, I think it's worth the effort.

I agree that the openssl dependency is perhaps the biggest stumbling
block for new users.

> btw: the solaris version works great now.

Excellent news!  Thanks much for the feedback.

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

Re: [Integrit-users] poll: integrit source distro size and BeeCrypt

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

You have my blessing. If openssl doesn't need to be installed in order to
compile integrit, I think it's worth the effort.
btw: the solaris version works great now.

Franky

On 19 Feb 2001, Ed L Cashin wrote:

> Hi, everyone.  I'd like to fish for comments.  I'm still waiting for a
> response from the openssl core group regarding distribution of an
> integrit binary that's been statically linked against openssl.
> 
> Meanwhile, I've discovered BeeCrypt:
> 
>     http://www.virtualunlimited.com/products/beecrypt/
> 
> ... which is LGPL and has MD5 and SHA-1 hashing implementations.  The
> SHA-1 has an assembly implementation and the author, Bob Deblier, is
> planning an assembly MD5 implementation, so I'm not worried that it
> will be compeditive with openssl in terms of performance.
> 
> I asked them about distributing a statically-linked binary integrit
> linked against libbeecrypt, including only the files for MD5 and SHA-1
> in the integrit source.  They responded with an offer that they'd be
> happy with that if I include the whole BeeCrypt source tree in the
> integrit source tree.
> 
> That would increase the size of the integrit source distribution from
> about 150K to about 290K.  (Compared to 214K for aide and 1,725K for
> tripwire.)
> 
> What's the general feeling out there?  Would anyone mind a bigger
> source distribution or is it worth it in order to be able to
> distribute binaries?
> 
> -- 
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/
> 
> 
> _______________________________________________
> Integrit-users mailing list
> Int...@li...
> http://lists.sourceforge.net/lists/listinfo/integrit-users
> 

[Integrit-users] poll: integrit source distro size and BeeCrypt

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

Hi, everyone.  I'd like to fish for comments.  I'm still waiting for a
response from the openssl core group regarding distribution of an
integrit binary that's been statically linked against openssl.

Meanwhile, I've discovered BeeCrypt:

    http://www.virtualunlimited.com/products/beecrypt/

... which is LGPL and has MD5 and SHA-1 hashing implementations.  The
SHA-1 has an assembly implementation and the author, Bob Deblier, is
planning an assembly MD5 implementation, so I'm not worried that it
will be compeditive with openssl in terms of performance.

I asked them about distributing a statically-linked binary integrit
linked against libbeecrypt, including only the files for MD5 and SHA-1
in the integrit source.  They responded with an offer that they'd be
happy with that if I include the whole BeeCrypt source tree in the
integrit source tree.

That would increase the size of the integrit source distribution from
about 150K to about 290K.  (Compared to 214K for aide and 1,725K for
tripwire.)

What's the general feeling out there?  Would anyone mind a bigger
source distribution or is it worth it in order to be able to
distribute binaries?

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

[Integrit-users] ANNOUNCE: version 1.06.04-beta

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

In my hurry to release version 1.06, I neglected to move away from
readdir_r.  

Patch level four of version 1.06 removes readdir_r from the source,
eliminating some issues that we've been seeing.  All platforms now use
readdir.  Please use beta version 1.06.04 instead of beta version
1.06.03.

Thanks.

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

[Integrit-users] ANNOUNCE: version 1.06.03-beta

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

The new version 1.06 includes an important bugfix that allows integrit
to run correctly on big-endian architectures (like Sparc) as well as
new features.  Details:

    Big bugfix: byte order issues were making i-viewdb and the
    check for missing files fail on big endian architectures
    (Sparc was the one tested) but work on little-endian
    machines (like PC's).  This problem has been corrected.
    
    Adding file stat and checksum information for missing and
    also new files to human-readable output.
    
    More error checking.
    
    Reporting permissions of symlinks as "sym" instead of "777"
    in human-readable output. 
    
    Adding rpm support.  Gyepi SAM <gy...@pe...> is
    the rpm packager.

This is a beta release because it includes new features and
significant improvements in the code.  The new release can be found at
the following URL's:

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

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

Re: solved: byte order issues (was Re: [Integrit-users] problems using integrit)

[Franky V. L. <fra...@pa...>]

great, so I now have to wait for the next version :) Any idea when this
will come out?

Franky

Ed L Cashin wrote:

> Good news: the problem has been fixed.  It was a byte order issue.
> The cdb is stored in a cross-platform format.  The numbers in the cdb
> file are in little-endian byte order, so no problems showed up on
> PC's.
>
> Now cdb's own number packing and unpacking routines are used to ensure
> that the numbers from the database are translated correctly into the
> host's native integer format.
>
> Thanks much to Van Liedekerke Franky for reporting the problem.  This
> fix is a big deal, since it applies to all big-endian architectures
> (and therefore lets me use integrit on more machines at work :).
>
> Soon I'll announce a version 1.06 release.  It will be a beta, since
> the current integrit has some enhancements and more error checking.
>
> --
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/

solved: byte order issues (was Re: [Integrit-users] problems using integrit)

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

Good news: the problem has been fixed.  It was a byte order issue.
The cdb is stored in a cross-platform format.  The numbers in the cdb
file are in little-endian byte order, so no problems showed up on
PC's.

Now cdb's own number packing and unpacking routines are used to ensure
that the numbers from the database are translated correctly into the
host's native integer format.

Thanks much to Van Liedekerke Franky for reporting the problem.  This
fix is a big deal, since it applies to all big-endian architectures
(and therefore lets me use integrit on more machines at work :).

Soon I'll announce a version 1.06 release.  It will be a beta, since
the current integrit has some enhancements and more error checking.

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

Re: [Integrit-users] problems using integrit

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

Ed L Cashin <ec...@co...> writes:

...
> I'm planning to check whether the cdb self-configuration is working
> right on Solaris 2.5.x this weekend.

Darn!  I mean 2.6.x.

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

Re: [Integrit-users] problems using integrit

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

Van Liedekerke Franky <lie...@pa...> writes:

> it's one version higher :)
> but still ... I'm stuck with it and I would really like to use
> integrit. Is it possibe the cdb libs are not up to date? Just
> guessing ...

They were the latest when I started making integrit (November 2000).
I'm planning to check whether the cdb self-configuration is working
right on Solaris 2.5.x this weekend.

> If somebody wants any debug info to get the problem fixed, mail me
> in private then.

OK.  

...
> btw... who is David Stes ?

He is the author of the POC, Portable Object Compiler, a nice, simple
Objective-C to C compiler.  According to him, he made the POC to
protect himself from the gcc developers, who he feared would remove
the Object class from the gcc Obj-C environment.

You can read many argumentative threads on comp.lang.objective-c.

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

Re: Re: [Integrit-users] problems using integrit

[Van L. F. <lie...@pa...>]

it's one version higher :)
but still ... I'm stuck with it and I would really like to use integrit. Is it possibe the cdb libs are not up to date? Just guessing ...
If somebody wants any debug info to get the problem fixed, mail me in private then.

greets,

Franky

btw... who is David Stes ?

------------------------
 Ed L Cashin <ec...@co...> wrote:
------------------------
	
>lie...@pa... writes:
>
> OS: Solaris 2.6 on a Enterprise 450
>
>Same OS as the one I mentioned (SunOS 5.5 -- confusing Sun
>shenanigans! ;)
>
>-- 
>--Ed Cashin                    integrit file verification system
>  ec...@co...          http://integrit.sourceforge.net/
>
>
>_______________________________________________
>Integrit-users mailing list
>Int...@li...
>http://lists.sourceforge.net/lists/listinfo/integrit-users
>

Re: [Integrit-users] problems using integrit

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

lie...@pa... writes:

> OS: Solaris 2.6 on a Enterprise 450

Same OS as the one I mentioned (SunOS 5.5 -- confusing Sun
shenanigans! ;)

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

Re: [Integrit-users] problems using integrit

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

OS: Solaris 2.6 on a Enterprise 450
I love to report bugs :)

Regards,

Franky

PS: the newline's were indeed inserted by my mailer.



On 16 Feb 2001, Ed L Cashin wrote:

> [I think David Stes has an account on pandora!]
> 
> lie...@pa... writes:
> 
> > Hi all,
> > 
> > I just installed integrit and am now of course trying to use it:
> > 
> > "../sbin/integrit -V" works fine
> > 
> > "../sbin/integrit -C test -u" gives me:
> > 
> > integrit: ---- integrit, version 1.05 -----------------
> > integrit:                      output : human-readable
> > integrit:                   conf file : test
> > integrit:                    known db : /opt/integrit/db/integrit-test.cdb
> > integrit:                  current db : 
> > /opt/integrit/db/integrit-test.cdb.new
> 
> I guess that your mailer is inserting the newline there, right?  It's
> really one line in the output?
> 
> > integrit:                        root : /web/content/test
> > integrit:                    do check : no
> > integrit:                   do update : yes
> > integrit: current-state db md5sum -------------- 
> > integrit: c8d98b53504a157f7bdc76620378e577 
> > /opt/integrit/db/integrit-test.cdb.new
> > 
> > But when I then try to do an check, it fails:
> > mv /opt/integrit/db/integrit-test.cdb.new
> > /opt/integrit/db/integrit-test.cdb
> > 
> > The command "../sbin/integrit -C test -u -c" gives me:
> > 
> > integrit: ---- integrit, version 1.05 -----------------
> > integrit:                      output : human-readable
> > integrit:                   conf file : test
> > integrit:                    known db : /opt/integrit/db/integrit-test.cdb
> > integrit:                  current db :
> > /opt/integrit/db/integrit-test.cdb.new
> > integrit:                        root : /web/content/test
> > integrit:                    do check : yes
> > integrit:                   do update : yes
> > integrit: checking for missing files --------------
> > integrit (check_for_missing): Error: cdb_seq_getkey: Invalid argument
> 
> Could you provide some details about the machine you're using?  OS, OS
> version, CPU, etc.?
> 
> I saw that on an older Solaris machine (SunOS 5.5).  For some reason,
> the database isn't getting read correctly, perhaps because it was
> never written correctly.  
> 
> I did some debugging, but I stopped because no one else seemed to be
> having a problem.  So thanks very much for reporting it.  :)
> 
> > also, when I try the i-viewdb command, it fails:
> > 
> > "../sbin/i-viewdb ../db/integrit-test.cdb" gives me:
> > 
> > integrit (viewdb): Error: bad entry (too big value) in DB 
> > (../db/integrit-test.cdb)
> > 
> > So can anybody help me with this?
> 
> I don't know if others have access to a machine that exhibits the
> problem, but if they do, maybe they could look into it.  My best guess
> would be that it's got something to do with data type sizes.
> 
> Personally, I plan to look into this on Saturday (tomorrow).  Thanks
> again for the report!
> 
> -- 
> --Ed Cashin                    integrit file verification system
>   ec...@co...          http://integrit.sourceforge.net/
> 
> 
> _______________________________________________
> Integrit-users mailing list
> Int...@li...
> http://lists.sourceforge.net/lists/listinfo/integrit-users
> 

Re: [Integrit-users] problems using integrit

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

[I think David Stes has an account on pandora!]

lie...@pa... writes:

> Hi all,
> 
> I just installed integrit and am now of course trying to use it:
> 
> "../sbin/integrit -V" works fine
> 
> "../sbin/integrit -C test -u" gives me:
> 
> integrit: ---- integrit, version 1.05 -----------------
> integrit:                      output : human-readable
> integrit:                   conf file : test
> integrit:                    known db : /opt/integrit/db/integrit-test.cdb
> integrit:                  current db : 
> /opt/integrit/db/integrit-test.cdb.new

I guess that your mailer is inserting the newline there, right?  It's
really one line in the output?

> integrit:                        root : /web/content/test
> integrit:                    do check : no
> integrit:                   do update : yes
> integrit: current-state db md5sum -------------- 
> integrit: c8d98b53504a157f7bdc76620378e577 
> /opt/integrit/db/integrit-test.cdb.new
> 
> But when I then try to do an check, it fails:
> mv /opt/integrit/db/integrit-test.cdb.new
> /opt/integrit/db/integrit-test.cdb
> 
> The command "../sbin/integrit -C test -u -c" gives me:
> 
> integrit: ---- integrit, version 1.05 -----------------
> integrit:                      output : human-readable
> integrit:                   conf file : test
> integrit:                    known db : /opt/integrit/db/integrit-test.cdb
> integrit:                  current db :
> /opt/integrit/db/integrit-test.cdb.new
> integrit:                        root : /web/content/test
> integrit:                    do check : yes
> integrit:                   do update : yes
> integrit: checking for missing files --------------
> integrit (check_for_missing): Error: cdb_seq_getkey: Invalid argument

Could you provide some details about the machine you're using?  OS, OS
version, CPU, etc.?

I saw that on an older Solaris machine (SunOS 5.5).  For some reason,
the database isn't getting read correctly, perhaps because it was
never written correctly.  

I did some debugging, but I stopped because no one else seemed to be
having a problem.  So thanks very much for reporting it.  :)

> also, when I try the i-viewdb command, it fails:
> 
> "../sbin/i-viewdb ../db/integrit-test.cdb" gives me:
> 
> integrit (viewdb): Error: bad entry (too big value) in DB 
> (../db/integrit-test.cdb)
> 
> So can anybody help me with this?

I don't know if others have access to a machine that exhibits the
problem, but if they do, maybe they could look into it.  My best guess
would be that it's got something to do with data type sizes.

Personally, I plan to look into this on Saturday (tomorrow).  Thanks
again for the report!

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

[Integrit-users] problems using integrit

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

Hi all,

I just installed integrit and am now of course trying to use it:

"../sbin/integrit -V" works fine

"../sbin/integrit -C test -u" gives me:

integrit: ---- integrit, version 1.05 -----------------
integrit:                      output : human-readable
integrit:                   conf file : test
integrit:                    known db : /opt/integrit/db/integrit-test.cdb
integrit:                  current db : 
/opt/integrit/db/integrit-test.cdb.new
integrit:                        root : /web/content/test
integrit:                    do check : no
integrit:                   do update : yes
integrit: current-state db md5sum -------------- 
integrit: c8d98b53504a157f7bdc76620378e577 
/opt/integrit/db/integrit-test.cdb.new

But when I then try to do an check, it fails:
mv /opt/integrit/db/integrit-test.cdb.new
/opt/integrit/db/integrit-test.cdb

The command "../sbin/integrit -C test -u -c" gives me:

integrit: ---- integrit, version 1.05 -----------------
integrit:                      output : human-readable
integrit:                   conf file : test
integrit:                    known db : /opt/integrit/db/integrit-test.cdb
integrit:                  current db :
/opt/integrit/db/integrit-test.cdb.new
integrit:                        root : /web/content/test
integrit:                    do check : yes
integrit:                   do update : yes
integrit: checking for missing files --------------
integrit (check_for_missing): Error: cdb_seq_getkey: Invalid argument


also, when I try the i-viewdb command, it fails:

"../sbin/i-viewdb ../db/integrit-test.cdb" gives me:

integrit (viewdb): Error: bad entry (too big value) in DB 
(../db/integrit-test.cdb)


So can anybody help me with this?

Franky

[Integrit-users] binary distro waits for license

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

Hi.  This is a quick note regarding the status of the new integrit
RPM.  I've reviewed the openssl license, and I want to contact openssl
before distributing a binary integrit that has openssl code statically
linked into it.  

I'll have to check Bernstein's cdb license too, but I don't remember
it being restrictive.

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

[Integrit-users] ANNOUNCE: i386 RPM for integrit version 1.05.03-stable

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

There is a new integrit RPM available.  Thanks to Gyepi SAM for
providing the spec file.  I tweaked it a bit to get integrit's version
number right.  I tried the rpm, and it worked great for me.  It does
the nice things you expect rpm to do.

I'm experimenting with providing the binary rpm in the file integrit
file releases.  If you're a PC rpm user, please give the rpm a try and
let us know how it works.  

Gyepi SAM, we can increment the release number in the rpm spec file if
you see any problems with release one.

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