Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1223337 > unrolled thread

Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-09 13:50 +0100
    Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-09 23:50 +0100
      Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-10 10:20 +0100
        Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-10 14:20 +0100
          Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-11 17:00 +0100
            Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-12 00:50 +0100
              Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-15 23:50 +0100
    Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-28 22:20 +0100
    Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-30 14:20 +0100

#1223337 — Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles

Package: chkrootkit
Version: 0.58b-3
Severity: normal

I was wondering why my /tmp is never cleared by systemd-tmpfiles, and
tried playing around with the settings in /etc/tmpfiles.d, but it
didn't help.

I then discovered the source of the problem: chkrootkit updates the
access times of all the files in /tmp as it checks them, meaning that
they are always viewed as recently accessed and so never cleaned.

This is clearly not desirable behaviour; chkrootkit shouldn't be
modifying the access times.  But obviously, chkrootkit is accessing
the files, so the access times will be updated by default.  It should
therefore record the access time prior to accessing the file and reset
it to that time afterwards (presumably using utimes(2) or similar).
This apparently will require CAP_FOWNER privileges (as mentioned in
systemd-tmpfiles(8)).

Best wishes,

   Julian

[toc] | [next] | [standalone]

#1223403

[Multipart message — attachments visible in raw view] — view raw

On Mon, 9 Dec 2024, 12:42 Julian Gilbey, <jdg@debian.org> wrote:

> Package: chkrootkit
> Version: 0.58b-3
> Severity: normal
>
> I was wondering why my /tmp is never cleared by systemd-tmpfiles, and
> tried playing around with the settings in /etc/tmpfiles.d, but it
> didn't help.
>
> I then discovered the source of the problem: chkrootkit updates the
> access times of all the files in /tmp as it checks them, meaning that
> they are always viewed as recently accessed and so never cleaned.
>

this is the check for suspicious php files, which does read the start of
each file to see if it is a php script.

It should
> therefore record the access time prior to accessing the file and reset
> it to that time afterwards (presumably using utimes(2) or similar).
>

the accessing is done from a shell script so is this even possible?

what if someone else accesses the file during the test?

[toc] | [prev] | [next] | [standalone]

#1223440

On Mon, Dec 09, 2024 at 10:45:40PM +0000, Richard Lewis wrote:
> On Mon, 9 Dec 2024, 12:42 Julian Gilbey, <jdg@debian.org> wrote:
> 
>   Package: chkrootkit
>   Version: 0.58b-3
>   Severity: normal
> 
>   I was wondering why my /tmp is never cleared by systemd-tmpfiles, and
>   tried playing around with the settings in /etc/tmpfiles.d, but it
>   didn't help.
> 
>   I then discovered the source of the problem: chkrootkit updates the
>   access times of all the files in /tmp as it checks them, meaning that
>   they are always viewed as recently accessed and so never cleaned.
> 
> this is the check for suspicious php files, which does read the start of each
> file to see if it is a php script. 
> 
>   It should
>   therefore record the access time prior to accessing the file and reset
>   it to that time afterwards (presumably using utimes(2) or similar).
> 
> the accessing is done from a shell script so is this even possible? 
> what if someone else accesses the file during the test?

Hi Richard,

Something like this should work in a shell script:

origtime=$(ls --full-time -u "$filename" | cut -d' ' -f6-8)
touch -a --date="$origtime" "$filename"

(though it might need a bit more testing).

Someone else accessing the file during the very short duration of the
test is relatively unlikely, and resetting the access time in such a
relatively uncommon event is not likely to have any significant
negative consequences.  But updating all access times across large
chunks of a filesystem is not at all desirable.  Access times are
usually uninteresting, except in cases such as this (systemd-tmpfiles)
where they are being actively inspected and acted upon.

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#1223465

[Multipart message — attachments visible in raw view] — view raw

On Tue, 10 Dec 2024, 09:10 Julian Gilbey, <jdg@debian.org> wrote:

> On Mon, Dec 09, 2024 at 10:45:40PM +0000, Richard Lewis wrote:
> > On Mon, 9 Dec 2024, 12:42 Julian Gilbey, <jdg@debian.org> wrote:
> > chkrootkit updates the
> >   access times of all the files in /tmp




> >   it to that time afterwards (presumably using utimes(2) or similar).
>
>
> Something like this should work in a shell script:
>
> origtime=$(ls --full-time -u "$filename" | cut -d' ' -f6-8)
> touch -a --date="$origtime" "$filename"
>
> (though it might need a bit more testing).
>

