aide.conf.autogenerated NOT properly generated

[Harvey Muller]

Binary package hint: aide-common

INSTALLED AIDE VERSION
0.13.1-7

PROBLEM DESCRIPTION

The aide.conf.autogenerated file is not properly generated. Not fully understanding how the debian based aide package works, I can only guess that the problem is either incorrect permissions on the executable files in /etc/aide/aide.conf.d, or the application which is responsible for concatenating the /etc/aide/aide.conf file with snippets in /etc/aide/aide.conf.d is malfunctioning.

The symptoms presented in the system are email notifications that are similar to the following:

<BEGIN EMAIL>
This is an automated report generated by the Advanced Intrusion Detection
Environment on mlab-1420 started at 2007-10-27 14:16:53.

******************************************************************************
* AIDE returned with exit code 17. Invalid configuration! *
******************************************************************************
Errors produced (3 lines):
37:syntax error:[
37:Error while reading configuration:[
Configuration error

End of AIDE error output.

funny, AIDE did not leave a log.

The check was done against /var/lib/aide/aide.db with the following characteristics:
  Mtime : 2007-10-27 11:06:08
  Ctime : 2007-10-27 11:06:08
  Inode : 246640

The AIDE run created a new database /var/lib/aide/aide.db.new with the following characteristics:

End of AIDE daily cron job at at 2007-10-27 14:16, run time 0 seconds
<END EMAIL>

To reproduce the problem, merely perform a fresh install of aide in Gutsy.

TEMPORARY SOLUTION

The update-aide.conf manpage states that the executable files in /etc/aide/aide.conf.d will be run and the stdout is used in the aide.conf.autogenerated file. The /etc/aide/aide.conf.d/* files as installed, are not marked as executable in their permissions. It may be that update-aide.conf is supposed to identify the snippets with shell code and run it. Regardless, the contents of all the /etc/aide/aide.conf.d files are being inserted verbatim into the aide.conf.autogenerated file (minus the shell identification line, i.e. #!/bin/sh).

The workaround, and perhaps the solution is to modify the permissions of all the files with shell script to be executable. I ran the following shell script in a terminal, and was then able to properly generate the *.autogenerated file:

<BEGIN SHELL SCRIPT>
#!/bin/sh
chmod 755 10_aide_hostname
chmod 755 30_aide_apache2
chmod 755 30_inn2_vars
chmod 755 31_aide_amanda-server
chmod 755 31_aide_apt
chmod 755 31_aide_ifupdown
chmod 755 31_aide_torrus
chmod 755 70_aide_dev
update-aide.conf
<END SHELL SCRIPT>

Those may not be the correct permissions to apply, but it did get me over the hurdle.

The other aide related bug I posted can either be marked a duplicate of this, or just closed.

TESTCASE
:: How to reproduce the issue ::
- Install the current version of aide
- Check that none of the scripts have the execute bit set in /usr/share/aide/config/aide/aide.conf.d/

:: Check the fix ::
- Install the -proposed version of aide
- Check that some scripts have the execute bit set in /usr/share/aide/config/aide/aide.conf.d/
  All files listed by
    # for file in /etc/aide/aide.conf.d/* ; do head -1 $file | grep -q '^\#\!' && ls -l $file ; done
  should show the execution bit set (e.g. mode -rwxr-xr-x)

[Jens Gecius (gmaniac)]

I can confirm the bug.

A fresh install of aide (after --purge) leaves the files

10_aide_hostname
30_aide_apache2
30_inn2_vars
31_aide_amanda-server
31_aide_apt
31_aide_ifupdown
31_aide_torrus
70_aide_dev

without the necessary execute-flag in directory /etc/aide/aide.conf.d/

Thus, the generated aide.conf.autogenerated includes shell-code, which aide fails to parse.

This renders the package out-of-the-box unuseable.

Thanks for considering this report.

[bmosher (bmosher)]

I've run into the same problem. This appears to be a fix:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447769

This accomplishes the fix stated in previous posts.

[Rolf Kutz (vzsze)]

The problem still exists in 8.04. Sad but true, since the fix is so easy and already exists.

[Christian Wolf (christianwolf)]

Same here, the autogenerated config file is hosed:

root@xxxxxx:/home/xxxxxx# aideinit
Running aide --init...
34:syntax error:(
34:Error while reading configuration:(
Configuration error
AIDE --init return code 17; see /var/lib/aide/aide.db.new for details

Not good, as it is one of the basic tools for server security.

[Edward Fjellskål (ebf0)]

Yes,

The same bug here.

Sollution (quick fix):
# chmod 754 /etc/aide/aide.conf.d/10_aide_hostname /etc/aide/aide.conf.d/30_aide_apache2 /etc/aide/aide.conf.d/30_inn2_vars /etc/aide/aide.conf.d/31_aide_amanda-server /etc/aide/aide.conf.d/31_aide_apt /etc/aide/aide.conf.d/31_aide_ifupdown /etc/aide/aide.conf.d/31_aide_torrus /etc/aide/aide.conf.d/70_aide_dev
# update-aide.conf
# aideinit

This is so sad :/ It takes the package maintainer so little effort to fix this, and its not done.
I find more and more packages in Ubuntu that are broken, and sadly stays so, even ppl do
post bug reports/fixes.. Some say that the bugs are fixed, but we have to wait until next
ubuntu release :/ which for aumix did not solve anything.. Its still broken...

I Love Ubuntu :) please keep up the good work btw :D

Edward Fjellskål

[Edward Fjellskål (ebf0)]

Sorry :)

# aide -v
Aide 0.13.1

Compiled with the following options:

WITH_MMAP
WITH_LSTAT64
WITH_READDIR64
WITH_MHASH
CONFIG_FILE = "/dev/null"

# uname -a
Linux view 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy

[Richard Ayotte (rich-ayotte)]

Same here on Hardy. I just ran

sudo grep -l '#!/bin' *|xargs chmod 755
sudo aideinit

and everyithing seems to be ok now.

[Zach (uid000)]

Hi,

I tried the above work-around. This allows aideinit to get farther, but does not succeed. I now get the following output from aideinit:

 $ sudo aideinit
Running aide --init...
109:syntax error:

109:Error while reading configuration:

Configuration error
AIDE --init return code 17; see /var/lib/aide/aide.db.new for details

The aide db is not written.

[Zach (uid000)]

I removed 31_aide_apt from aide.conf.d and the above error went away. not sure what the problem is with it.

[Zach (uid000)]

Turns out 31_aide_apt doesn't check for end-of-line comments as added by software-properties:
deb-src http://us.archive.ubuntu.com/ubuntu/ hardy restricted main multiverse universe #Added by software-properties

The attached patch sticks seds out end of line comments (and preceding whitespace) from each line in sources.list

[Dan Am (da-lonx)]

I can confirm the bug being present in 8.04. Zachs patch works. It should be included. The permissions thing on the scripts in /etc/aide/aide.conf.d is still present, too. I'd like to fix the package.

[Jean-Baptiste Lallement (jibel)]

The fix for the original issue has been fixed in Debian and need to be backported in Gutsy and Hardy. The version of aide in Intrepid is already up to date, so, I'm changing state to "Fix released" and will nominate it for release for the previous release of Ubuntu.

The point reported by Zach is addressed in bug #112242

Thanks for your help to make Ubuntu better.

[Jean-Baptiste Lallement (jibel)]

SRU: minimal patch for hardy.

The fix is from intrepid and fixes "aide_fixperms"

The patch is safe and affect an application rather than critical infrastructure packages.

Can someone test it ?

[Jean-Baptiste Lallement (jibel)]

SRU: minimal patch for gutsy.

The fix is from intrepid and fixes "aide_fixperms"

The patch is safe and affect an application rather than critical infrastructure packages.

Can someone test it ?

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Jean-Baptiste Lallement (jibel)]

I do confirm that the -proposed version of the package solves this issue for both Gutsy and Hardy.

== Test Case ==
:: How to reproduce the issue ::
- Install the current version of aide
- Check that none of the scripts have the execute bit set in /usr/share/aide/config/aide/aide.conf.d/

:: Check the fix ::
- Install the -proposed version of aide
- Check that some scripts have the execute bit set in /usr/share/aide/config/aide/aide.conf.d/

[Steve Beattie (sbeattie)]

I am able to reproduce the problem with aide|aide-common 0.13.1-8ubuntu1 in the 8.04.1 hardy release. The version of aide|aide-common in hardy-proposed, 0.13.1-8ubuntu2, fixes the problem, but *only* for fresh installations of aide. It does not fix the issue if someone installs the original 0.13.1-8ubuntu1 package of aide, and then either upgrades to the version of aide in -proposed or uninstalls aide and installs the version in -proposed; it will only address the issue for someone who installed the original aide package if the config files are removed via 'apt-get purge aide'.

In my opinion, the update ought to fix up the incorrect mode set by the original hardy version of aide, as this gives a bad user experience otherwise.

[Jean-Baptiste Lallement (jibel)]

Steve, you're right . This minimal patch don't sync the permissions of the files in /etc/aide/aide.conf.d with those in /usr/share/aide/config/aide/aide.conf.d/ . I haven't found any satisfying solution to sync modes and preserve user changes (if any) in /etc/aide/aide.conf.d/ .

However, I'll propose another version to correct this point.

[Jean-Baptiste Lallement (jibel)]

Here is another patch that solves the upgrade issue mentioned by Steve. The side effect is that any permission change made by the user prior to this patch will be reseted to default.

I'll let the SRU team decide if it's a valid SRU candidate or not.

[Jamie Strandboge (jdstrand)]

I just reviewed the debdiff and have a couple of comments:

1. the version will need to be updated to ubuntu3, since ubuntu2 has already been uploaded to -proposed

2. I don't see debdiffs for feisty and dapper. Does this mean that these versions are not affected by the bug? If so, I think an extra version check should be made in aide-common.postinst for upgrades from dapper to hardy or feisty to gutsy that would otherwise change permissions unnecessarily.

As such, I am marking the bug as 'Triaged'. Please update to 'In Progress' when an updated debdiff is supplied. Thanks!

[Jamie Strandboge (jdstrand)]

Also, this is very likely a change that should go to Debian. Can you contact Debian as per https://wiki.ubuntu.com/Bugs/Upstream?

[Jamie Strandboge (jdstrand)]

In the interest of getting this fixed, I went ahead and used the updated debdiff from Jean-Baptiste, creating an 0.13.1-8ubuntu3 version and added the fix for bug #114730 in that version. My testing shows that permissions are fixed on upgrade as well as new install. Also, /var/run/aide is created if it doesn't exist.

Chance of regression is very low for new installs. Existing installs with admins who use custom permissions will see a change in the permissions of the files in /etc. As I am not an aide user, Jean-Baptiste, can you comment further?

[Jean-Baptiste Lallement (jibel)]

Not much to add, you've said it all. Dapper is not affected by this and feisty will reach EOL next week. As said above, the choice had to be made between preserving user changes on upgrade, and syncing perms with package defaults. Maybe we could add a note about it in the changelog in order to inform the users and reduce bug reporting ?

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Steve Beattie (sbeattie)]

I can confirm that the problem is fixed in the version of aide and aide-common in hardy-propsed, 0.13.1-8ubuntu3, both for new installations and from the released version 0.13.1-8ubuntu1. Some minimal regression testing showed that, after installing the proposed package, aide was able to correctly read its configuration, build its file index, and monitor and detect changes to files correctly.

[Steve Beattie (sbeattie)]

The aide packages in gutsy-proposed, 0.13.1-7ubuntu1, have the same issue as the original hardy-proposed packages, that the permissions are correct for a new install using the gutsy-proposed package, but updating from the version in gutsy does not correct the permissions. The package in gutsy-proposed should dropped or replaced with a fix similar to that done for hardy.

Also, if someone does prepare a new fix for gutsy, that version also suffers from bug #114730.

To summarize, since I can't apply tags to individual tasks:

  hardy-proposed is verification-done
  gutsy-proposed is verification-failed

Martin: FYI, the hardy upload changelog refers to the wrong bug (bug #144730 vs bug #114730), so your archive script is showing that it hasn't been verified yet, when it has been (and I've confirmed it as well). AFAICS, the hardy-proposed package can move to hardy-updates.

Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package aide - 0.13.1-8ubuntu3

---------------
aide (0.13.1-8ubuntu3) hardy-proposed; urgency=low

  [ Jean-Baptiste Lallement ]
  * more fixes to aide_fixperms. Backported from intrepid (LP: #157858)

  [ Jamie Strandboge ]
  * Create TMPBASE directory if it doesn't exists (LP: #144730). Thanks
    to Jean-Baptiste Lallement.

 -- Jamie Strandboge <email address hidden> Fri, 10 Oct 2008 17:10:22 -0500

[Steve Beattie (sbeattie)]

Now that the hardy update has gone out the door, marking the package in gutsy-proposed as verification-failed.

[Martin Pitt (pitti)]

This got stalled way too much, and I guess there isn't much interest in gutsy any more. I pulled the failed SRU from gutsy-proposed.