[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 20 Jun 2020 23:39:47 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: The lkrg.service for systemd
Hi,
I was hoping that Adam and/or someone familiar with multiple init
systems would reply, but since no one did let me share some thoughts:
On Fri, Jun 05, 2020 at 05:36:49PM +0200, Mikhail Morfikov wrote:
> You provide the lkrg.service file for systemd. It basically loads/unloads the
> LKRG module and currently has the following boot dependencies:
>
> After=basic.target
> Before=network.target
As I recall, part of the rationale here was to load LKRG before a
potential attacker could connect over network. However, this doesn't
account for the possibility of someone with an account on the system
putting an exploit on cron to run on next bootup (e.g., using Vixie
Cron's "@reboot" feature) and taking advantage of that exploit later.
> There's another service called systemd-modules-load.service which takes care
> of loading any modules defined in /etc/modules or /etc/modules-load.d/ . It
> has the following deps:
>
> Before=sysinit.target shutdown.target
>
> The difference here is *basic.target* vs. *sysinit.target* . According to[1]
> sysinit.target is a way earlier in the boot chain than basic.target. In the
> case of my system, systemd-modules-load.service is started almost at the
> beginning of the boot phase, and the network.target (which is in Before= in
> lkrg.service) is almost at the end of the boot process.
>
> Wouldn't be better to use the same deps as in systemd-modules-load.service ?
Maybe yes. However, then LKRG's load order vs. other modules would vary
between bootups, which would lower the confidence that the system will
always boot up correctly after the sysadmin having tested that it does
so once. That would be a drawback for unattended servers. Since LKRG
checks integrity of other modules, having them loaded before or after
LKRG makes a difference for how and when LKRG starts monitoring them.
So maybe we should use something inbetween, like this:
After=sysinit.target
Before=basic.target
> What about other inits? Not all of the available init systems use this
> .service file. Maybe is it better to provide a file with the module name and
> place it under /etc/modules-load.d/ , so all the inits be supported? What do
> you think?
Do other init systems support /etc/modules-load.d? Which ones? On
RHEL7+, this directory comes from the systemd package. On RHEL6, it is
not available. So it looks systemd-specific to me.
There's also the question of how to pass module parameters and/or
override some sysctl's right after loading LKRG into the kernel. For
module parameters, there's /etc/modprobe.d, which should work regardless
of the init system in use as long as it uses modprobe (and we provide a
unit or init file or such that triggers loading of LKRG). However, for
sysctl's we need to execute a script, which is more init system
specific. Unfortunately, Adam hasn't implemented support for profile_*
as module parameters yet. When he does, we won't need to be able to set
LKRG sysctl's on bootup.
> [1]: https://www.freedesktop.org/software/systemd/man/bootup.html
Thank you for this reference, it helps.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
