I don’t know if that is possible without using a package. For example to trigger DKMS, a new kernel package needs to be installed. It may be possible to reinvent all of this (call DKMS ourselfes) but the bigger the hack, the more likely it will have bugs.
question | with a package | without a package
What kernel version is installed? | Check kernel package version. | ?
How to remove that kernel? | apt purge… | ?
By not using a package many things get messy / lots of code duplication / bugs.
I think we should sign all modules during build. After the build, we can sign lkrg, vbox guest additions etc. with scripts/sign-file, then we can destroy the private key with shred -zu in certs/ and enforce only signed module loading. This way, only signed modules can load, vbox won’t break and we don’t need to worry about a private key.
But even while the newer version of DKMS supports module singing, modules such as virtualbox do not make use of it. Automated module signing during kernel upgrade and module upgrade is still a non-trivial challenge.
When modules are upgraded, these need to be recompiled. This happens automatic by DKMS (but not yet with module signing). Therefore we cannot delete the signing key. But we could restrict signing key access with appaprmor-profile-everything.
But Travis CI is Ubuntu based. Not sure it is worth the effort making the CI build compatible with Ubuntu. Did run into some issues due to version differences (Linux 4.15 vs 4.19) but now fixed. I don’t know if there is a Debian buster based CI. Inquired just now:
The differences interactive vs non-interactive could be a result of different installed packages / programs on the build machine.
Fixed this on my local machine.
Please review that change. Please check best settings for prempt on everything.
CONFIG_HAVE_PREEMPT_LAZY=y is getting enabled either way by running make deb-pkg. Even if set to
# CONFIG_HAVE_PREEMPT_LAZY is not set
Please compare .config prior make deb-pkg with .config after make deb-pkg. It changes. And that I find very unusual, weird (not implying malicious, just saying to not have this misinterpreted / misquoted by third parties).
Better to rename from hardened-vm-kernel to hardened-kernel? Reason is the compile script and install hacks might be shared. Ideally for host kernel we’d offer precompiled but with a drop-in config snippet we’ll let the user opt-in for local self-compilation. Using all the same code but just some variables change depending on VM or host.
Various /proc files exist to monitor process memory utilization:
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
It was called “brain-dead” and a security risk by grsecurty.
It was also used in exploiting rowhammer to gain kernel privileges.