[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Nov 2019 08:00:37 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: module loading / systemd bug report / suggestion /
my Debian packaging rationale
Hi,
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]
>
OK
> > 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
it.
> >> # 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]
> >> 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
>
Thanks,
Adam
> Kind regards,
> Patrick
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.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.
