search

lkrg-org / lkrg

Linux Kernel Runtime Guard
https://lkrg.org
Other
404 stars 72 forks source link

feat(scripts): support OpenRC init system #197

Closed mrl5 closed 2 years ago

mrl5 commented 2 years ago

Description

introduce OpenRC bootup scripts

How Has This Been Tested?

I've tested it by running

# make uninstall
# lsmod | grep lkrg
# make install &&
  /etc/init.d/lkrg start &&
  lsmod | grep lkrg &&
  /etc/init.d/lkrg status &&
  rc-update add lkrg boot &&
  rc-update show | grep lkrg
# make uninstall
# lsmod | grep lkrg
# /etc/init.d/lkrg status
# rc-update show | grep lkrg

on OpenRC system (funtoo linux)

update after gathering requirements in this comment I've additionally run

# runlevel
N 3
# /etc/init.d/lkrg stop
# lsmod | grep lkrg;  echo $?
1
# /etc/init.d/lkrg start
# lsmod | grep lkr
p_lkrg                221184  0
# init 1
# lsmod | grep lkr
p_lkrg                221184  0

and ensured that p_lkrg module is not unloaded from the kernel on poweroff or reboot

solardiz commented 2 years ago

@mrl5 Also, you seem to have a GitHub-provided noreply e-mail address on the commit. You might want to change that to an address of your own, which you'd then add to your GitHub account.

solardiz commented 2 years ago

@mrl5 Is there any way for me to contact you about the misunderstandings I see in comments at https://bugs.funtoo.org/browse/FL-10115? That would be off-topic to discuss on this pull request.

mrl5 commented 2 years ago

@mrl5 Is there any way for me to contact you about the misunderstandings I see in comments at https://bugs.funtoo.org/browse/FL-10115? That would be off-topic to discuss on this pull request.

I've sent PM to your twitter account: https://twitter.com/solardiz

solardiz commented 2 years ago

@mrl5 BTW, for the sysctl file to provide (almost-)initial LKRG configuration, LKRG needs to be loaded before that file is processed (edit: otherwise those settings would not take effect at all). However, I don't see anything in the init script that would indicate its priority vs. other scripts. Did you look into that?

It's also desirable for security that LKRG be loaded before services such as sshd, cron, MTA/MDA, and unloaded late on system shutdown (if at all).

On pre-systemd Red Hat'ish systems with chkconfig, this would be controlled with lines like # chkconfig: 2345 55 25 in init files (comments for the shell, but magic for chkconfig). These indicated runlevels (2345 here) and start and stop priorities vs. other init scripts (55 and 25 here). Does OpenRC have anything similar? Does Funtoo use that?

Quite possibly we'll eventually drop unloading of LKRG on system shutdown somehow. This is currently mostly a side-effect of our uninstall/upgrade instructions.

mrl5 commented 2 years ago

@mrl5 BTW, for the sysctl file to provide (almost-)initial LKRG configuration, LKRG needs to be loaded before that file is processed (edit: otherwise those settings would not take effect at all). However, I don't see anything in the init script that would indicate its priority vs. other scripts. Did you look into that?

It's also desirable for security that LKRG be loaded before services such as sshd, cron, MTA/MDA, and unloaded late on system shutdown (if at all).

On pre-systemd Red Hat'ish systems with chkconfig, this would be controlled with lines like # chkconfig: 2345 55 25 in init files (comments for the shell, but magic for chkconfig). These indicated runlevels (2345 here) and start and stop priorities vs. other init scripts (55 and 25 here). Does OpenRC have anything similar? Does Funtoo use that?

Quite possibly we'll eventually drop unloading of LKRG on system shutdown somehow. This is currently mostly a side-effect of our uninstall/upgrade instructions.

thanks for bringing this up. it actually made me to take a step back and ask this question: https://github.com/lkrg-org/lkrg/issues/109#issuecomment-1175514381

