Bug#1032381: aide: Broken aideinit due to _aide user handling

[Guillem Jover]

Package: aide
Version: 0.18-2
Severity: serious

Hi!

Just upgraded a server to Debian bookworm, and noticed that aideinit
was not working anymore, giving the following error:

,---
# aideinit --yes --force
Running aide --init...
User [_aide] not known
AIDE --init return code 1
`---

This specific system is using sysvinit. Checking the postinst I notice
it is conditionally using systemd-sysusers if available, but then
unconditionally tries to chown files and does not fail if it cannot
perform the operation.

So ideally this would get adduser support, and depend on either that
or systemd-standalone-sysusers.

After having manually created the user with adduser, then aideinit
still failed with:

,---
# aideinit --force --yes
Running aide --init...
/bin/bash: line 1: /var/log/aide/aideinit.log: Permission denied
AIDE --init return code 1
`---

Checking «/var/log/aide/» I saw that at least aideinit.log and
aideinit.errors were indeed still owned by root:adm, fixing the
ownership for those files made aideinit work again. So I guess this is
also missing in the postinst handling.

Thanks,
Guillem

[Marc Haber]

On Sun, Mar 05, 2023 at 04:00:26PM +0100, Guillem Jover wrote:
> Package: aide
> Version: 0.18-2
> Severity: serious

Justification?

> This specific system is using sysvinit. Checking the postinst I notice
> it is conditionally using systemd-sysusers if available, but then
> unconditionally tries to chown files and does not fail if it cannot
> perform the operation.

Yes, that is expected, please see
/usr/share/doc/aide-common/README.Debian.gz and consider sending a
tested patch.

> So ideally this would get adduser support, and depend on either that
> or systemd-standalone-sysusers.

It is my intention to have aide degrade gracefully to using root on
non-systemd systems, since non-systemd users obviously dont care much
about security.

Greetings
Marc

[Guillem Jover]

On Sun, 2023-03-05 at 17:18:00 +0100, Marc Haber wrote:
> On Sun, Mar 05, 2023 at 04:00:26PM +0100, Guillem Jover wrote:
> > Package: aide
> > Version: 0.18-2
> > Severity: serious
>
> Justification?

After upgrade, something that used to work stopped working, which
seemed appropriate to me, but if you disagree I don't feel like
arguing over this.

> > This specific system is using sysvinit. Checking the postinst I notice
> > it is conditionally using systemd-sysusers if available, but then
> > unconditionally tries to chown files and does not fail if it cannot
> > perform the operation.
>
> Yes, that is expected, please see
> /usr/share/doc/aide-common/README.Debian.gz and consider sending a
> tested patch.

Ah, ok thanks. I'm attaching the patch that I've prepared, I'll be
testing it later today. Let me know if you see any issue with its
direction, and I'm happy to amend stuff.

> > So ideally this would get adduser support, and depend on either that
> > or systemd-standalone-sysusers.
>
> It is my intention to have aide degrade gracefully to using root on
> non-systemd systems,

I did have libcap2-bin installed so I guess that's why it broke these
expectations.

> since non-systemd users obviously dont care much about security.

(This seems like a gratuitous comment, but it does not seem productive
to get into this.)

Thanks,
Guillem

[Marc Haber]

On Sun, Mar 05, 2023 at 04:00:26PM +0100, Guillem Jover wrote:

> So ideally this would get adduser support, and depend on either that
> or systemd-standalone-sysusers.

As the maintainer of adduser, I specifically selected aide to be my test
balloon to "test the enemy" ;-)

I was not aware of dh_installsysusers and will change the package to use
that instead.

Greetings
Marc

[Marc Haber]

On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> After upgrade, something that used to work stopped working, which
> seemed appropriate to me, but if you disagree I don't feel like
> arguing over this.

Debian decided that support for non-systemd init systems is optional and
that we're allowed to use systemd features. I am not a systemd fanboi,
but I see its advantages and have committed to using its features and I
feel that it's fair to leave the work of supporting non-systemd init
systems to the users of those init systems. Thanks for helping here, and
I will try to be as accomodating as possible while not spending too much
time myself. My focus therefore is not to break systemd systemd and not
to add ballast.

