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

[Marc Haber]

Hi Francois,

On Wed, Mar 05, 2008 at 05:30:52PM +0100, Francois Gouget wrote:
> 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 :-(

Until then, you can manually copy aide.db.new over aide.db.

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

They are already in svn, but have not been tested widely. I will
prepare a new upload of aide maybe this week.

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

cruft and aide do quite different things, and merging their
configuration seems like a good idea. But I am totally demotivated to
help with cruft as I have tried to work with cruft's maintainer on a
different package, ifupdown, for years and have found that he is
impossible to work with.

The Debian Policy thing is not going to happen any time soon. The
right way would be submitting aide rules to the other packages by way
of a wishlist bug report, leaving it at the maintainer's discretion to
include the file or not.

Having the aide rule brought with the package that needs them also
eases the problem that an aide installation bringing all rules with
itself would have a lot of unnecessary rules active, giving
more opportunities to attackers to hide their files.

> 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 :-(

To me your opinion carries as much weight as a DD's, and nothing keeps
you away from producing code and patches.

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

Aide configuration may have bugs, and thus a manual inspection is in
order. When the local admin feels sufficiently comfortable with his
configuration, he might give consent to automatically accept the
changes.

> Do you use ifnochange?

Yes, I use it. But my systems rarely have no changes in the aide logs.

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

Ifnochange is a Debian extension implemented in the Debian daily cron
job. Upstream doesn't even know about that feature.

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

If /usr/bin/perl weren't changed, and the rules for /var/log/syslog
were correct, aide wouldn't report any changes here, and the new
database would be copied if ifnochange is set.

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

That's the idea, but the I feature of aide doesn't interface very well
with ANF and ARF to allow this transparently. I have to trust upstream
saying that this interface would be awfully hard without a major
design change in aide.

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

Yes, but it should be discussed on the upstream mailing list.

Did I point you to the debugging setup published at
https://ivanova.notwork.de/~mh/stuff/aidetest.tar.gz?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190