TBH the only reason why I decided to do this pull request was to make OpenRC service per analogy to the existing systemd one. But now I'm really thinking to give up this idea and simply fall back to modules-load.d.

I'm pretty sure OpenRC takes care of correct loading order when modules-load.d is detected (like mentioned first sysctl file then modules as well as modules before other services). Additionally I don't think that it would unload the modules before shutdown.

If you agree with above statement I'd be happy to modify README to include some instructions for modules-load.d

update:

solardiz commented 2 years ago

I'm pretty sure OpenRC takes care of correct loading order when modules-load.d is detected

What makes you so sure?

like mentioned first sysctl file then modules

For LKRG, it should be the other way around! The sysctl's can't be applied before the module is loaded, they simply don't exist yet. For some other module, it could be different - maybe that other module does not have its own sysctl's, but its loading is affected by the kernel's sysctl settings. So there isn't a universal "correct" order that an init system could use.

Anyway, longer term we should probably move away from usage of sysctl's for initial configuration. We intended module parameters to be used for that, but then got contributed this file with all sysctl's based on our README, and I understand it's more convenient to edit than a list of module parameters all on one line, but it's also less reliable and is inherently racy.

I'd be happy to modify README to include some instructions for modules-load.d

Then we also need instructions for passing parameters to modules loaded that way.

Since you started this PR with an almost ready contribution, I thought we could accept it for now, then possibly drop both systemd and OpenRC specifics at some later time.

mrl5 commented 2 years ago

What makes you so sure?

It's an assumption :D sorry - it might sound misleading

Since you started this PR with an almost ready contribution, I thought we could accept it for now, then possibly drop both systemd and OpenRC specifics at some later time.

very well then - let me go through 2nd iteration of your CR so that I can apply fixes. I'll click on re-request review once I think I'm ready

solardiz commented 2 years ago

@mrl5 Perhaps you can actually test whether the sysctl's from the installed file take effect on system bootup or not? I mean when using OpenRC as implemented in this PR? My current guess is the init script probably runs too late for that. If so, we'll need to do something different... like the modules-load.d approach, if that one happens to achieve the desired order.

mrl5 commented 2 years ago

@solardiz for my convenience I decided to gather requirements for proper way of handling p_lkrg module by the init system dedicated service (I'm using RFC 2119 nomenclature):

  1. it MUST load p_lkrg module before sysctl config files are processed (esp. /etc/sysctl.d/01-lkrg.conf)
  2. it MUST load p_lkrg module as early after bootup as possible (esp. before services such as sshd, cron, MTA/MDA are started)
  3. it MUST unload p_lkrg module on explicit user command
  4. it SHOULD NOT unload p_lkrg module automatically at shutdown
  5. it MAY not load p_lkrg module if nolkrg kernel parameter was provided

pls suggest changes to above if I missed sth or misunderstood sth.

update with 4. I'll ofc investiage possible options with OpenRC but if this is a big concern then we can cosider changing it to

- 3. it MUST unload `p_lkrg` module on explicit user command
- 4. it SHOULD NOT unload `p_lkrg` module automatically at shutdown
+ 3. it SHOULD unload `p_lkrg` module on explicit user command
+ 4. it MUST NOT unload `p_lkrg` module automatically at shutdown

then I guess if user does /etc/init.d/lkrg stop it could print information about modprobe -r p_lkrg

solardiz commented 2 years ago

@mrl5 You got those requirements (1, 2, 3) and preferences (4, 5) right. The changes you suggest in "update" are also within consideration. Thanks!

solardiz commented 2 years ago

BTW, note that this PR looks like it'll clash with #200. I hope you don't mind rebasing if we happen to merge that other one first.

mrl5 commented 2 years ago

BTW, note that this PR looks like it'll clash with #200. I hope you don't mind rebasing if we happen to merge that other one first.

I don't mind rebasing in case of git conflict :) I hope you don't mind reviewing one more time in case this happens :D

solardiz commented 2 years ago

Looks good to me. I'll merge now. Thank you!