Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: audit init message shows 0-second timestamp on aarch64 #155

Open
rgbriggs opened this issue Oct 4, 2023 · 2 comments
Open

BUG: audit init message shows 0-second timestamp on aarch64 #155

rgbriggs opened this issue Oct 4, 2023 · 2 comments
Labels

Comments

@rgbriggs
Copy link
Member

rgbriggs commented Oct 4, 2023

First audit message, audit initialization, on aarch64, has zero-second timestamp. The msec counter appears to be running. It appears audit is initialized before the system clock.

Ex:
audit: type=2000 audit(0.360:1): state=initialized audit_enabled=0 res=1
audit: type=1403 audit(1692710902.940:3): auid=4294967295 ses=4294967295 lsm=selinux res=1
audit: type=1305 audit(1692710990.312:85): op=set audit_enabled=1 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1

Expected results:
The problem was discovered because logwatch does not match these lines, expecting more digits in the parentheses. This assumption works elsewhere but not on aarch64.

@pcmoore pcmoore changed the title audit init message shows 0-second timestamp on aarch64 BUG: audit init message shows 0-second timestamp on aarch64 Oct 4, 2023
@pcmoore pcmoore added the bug label Oct 4, 2023
@pcmoore
Copy link
Member

pcmoore commented Oct 4, 2023

Quick silly question: does this system have a working RTC? There are a number of smaller aarch64 systems, e.g. RPi 4 and below, that do not have a RTC and I imagine one might see something like this before the system has a chance to sync the clock to an external source.

@pcmoore
Copy link
Member

pcmoore commented Oct 4, 2023

Quick silly question: does this system have a working RTC? There are a number of smaller aarch64 systems, e.g. RPi 4 and below, that do not have a RTC and I imagine one might see something like this before the system has a chance to sync the clock to an external source.

Nevermind, I just checked on one of my aarch64 systems with a RTC and I'm seeing a similar timestamp issue.

We should obviously look into this, but we should also be prepared for the idea that this may not be something we can resolve. We want audit up and running as quickly as we can on the system, if we can't move the clock initialization sooner in the kernel startup we may have to live with this as a known issue on some systems/arches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants