[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <408c3341-6161-6e98-dea7-30ffd8c0c271@riseup.net>
Date: Wed, 13 Nov 2019 10:30:00 +0000
From: Patrick Schleizer <adrelanos@...eup.net>
To: lkrg-users@...ts.openwall.com
Subject: Re: module loading / systemd bug report / suggestion /
my Debian packaging rationale
Adam Zabrocki:
> It should be fine in most environment. What do you think?
It's OK with me, but I still don't think a systemd unit file is the
correct way to load a kernel module.
In the Debian package which I am intending to create, I'd just use
system'd /usr/lib/modules-load.d mechanism. [Unless you'd oppose that.
Then I'd follow upstream LKRG wish.] Other related concerns are replied
to below.
>> # module loading
>>
>> Another approach would be to not use a systemd unit file but instead
>> system'd /usr/lib/modules-load.d mechanism.
>>
>> A drop-in configuration file snippet in folder /usr/lib/modules-load.d
>> i.e. /usr/lib/modules-load.d/p_lkrg with contents:
>> p_lkrg
>>
>> Works for me on Debian 10, buster. I think that way the module gets
>> loaded even earlier, which should be even better.
>>
>> I am considering to use that mechanism for the Debian packaging that I
>> am planning. Unless there is a reason not to use this approach.
>>
>
> Interesting. I was not aware about that feature. However, I can see a few
> caveats:
>
> 1. You should probably provide argument to the LKRG module to change default
> log level (1) to be 0.
The /etc/sysctl.d mechanism could be used. If I had to bet, I'd bet it
is processed by systemd even before module loading. So module arguments
would be load just at the right time before LKRG module load. Even the
/usr/lib/modules-load.d mechanism might allow to pass sysctl parameters,
I don't know yet.
> During the boot, kernel might generate a lot of events
> which forces LKRG doing verification and you might receive a lot of "System is
> clean!" messages.
I am not worried about these. Most users (that I am working with)
wouldn't notice any log / kernel messages. [1]
> It can be configured via p_init_log_level argument.
> 2. I believe you would still want to have systemd service file which could (in
> the later phase of booting) reconfigure LKRG via sysctl interface (like it is
> doin now).
Why use a systemd service file if a system administrator could easily
use sysctl directly?
>> # module unloading
>>
>> scripts/bootup/systemd/lkrg.service uses "ExecStop=/sbin/rmmod p_lkrg".
>> Why unload the kernel module at shutdown? Perhaps malware could
>> specifically target to run after that moment? Any reason to unload?
>> Could just keep the module?
>>
>
> The reason why we have "ExecStop" is to provide convinient way of managing LKRG
> via 'service' interface. E.g. if you want to update LKRG to the newer version,
> you can execute from the LKRG folder just the following commands:
>
> make uninstall
> make install
>
> under-the-hood old LKRG will be unloaded (via 'systemctl stop lkrg.service' +
> 'systemctl disable lkrg.service' command).
>
> You might also want to stop LKRG for some reasons and reenable it again later.
> This is an easy way of doing it.
Right. However, using rmmod directly would be similar easy?
> Of course you are right that it is not ideal. The best would be to not have
> unloading feature at all (which is possible to achieve from the simple
> source-code modification) and at the same time set LKRG to the 'hiding mode'.
Yes. I'd prefer that. At the moment I am not convinced that LKRG
unloading (without reboot) is an important feature.
[1] I am coming from a usability perspective. What I am working on is
taking great existing pieces of software that are difficult to use for
laymen and transforming it into "mobile phone app style". I.e. make it
easier to use for "laymen". "Dumbing it down." "ELI5". Of course, I am
aware that there are many levels of being a technical vs non-technical
users. Levels such as
- a) Windows desktop users, never heard of Linux
- b) Linux desktop users
- c) Whonix users
- d) aware of and installing LKRG
By goal is to make LKRG easily available to groups of c) and b). Many of
these won't be interesting in and/or understand module unloading, kernel
messages, and whatnot.
LKRG is not something that many users would even notice. But it's added
value. LKRG would do its thing without the user noticing much.
Predicting from my experience, most users wouldn't be aware of LKRG. My
goals are to provide easy installation, potentially installation by
default. Providing value to non-technical users without them requiring
technical knowledge.
One step at a time, but I am already wondering how a graphical user
interface (GUI) for LKRG could be provided. Potentially invented by me.
If exploits are detected (and killed) the user could be presented with
the kernel log message shown in a (zenity) popup. Otherwise if LKRG
messages are "hidden" in the kernel log, I think most users wouldn't
notice even if LKRG had a chance to and did something good.
Maybe LKRG can be considered similar to antivirus:
"A tool that is useful to check if your security concept is efficient.
But not part of the security concept (hardening, ...) itself. If your
antivirus found (and removed) a virus, it means your security
precautions failed. Shut down the machine and move on to disaster
recovery procedures."
>> # install section
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> I am not sure that should be WantedBy=sysinit.target.
>>
>
> My knowledge of 'systemd' service is limited. If I understand it correctly, you
> are suggesting to load LKRG at the ealier stage, correct?
Yes.
Similar discussion which made me unsure if I am right about this:
https://github.com/rustybird/corridor/issues/43
Kind regards,
Patrick
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.