> -if command -v systemd-sysusers >/dev/null; then
> +if command -v adduser >/dev/null; then
> + # XXX: Use deprecated options to handle a smooth partial upgrade,
> + # switch the the new options after bookworm's release.
> + adduser --system --group --force-badname --quiet \
> + --no-create-home --home /var/lib/aide --shell /usr/sbin/nologin \
> + ---gecos 'Advanced Intrusion Detection Environment' _aide
> +elif command -v systemd-sysusers >/dev/null; then
> systemd-sysusers
> fi

I am not sure whether calling systemd-sysusers from postinst is still
necessary if dh_installsysusers is used, so I'll adapt this after
testing the new dh_installsysusers stuff.

> # added updating to 0.18-1
> rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
>
> -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> +if dpkg --compare-versions "$2" lt "0.18-2"; then

I am wondering why your postinst didn't trigger there. And I think if
there is one person in Debian who knows how dpkg --compare-versions
works then I am right now talking to him.

Current stable has 0.17.3-4+deb11u1, and we had number of 0.17.4
versions in testing during the bullseye cycle, so even the first version
comparing with 0.17.5-1 should have always triggered the chown
mechanisms, right?

> # we're updating from a version earlier than 0.17.5, chown logs and databases
> chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log /var/log/aide/aide.log.* || true
> + chown --quiet _aide:adm /var/log/aide/aideinit.log /var/log/aide/aideinit.errors || true
> chmod --quiet 2755 /var/log/aide || true
> chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new || true

This would re-chown the other logfiles and the database for a user who
had updated to 0.18-1 or 0.18-2 before and then decided to run aide with
a different user. Wouldn't it be clearer to have a dedicated dpkg
--compare-versions route for the forgotten aideinit.log, like:

if dpkg --compare-versions "$2" lt 0.18-3; then
# we're updating from a version earlier than 0.18-3, chown aideinit logs
chown --quiet _aide:adm /var/log/aide/aideinit.log /var/log/aide/aideinit.errors|| true
fi

> Depends: aide (>= 0.17),
> liblockfile1,
> ucf (>= 2.0020),
> + adduser | systemd-sysusers,
> ${misc:Depends}

This is hopefully handled by dh_installsysusers

> Recommends: cron,
> + libcap2-bin,
> bsd-mailx | mailx | s-nail

I'd rather not have this but document it in README.Debian to not pull in
libcap2-bin on systemd systems which don't need that dependency. I have
added a half-sentence mentioning libcap2-bin to README.Debian. The
scripts should run fine without libcap2-bin installed and fall back to
running as root instead.

Greetings
Marc

[Guillem Jover]

On Thu, 2023-03-09 at 14:39:37 +0100, Marc Haber wrote:
> On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> > # added updating to 0.18-1
> > rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
> >
> > -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> > +if dpkg --compare-versions "$2" lt "0.18-2"; then
>
> I am wondering why your postinst didn't trigger there. And I think if
> there is one person in Debian who knows how dpkg --compare-versions
> works then I am right now talking to him.

> Current stable has 0.17.3-4+deb11u1, and we had number of 0.17.4
> versions in testing during the bullseye cycle, so even the first version
> comparing with 0.17.5-1 should have always triggered the chown
> mechanisms, right?

I think I tried to cover this in the commit message, but perhaps it
was not very clear. This should have triggered, and the chown/chmod
calls executed, but because the user _aide had not been created then
the chown calls failed silently and their error codes got ignored.

I bumped the version because this needs to be re-executed once the
user is guaranteed to have been created. Otherwise when using the
_aide user, the tools will fail due to lack of permissions.

> > # we're updating from a version earlier than 0.17.5, chown logs and databases
> > chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log /var/log/aide/aide.log.* || true
> > + chown --quiet _aide:adm /var/log/aide/aideinit.log /var/log/aide/aideinit.errors || true
> > chmod --quiet 2755 /var/log/aide || true
> > chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new || true
>
> This would re-chown the other logfiles and the database for a user who
> had updated to 0.18-1 or 0.18-2 before and then decided to run aide with
> a different user. Wouldn't it be clearer to have a dedicated dpkg
> --compare-versions route for the forgotten aideinit.log, like:
>
> if dpkg --compare-versions "$2" lt 0.18-3; then
> # we're updating from a version earlier than 0.18-3, chown aideinit logs
> chown --quiet _aide:adm /var/log/aide/aideinit.log /var/log/aide/aideinit.errors|| true
> fi

