Real Ubuntu and Debian do not have LINUX_VERSION_LIKE set. They are
different enough to consider them as a different distribution.
Tests targetting any of distributions based of those two should check
both, LINUX_VERSION and LINUX_VERSION_LIKE.
Improve handling of kenrel files
/boot/vmlinuz-linux-lts
/boot/vmlinuz-linux
/boot/vmlinuz-lts
by updateing RegEx and adding elif
this corrects issue where version is identified
as 'linux' or 'lts' causing false report that a
reboot is needed
Apple doesn’t disclose when it stops providing security updates for
macOS versions. There’s no consensus on when the exact EOL date is.
Lacking that information, I applied the following ruleset, which is
driven by what people have observed, and seems pragmatic enough:
- From Mac OS X 10.0 through 10.4, a version 10.N would be considered
EOL on the day the first patch-level update 10.(N+2).1 for its
N+2 successor was released.
- Starting with 10.5, Apple began to support three versions at the same
time. For 10.5 itself, the EOL date is difficult to pin down so I
went with 2011-06-23, the date given by the English-language
Wikipedia.
- From 10.6 through 10.11, a version 10.N would be considered EOL on
the day the first patch-level update 10.(N+3).1 for its N+3 successor
was released.
- Starting with macOS Sierra (10.12), Lynis counts the patch level.
Any version 10.N.P can be considered EOL on the day 10.N.(P+1)
is released. If that hasn’t happened, the EOL date is the day
10.(N+3).1 is released. If neither has been released, 10.N.P has
no EOL date.
Before parsing /etc/debian-release and /etc/lsb-release,
it is now checked if the variable LINUX_VERSION is already set.
This fixescisofy/lynis#1003, but has some side effects.
This will affects Ubuntu and Debian based distributions, like:
- Pop!_OS (Ubuntu based)
- Kali (Debian Based)
- Raspbian
- ...
Unfortunately this will likely skip/brake a few tests for those
distributions, as they are not considered to be Ubuntu or Debian
anymore. Linux Mint was already detected properly, but at least some
tests already had support for them (will other tests for Ubuntu are
skipped).
Those are tests I identified that will be skipped incorrectly now:
- BOOT-5180: Check for Linux boot services (Debian style)
It was already skipped on Linux Mint.
- KRNL-5622: Check default run level on Linux machines
This will only be skipped if systemd is not installed. It is
already skipped on Linux Mint in this case.
- KRNL-5788: Checking availability new kernel (sic!)
This was already skipped on Linux Mint.
- PKGS-7388: Check security repository (...)
It will now be skipped for all distributions that do use the
Debian / Ubuntu security repositories but are not detected as such
anymore (like Pop!_OS). It will now be correctly skipped on
Raspbian. This test was already aware of Linux Mint.
- PKGS-7390: Check Ubuntu database consitency
I am not sure why this test is Ubuntu only, thus it already
skipped on Debian and Mint.
- PKGS-7394: Check Ubuntu upgradeable packages
I am not sure why this is for Ubuntu only, too.
I think this should be feature tested instead, as
apt-show-versions can be installed on any Debian based
distribution as well..
- PKGS-7366: Checking if debsecan is installed (...)
While it may be correct to skip, debsecan remains usefull if
package versions, patches and vulnerability fixes are very close
on Debian itself.
It is the correct behaviour to not do this test on Ubuntu and
Ubuntu based distributions, as Canonical does not provide the
required databases.
- PKGS-7420: (Autoupdates)
Linux Mint was already skipped on this test.
I think this could be solved by introducing a variable like
LINUX_VERSION_PARENT. On Linux Mint it would be set to Ubuntu, on e.g.
Kali Linux the veriable has the value Debian. Tests can use this variable
to check if it is broadly applicable, and then check if the specific
distribution is excluded.
On systems without dbus timedatectl does not work.
Thus it is checked if timesyncd currently runs and when
/run/systemd/timesyncd/synchronized was last modified.
Timesyncd touches this file on any sucessfull synchronization.
This is documented in systemd-timesyncd(8).
The new test for successfull documentation has the id TIME-3185.