i suppose you could make this happen in /usr/lib/chkrootkit/check_php

a thought --- would a better way be to make the daily run have a read-only
filesystem? i think systemd can do that with hardening dirctives and it
might avoid a lot of work.

Otherwise you would need to make this work with the -p -r and -e options
(and we will continue to pretend not to notice -x ), and provide tests

[toc] | [prev] | [next] | [standalone]

#1223620

On Tue, Dec 10, 2024 at 01:10:16PM +0000, Richard Lewis wrote:
> On Tue, 10 Dec 2024, 09:10 Julian Gilbey, <jdg@debian.org> wrote:
> 
>   On Mon, Dec 09, 2024 at 10:45:40PM +0000, Richard Lewis wrote:
>   > On Mon, 9 Dec 2024, 12:42 Julian Gilbey, <jdg@debian.org> wrote:
>   > chkrootkit updates the
>   >   access times of all the files in /tmp
> 
>   >   it to that time afterwards (presumably using utimes(2) or similar).
> 
>   Something like this should work in a shell script:
> 
>   origtime=$(ls --full-time -u "$filename" | cut -d' ' -f6-8)
>   touch -a --date="$origtime" "$filename"
> 
>   (though it might need a bit more testing).
> 
> i suppose you could make this happen in /usr/lib/chkrootkit/check_php
> a thought --- would a better way be to make the daily run have a read-only
> filesystem? i think systemd can do that with hardening dirctives and it might
> avoid a lot of work. 

That's an interesting possibility I wasn't aware of.  If that can be
done, it would be perfect.

> Otherwise you would need to make this work with the -p -r and -e options (and we
> will continue to pretend not to notice -x ), and provide tests

(I'm not sure whether this means that I (Julian) would need to make it
work, or whether it means that someone would have to make it work.  I
don't have the capacity to work on this myself, I'm afraid.)

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#1223671

On Wed, 11 Dec 2024 at 15:53, Julian Gilbey <jdg@debian.org> wrote:
>
> On Tue, Dec 10, 2024 at 01:10:16PM +0000, Richard Lewis wrote:
> > On Tue, 10 Dec 2024, 09:10 Julian Gilbey, <jdg@debian.org> wrote:
> >
> >   On Mon, Dec 09, 2024 at 10:45:40PM +0000, Richard Lewis wrote:
> >   > On Mon, 9 Dec 2024, 12:42 Julian Gilbey, <jdg@debian.org> wrote:
> >   > chkrootkit updates the
> >   >   access times of all the files in /tmp
> >
> >   >   it to that time afterwards (presumably using utimes(2) or similar).
> >
> >   Something like this should work in a shell script:
> >
> >   origtime=$(ls --full-time -u "$filename" | cut -d' ' -f6-8)
> >   touch -a --date="$origtime" "$filename"
> >
> >   (though it might need a bit more testing).
> >
> > i suppose you could make this happen in /usr/lib/chkrootkit/check_php
> > a thought --- would a better way be to make the daily run have a read-only
> > filesystem? i think systemd can do that with hardening dirctives and it might
> > avoid a lot of work.
>
> That's an interesting possibility I wasn't aware of.  If that can be
> done, it would be perfect.

I think all it needs is
/etc/systemd/system/chkrootkit.service.d/override.conf with

[Service]
ProtectSystem=strict

(you can do "systemctl edit chkrootkit.service" and it will make such
a file and reload it,
you can then do systemctl start chkrootkit and it should be used)
That should solve the problem for the daily check. Can you see if that
it works. it's probably useful anyway)

[toc] | [prev] | [next] | [standalone]

#1224187

On Wed, Dec 11, 2024 at 11:43:18PM +0000, Richard Lewis wrote:
> [...]
> I think all it needs is
> /etc/systemd/system/chkrootkit.service.d/override.conf with
> 
> [Service]
> ProtectSystem=strict
> 
> (you can do "systemctl edit chkrootkit.service" and it will make such
> a file and reload it,
> you can then do systemctl start chkrootkit and it should be used)
> That should solve the problem for the daily check. Can you see if that
> it works. it's probably useful anyway)

That works perfectly, thank you!

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#1225965

On Sun, 15 Dec 2024 22:40:51 +0000 Julian Gilbey <jdg@debian.org> wrote:
> On Wed, Dec 11, 2024 at 11:43:18PM +0000, Richard Lewis wrote:
> > [...]
> > I think all it needs is
> > /etc/systemd/system/chkrootkit.service.d/override.conf with
> >
> > [Service]
> > ProtectSystem=strict
> >
> > (you can do "systemctl edit chkrootkit.service" and it will make such
> > a file and reload it,
> > you can then do systemctl start chkrootkit and it should be used)
> > That should solve the problem for the daily check. Can you see if that
> > it works. it's probably useful anyway)
>
> That works perfectly, thank you!

Quick update: I've been testing this, and whille it usually works it
can prevent the output being emailed with the following:

Dec 28 00:01:45 hostname chkrootkit-daily[4050677]: mail:
mu_temp_file_stream_create() failed: Read-only file system
Dec 28 00:01:45 hostname chkrootkit-daily[4050677]: mail:
mu_temp_file_stream_create() failed: Read-only file system
Dec 28 00:01:46 hostname exim[4050709]: 2024-12-28 00:01:46
1tRKH4-00Gzm1-00 Failed to create spool file
/var/spool/exim4//input//1tRKH4-00Gzm1-00-D: Read-only file system
Dec 28 00:01:46 hostname exim[4050709]: 2024-12-28 00:01:46
1tRKH4-00Gzm1-00 Cannot open main log file "/var/log/exim4/mainlog":
Permission denied: euid=109 egid=113
Dec 28 00:01:46 hostname exim[4050709]: exim: could not open panic log
- aborting: see message(s) above

I believe this only(?) happens if the report is large enough. i assume
we can allow more of /var to be read-write and avoid this
possibly the first error is from mailutils -- i remember failing to
identify this before, unfortunately without success.

[toc] | [prev] | [next] | [standalone]

#1226146

On Sat, 28 Dec 2024 21:15:34 +0000 Richard Lewis
<richard.lewis.debian@googlemail.com> wrote:
> On Sun, 15 Dec 2024 22:40:51 +0000 Julian Gilbey <jdg@debian.org> wrote:
> > On Wed, Dec 11, 2024 at 11:43:18PM +0000, Richard Lewis wrote:
> > > [...]
> > > I think all it needs is
> > > /etc/systemd/system/chkrootkit.service.d/override.conf with
> > >
> > > [Service]
> > > ProtectSystem=strict
> > >
> > > (you can do "systemctl edit chkrootkit.service" and it will make such
> > > a file and reload it,
> > > you can then do systemctl start chkrootkit and it should be used)
> > > That should solve the problem for the daily check. Can you see if that
> > > it works. it's probably useful anyway)
> >
> > That works perfectly, thank you!
>
> Quick update: I've been testing this, and whille it usually works it
> can prevent the output being emailed with the following:
>
> Dec 28 00:01:45 hostname chkrootkit-daily[4050677]: mail:
> mu_temp_file_stream_create() failed: Read-only file system
> Dec 28 00:01:45 hostname chkrootkit-daily[4050677]: mail:
> mu_temp_file_stream_create() failed: Read-only file system
> Dec 28 00:01:46 hostname exim[4050709]: 2024-12-28 00:01:46
> 1tRKH4-00Gzm1-00 Failed to create spool file
> /var/spool/exim4//input//1tRKH4-00Gzm1-00-D: Read-only file system
> Dec 28 00:01:46 hostname exim[4050709]: 2024-12-28 00:01:46
> 1tRKH4-00Gzm1-00 Cannot open main log file "/var/log/exim4/mainlog":
> Permission denied: euid=109 egid=113
> Dec 28 00:01:46 hostname exim[4050709]: exim: could not open panic log
> - aborting: see message(s) above
>
> I believe this only(?) happens if the report is large enough. i assume
> we can allow more of /var to be read-write and avoid this
> possibly the first error is from mailutils -- i remember failing to
> identify this before, unfortunately without success.

I believe the following is needed in override.conf -- this allows exim
to write its logs and send the final email, and mailutils (and others)
to have /run/chkrootkit as a writeable TMPDIR while the real /tmp
stays "protected". (this last is needed if mail is provided by
mailutils, and is sensible anyway)


[Service]
ProtectSystem=strict
ReadWritePaths=-/var/spool -/var/mail -/var/log
RuntimeDirectory=chkrootkit
Environment=TMPDIR=/run/chkrootkit

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web