[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Jun 2020 17:31:45 +0200
From: Mikhail Morfikov <mmorfikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: The lkrg.service for systemd
On 21/06/2020 14:58, Solar Designer wrote:
> There's yet another issue, though: LKRG may take a little while to
> initialize before it's fully monitoring for attacks and enforcing its
> configured policies, yet the boot process may concurrently proceed
> further and e.g. start crond and an exploit from there.
>
> Do you have suggestions on how to make system boot process wait before
> advancing to a phase where user code may run until LKRG is ready?
The Before=sysinit.target would take care of holding the system boot till
the LKRG module finish loading. The regular services, like cron, are started
after the basic.target is reached (which is after sysinit.target). So
basically this dependency would do the job with ease.
>
> What would you suggest we put into the documentation for those wanting
> to use other init systems?
I don't really know other init systems -- I use Debian on all of my machines,
and this distro (like many others) defaults to systemd, and this move has
been made some years ago. If there are any people who use some other inits, I
would suggest that they speak about the proper support here, like I do with
systemd.
>
> With the 0.8 release being (hopefully) just around the corner, I think
> switching to /etc/modules-load.d/99-lkrg.conf is too invasive a change
> right now, but perhaps we can change the Before/After lines for now and
> plan on making further changes for 0.9.
>
>> I would suggest something like:
>>
>> After=systemd-modules-load.service # to make sure all other modules are loaded
>> Before=sysinit.target # to load LKRG as fast a possible
>
> Can you please test this suggestion of yours and confirm that it works?
>
I tested, and I had to completely rewrite the systemd.service . Here's how it
looks now:
--------------
[Unit]
Description=Linux Kernel Runtime Guard
Documentation=https://bitbucket.org/Adam_pi3/lkrg-main/src/master/README
DefaultDependencies=no
After=systemd-modules-load.service
Before=systemd-sysctl.service
Before=sysinit.target shutdown.target
Conflicts=shutdown.target
[Service]
Type=oneshot
ExecStart=/sbin/modprobe -v p_lkrg
#ExecStop=/sbin/modprobe -v -r p_lkrg
RemainAfterExit=yes
Restart=on-failure
[Install]
WantedBy=sysinit.target
--------------
The *DefaultDependencies* has to be used, since this is early boot service. When
you use it, you have to take care of stopping the service, i.e. to add
*Before=shutdown.target* and *Conflicts=shutdown.target* dependencies. I'm not
sure what would happen in this case when the two are omitted because there's no
real service that has to be stopped when system reboots/shutdowns. Anyway, after
adding them, when system reboots/shutdowns the *ExecStop* command will be
executed. So I commented it out because removing the module before system reboot
is pointless. Using *After=systemd-modules-load.service* will make sure that
LKRG will load after any other module does, *Before=systemd-sysctl.service* is
for sysctl config to work, so if you block module loading via
*lkrg.block_modules*, it will work. The *Before=sysinit.target* is redundant,
but I keep it just to explicitly show where the LKRG service is assigned to. I
also use *modprobe* for *ExecStart* and *ExecStop* commands (the -v flag can be
removed). I changed the *Type* from *Simple* to *Oneshot as it better fits in
this case, especially with *RemainAfterExit=yes*. Also *WantedBy* changed from
*multiuser.target* to *sysinit.target*.
Here's you can see how it works[1]. This is very beginning of the boot phase,
and you have first the systemd-modules-load.service , when it finishes,
lkrg-dkms starts and the module loads for ~1,5s. When it finishes, then
systemd-sysctl.service is launched and the rest of boot continues as ususal.
[1]: https://i.imgur.com/YCcPd60.png
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
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.
