[Pkg-aide-maintainers] Bug#442214: Bug#442214: aide: Aide issues false alarms

Francois Gouget fgouget at free.fr
Wed Mar 5 16:30:52 UTC 2008


On Wed, 5 Mar 2008, Marc Haber wrote:
[...]
> Which is why the AIDE documentation asks people to submit their rules
> either to aide or to the maintainers of the other packages for
> inclusion in either package. The support scheme supports either.

I have been trying to add the missing rules but this has been pretty 
frustrating. Even more so because some files keep coming back eventhough 
I thought I had them covered. But now I understand it is because 
ifnochange was not set, and even then it's not going to trigger before I 
solve everything :-(

So I've sent you a few of the missing rules. They mostly have to do with 
(rotated) logs. I'm not very confident in the rules I wrote though but 
hopefully with your help I can get them right and accepted in aide. Then 
as the first rules receive your green light I can send you more (there's 
no point burying you in what may be little more than garbage).



> Unfortunately, users and other maintainers are quite reluctant to do
> so, and I do not have the time to build rules for packages that I do
> not use myself. Frankly, I _must_ rely on other doing this work.

I think the aide configuration files and the cruft configuration files 
should be merged (in fact cruft should probably have more than enough 
information in the aide configuration files), and then Debian Policy 
should make it mandatory for every Debian package to provide these 
configuration files.

This would have many benefits:
 * Make it easy to support both cruft and aide
 * Debian systems would become much more auditable as not only the 
   'static' files would be accounted for, but also the dynamic runtime 
   ones.
 * 'dlocate /var/log/syslog' would finally return something sensible
 * By making it part of Debian Policy we'd get much much better coverage 
   and solve what has been the main problem for both cruft and aide.

But of course this is a big change so there will be resistance and as 
I'm not a Debian developer my opinion does not carry much weight :-(



[...]
> > I also don't understand why ifnochange is not the default since, as it 
> > is and with the rules that aide ships with, using anything else will 
> > result in the administrator being deluged with false positives 
> > (essentially every single Debian package's log files will be reported in 
> > short order).
> 
> Ifnochange basically accepts a certain set of changes automatically,
> which is, IMO, unacceptable as a default configuration.

But this set of changes has been explicitly okay-ed by the aide 
configuration files as corresponding to the normal system behavior. So 
I see no reason not to validate them.

Otherwise we have the current situation where after just a couple of 
days you have tons of changed files in the aide reports, which, if you 
don't do what ifnochange would have done in the first place, means the 
aide reports becomes useless because it is filled with false positives.

Do you use ifnochange? If not, how do you deal with all the warnings 
about the logs?


Ideally, in ifnochange mode aide would know how to make partial changes 
to the aide.db file.

For instance on day N /var/log/syslog gets rotated but that's allowed by 
the configuration files so the corresponding entries are updated in 
aide.db. On the same day /usr/bin/perl is modified but that's not 
allowed by the aide rules so that entry is not updated in aide.db.

Then on day N+1 /var/log/syslog gets rotated again. But that's ok 
because it's allowed by the aide rules and the database has been updated 
the day before. /usr/bin/perl has not been modified further but aide 
still reports it because it still does not match what aide.db says it 
should be.

Such a behavior would make it much easier to progressively get the 
aide.log reports under control and finally useful.

-- 
Francois Gouget <fgouget at free.fr>              http://fgouget.free.fr/
 The greatest programming project of all took six days; on the seventh day the
  programmer rested. We've been trying to debug the *&^%$#@ thing ever since.
                      Moral: design before you implement.





More information about the Pkg-aide-maintainers mailing list