See above. Also, I'd assume the supported users are root or _aide? Or
do you consider running under any arbitrary user configured by the
admin something to support? If the former, then if the admin has
decided to run the tools as root, then I'd assume the tools should have
enough permissions to write into the files even if they are owned by
_aide (but didn't try that in case they drop privs or similar).

> > Depends: aide (>= 0.17),
> > liblockfile1,
> > ucf (>= 2.0020),
> > + adduser | systemd-sysusers,
> > ${misc:Depends}
>
> This is hopefully handled by dh_installsysusers

(I assume that will imply having to install systemd-sysusers on a
system where adduser is already available if no adduser support is
added, which seems unfortunate, but better than not having the user
created. :)

> > Recommends: cron,
> > + libcap2-bin,
> > bsd-mailx | mailx | s-nail
>
> I'd rather not have this but document it in README.Debian to not pull in
> libcap2-bin on systemd systems which don't need that dependency. I have
> added a half-sentence mentioning libcap2-bin to README.Debian. The
> scripts should run fine without libcap2-bin installed and fall back to
> running as root instead.

If you find Recommends too strong, then it can always be added as a
Suggests, which is metadata available to the package managers and
frontends (perhaps even with a brief note in the Description?). Looking
into README.Debian is the last place I think when deciding whether I
might need to install additional packages needed by something.

Another option could be to declare this as «systemd-sysv | libcap2-bin»,
which keeps it as declarative, and handles the systemd case you are
concerned about.

Thanks,
Guillem

[Dark]

I've run into this issue when upgrading a systemd system from bullseye to bookworm - _aide user was not created

This is resulting in the following failure:

May 02 03:34:21 *** (idecheck)[12947]: dailyaidecheck.service: Failed to determine user credentials: No such process
May 02 03:34:21 *** (idecheck)[12947]: dailyaidecheck.service: Failed at step USER spawning /usr/share/aide/bin/dailyaidecheck: No such process
May 02 03:34:21 *** systemd[1]: dailyaidecheck.service: Failed with result 'exit-code'.
May 02 03:34:21 *** systemd[1]: Failed to start dailyaidecheck.service - daily AIDE check.

Looking at my upgrade log I can see:

chown: invalid user: ‘_aide:adm’
chown: invalid user: ‘_aide:root’
chown: invalid user: ‘_aide:adm’

/usr/lib/tmpfiles.d/aide-common.conf:1: Failed to resolve user '_aide': No such process
/usr/lib/tmpfiles.d/aide-common.conf:2: Failed to resolve user '_aide': No such process
/usr/lib/tmpfiles.d/aide-common.conf:3: Failed to resolve user '_aide': No such process

Other packages created users successfully as part of the upgrade so doesn't seem to be any fundamental issue with user creation. See this rkhunter log:

Warning: User 'polkitd' has been added to the passwd file.
Warning: User 'iperf3' has been added to the passwd file.

Also an aside, not an expert on Debian bug tracker, but shouldn't this be a release critical bug? Maybe it already is but I'm not seeing it in the release critical bugs list

Sending this again as not showing on bugreport.cgi, apologies if duplicate

[Dark]

[Marc Haber]

Hi Dark,

please file a new bug report, that gives more information about your
system.

Are you using systemd?

Greetings
Marc

[Dark]

Yep this is a systemd system

The only relevant customisation I can think of is adduser.conf set to
'DIR_MODE=0750' (which I reverted to the new 0700 default as part of the
upgrade, but not sure if that happened before or after aide was
upgraded), and proc mounted with 'hidepid=2' (which I know systemd
sometimes isn't happy with)

Will get a separate bug written up soon

[Marc Haber]

I apologize for letting this hang for too long. Sadly, any more changes
are not going to be in bookworm.

On Wed, Mar 15, 2023 at 04:14:25AM +0100, Guillem Jover wrote:
> On Thu, 2023-03-09 at 14:39:37 +0100, Marc Haber wrote:
> > On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> > > # added updating to 0.18-1
> > > rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
> > >
> > > -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> > > +if dpkg --compare-versions "$2" lt "0.18-2"; then
> >
> > I am wondering why your postinst didn't trigger there. And I think if
> > there is one person in Debian who knows how dpkg --compare-versions
> > works then I am right now talking to him.
>
> > Current stable has 0.17.3-4+deb11u1, and we had number of 0.17.4
> > versions in testing during the bullseye cycle, so even the first version
> > comparing with 0.17.5-1 should have always triggered the chown
> > mechanisms, right?
>
> I think I tried to cover this in the commit message, but perhaps it
> was not very clear. This should have triggered, and the chown/chmod
> calls executed, but because the user _aide had not been created then
> the chown calls failed silently and their error codes got ignored.

So we should check for _aide to be present, or is the current package
using dh_installsysusers robust enough so that we can assume _aide to be
there?

> > if dpkg --compare-versions "$2" lt 0.18-3; then
> > # we're updating from a version earlier than 0.18-3, chown aideinit logs
> > chown --quiet _aide:adm /var/log/aide/aideinit.log /var/log/aide/aideinit.errors|| true
> > fi
>
> See above. Also, I'd assume the supported users are root or _aide? Or
> do you consider running under any arbitrary user configured by the
> admin something to support? If the former, then if the admin has
> decided to run the tools as root, then I'd assume the tools should have
> enough permissions to write into the files even if they are owned by
> _aide (but didn't try that in case they drop privs or similar).

I'd like to be cooperative and help local admins to use other users as
well, but not to an extents that I would write tens of lines of codes to
"support" this. I'd just rather not slam a door unnecessarily, if that
makes sense.

> > > Depends: aide (>= 0.17),
> > > liblockfile1,
> > > ucf (>= 2.0020),
> > > + adduser | systemd-sysusers,
> > > ${misc:Depends}
> >
> > This is hopefully handled by dh_installsysusers
>
> (I assume that will imply having to install systemd-sysusers on a
> system where adduser is already available if no adduser support is
> added, which seems unfortunate, but better than not having the user
> created. :)

Yes, that will imply that. systemd-sysusers is provided by systemd
proper, and I do not plan on using adduser in aide.

> > > Recommends: cron,
> > > + libcap2-bin,
> > > bsd-mailx | mailx | s-nail
> >
> > I'd rather not have this but document it in README.Debian to not pull in
> > libcap2-bin on systemd systems which don't need that dependency. I have
> > added a half-sentence mentioning libcap2-bin to README.Debian. The
> > scripts should run fine without libcap2-bin installed and fall back to
> > running as root instead.
>
> If you find Recommends too strong, then it can always be added as a
> Suggests, which is metadata available to the package managers and
> frontends (perhaps even with a brief note in the Description?).

Too late for bookworm, but noted for the next cycle. It will be a
suggests.

Greetings
Marc

[Marc Haber]

On Tue, May 02, 2023 at 12:49:13PM +0100, Dark wrote:
> Yep this is a systemd system

Then your issue is completely independent from this bug report. I am
happy to hear from you in a new bug report.

Greetings
Marc

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

[Marc Haber]

Control: tags -1
thanks

On Wed, Mar 15, 2023 at 04:14:25AM +0100, Guillem Jover wrote:

> Another option could be to declare this as «systemd-sysv | libcap2-bin»,
> which keeps it as declarative, and handles the systemd case you are
> concerned about.

Unfortunately, that will pull in systemd. I think that is not what users
of sysvinit want.

iproute2 depends on libcap2-bin, so that library is probably already
present on the vast majority of Debian systems anyway.

I'd rather not add that Suggests to aide, but I'm open to new arguments.

Greetings
Marc

[Marc Haber]

Control: severity -1 minor
Control: retitle -1 should depend/suggest libcap2-bin for non-systemd systems
thanks

To my understanding the issues raised in this bug report are all solved
now BUT the dependency on libcap2-bin. I don't consider this a
hard showstopper and am lowering the severity appropraitely and
de-dramatize the title.

I'm open to arguments to convince me that this is wrong.

Greetings
Marc

[Marc Haber]

Control: tags -1
thanks

On Tue, Jul 11, 2023 at 02:47:52PM +0200, Marc Haber wrote:

> I'd rather not add that Suggests to aide, but I'm open to new arguments.

I plan to close this bug by the End of October 2023.

Greetings
Marc