Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Nov 2019 08:00:37 +0100
From: Adam Zabrocki <>
Subject: Re: module loading / systemd bug report / suggestion /
 my Debian packaging rationale


On Wed, Nov 13, 2019 at 10:30:00AM +0000, Patrick Schleizer wrote:
> 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.

No concerns from my side.

> >> # 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.

Fair point.

> > 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?

I believe it's just a personal preferences. There is no real 'need' for using 

> >> # 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?

Yep. I'm using LKRG in 'traditional way', but some people find systemd service 
file easier. That's why it's there.

> > 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.

That's one of the goals, yes.

> 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.

Yep. We have/had this in mind as well. LKRG can be a core-logic module which 
might be wrapped and use in such a way. It can be a 'brain' of any ATP-like 
systems as well.

> 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]
> >>
> >>
> >> I am not sure that should be
> >>
> > 
> > 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:


> Kind regards,
> Patrick

pi3 (pi3ki31ny) - pi3 (at) itsec pl

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.