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