Necessary kernel config for a minimal working system

VannTen · 2020-07-08 14:12:04

Hi.

I'm currently trying to build myself a live system on a USB stick.
The initial purpose was to have a minimal separate system for handling my gpg master key operations,
but it has since shifted to a learning experiment.

I'm using archiso (a bit modified) for that purpose, and I'm currently stuck on the custom kernel part.
I'm trying to build a kernel with only the necessary parts, but I currently encounters a problem when systemd
start : it is unable to open any tty

This is in single `user mode (launched in qemu)

Run /sbin/init as init process
: can't log to /dev/tty5
starting pid 15, tty '': '-/bin/sh'
-/bin/sh: can't access tty: job control turned off

In multi user, it loops trying to open /dev/tty{1,5}

I do have the CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT set to y in the kernel config,
as well as the tty devices drivers (CONFIG_TTY, CONFIG_VT, CONFIG_VT_CONSOLE... ) ; and so I'm not sure
what's missing.
My complete kernel config : http://ix.io/2rbS

I'm quite sure that my custom kernel is the trouble since when I use the stock arch one, it boots flawlessly.
I've googled my error messages, and all I could find was about either missing tmpfs for dev / missing tty drivers /
udev failing somehow to correctly create those devices. I believe I have what's needed for those, but there is obviously
something missing.

Could any of you have an idea on what kernel part I must include and do not ? Or how I could find out myself ?
Maybe this is related to the particular options systemd for arch is compiled with ?

I would be thankful if anyone have a clue on that one

Trilby · 2020-07-08 14:20:34

Have you tested with a simpler init?

If you're going to the length or parring down your kernel config, sticking with systemd seems odd. That's like eating a bacon-double-cheeseburger topped with two fried eggs and and a onion ring on a glazed donut bun but washing it down with a diet coke.

If another init (e.g., busybox's) works but you still want to use systemd, you could check systemd's upstream docs for what kernel configs are required, or check the gentoo wiki, but you may need to add a lot back.

VannTen · 2020-07-08 15:26:46

I did not. Initially I wanted to stay with arch packages in order to minimize my work.
I'm not staying that I want to stick with systemd no matter what, but my approach was more to go from the archiso working state,
and take out stuff. Compiling a custom kernel with the arch build system is in the wiki ^.

That said, point taken. I'll check on busybox.

Regarding the gento wiki link, I already looked there and activated the required options (when there is a mapping) (unless I've made a mistake), hence my question here.

Last edited by VannTen (2020-07-08 15:28:41)

Trilby · 2020-07-08 15:43:33

VannTen wrote:

Initially I wanted to stay with arch packages in order to minimize my work.

Ok, but for what purpose are you adjusting the kernel config then? What do you hope to gain by it? Any benefits in kernel size, memory use, or any other metric of efficiency will be obscenely trivial compared to what could be gained by simplifying the userspace tools.

ewaller · 2020-07-08 16:00:06

To answer the question, whether or not it is a good approach, I would:

Boot the install media and capture the output of lsmod.
Reboot into your system and acquire the kernel source.
Start with the current configuration (available in /proc/config.gz).
Using the kernel's make option make menuconfig, locate all the modules that had been in use in the install environment and configure them as built in instead of as a module. Turn off all other modules.
Build your kernel, copy it to your install media, configure a bootloader to load the kernel and point it at you init system. You should not need an initrd unless you are dealing with microcode patches; most likely not necessary.

Edit: You may want to look through the Gentoo documentation on how to configure a stand alone kernel; in this case, they probably have much better documentation than do we.

Last edited by ewaller (2020-07-08 16:01:52)

VannTen · 2020-07-08 17:25:16

@Trilby
The initial purpose was more about capabilities than size, like disabling networking support in kernel.
The objectif would be something like a "clean room" system ; I started with the kernel as it seems to me it would be more work to reconstruct those capabilites for a potential attacker (am I wrong here ?).

@ewaller
I hoped to avoid doing that, but I think I will have to, indeed... (the lsmod part).
Regarding the initrd : it does not change whether or not I have the required modules, does it ? Once I have it working that way, I'll consider build everything into the kernel and ditching the initrd.

Gentoo docs and forums are indeed quite good. I have found similar problems with seemingly non existing tty devices, but the cause in the threads i saw was the missing kernel config for devtmpfs / the tty devices drivers.

Trilby · 2020-07-08 17:31:50

VannTen wrote:

The objectif would be something like a "clean room" system ; I started with the kernel as it seems to me it would be more work to reconstruct those capabilites for a potential attacker (am I wrong here ?).

Ah, I was not considering a goal like that. I'm still not sure it makes sense: what kind of attack does that prevent? Disabling networking in the kernel will prevent you from using any networking, but the only real attack it could prevent would be from someone with physical access to the machine starting some network-facing service or downloading malicious materal. But if they have physical access to the machine, that's really the least of your concern as they have far easier ways to get that malicious material on your machine or steal other material off of it. But perhaps this is too tangential.

VannTen · 2020-07-08 20:40:12

Trilby wrote:

what kind of attack does that prevent ?

The idea behind the setup would be an offline master key, kept on encrypted usb keys.

The live usb would only be used (on separate hardware, if I want to be truly paranoid... ) to make subkeys, sign other people uid (in short, operations which need the secret part of the master key).
Signatures and public part of new subkeys (keeping the private on smartcard like a Yubikey) go out on of the system using usb or sd card.
Other peoples keys (to be certified) go in the same way.

So, given these premises, the threat model would be :
Machine A is the daily used one, compromised in that threat model.
Machine B is the "secure system".
Master private key storage is only connected to the Machine B.
Exchange medium (the usb or sd card used to transport public keys and signature) is connected both to A and B.
The attack model would be :
1 compromise Machine A,
2 infect the exchange media,
3 compromise machine B,
4 exfiltrate private key material from Machine B.

I think reducing the kernel modules used can make step 3 and 4 harder :
- for 3 : less fs modules in which to find a bug to exploit when mounting the storage
- for 4 : less possibility to exfiltrate data out of the system (network, make the leds blink in pattern, sound from the hard drive etc)
(Of course the attack could exfiltrate by the exchange medium... but you could use a separate one ^).
Reducing the software used inside is also a valid concern, ofc.

Obviously, this is overkill for almost everyone, and does not protect against rubber host cryptanalysis... But I did said it was for learning.

VannTen · 2020-07-09 15:13:13

After having added the module provided by lsmod, I have still the same result... (i didn't add joydev or mousedev but those missing should not prevent tty from being created, or somehting is very wrong...)
I'm probably gonna have to start from the arch config and chop off pieces by pieces.

Head_on_a_Stick · 2020-07-09 18:00:57

Have you tried

make localmodconfig

https://wiki.archlinux.org/index.php/Ke … figuration

pk.gmp · 2020-07-10 07:07:57

You may want to check modprobed-db https://wiki.archlinux.org/index.php/Modprobed-db

One way to use it in PKGBUILD.. is in your "prepare()" ....

make olddefconfig
make xconfig

## In place of this...
##### make prepare

# Build only those modules which you modprobed and hand crafted..
make LSMOD=$HOME/.config/modprobed.db localmodconfig

VannTen · 2020-07-10 10:24:31

@Head_on_a_Stick
What's what I'm doing as part of the "start from arch config" part. Unfortunalety it removes too much when I run it from my current system, since some thing needed in the livecd are'nt needed in my installation.

@pk.gmp
I did'nt that package, seems that it could help indeed (and be a little more conservative than just localmodconfig), Would probably suffer of the same thing cited above though.

Some results I have makes me think that the problem with the tty could have been the result of something beeing a module instead of a built-in (doing a make yes2modconfig re-triggered the problem).

Arch Linux

#1 2020-07-08 14:12:04

Necessary kernel config for a minimal working system

#2 2020-07-08 14:20:34

Re: Necessary kernel config for a minimal working system

#3 2020-07-08 15:26:46

Re: Necessary kernel config for a minimal working system

#4 2020-07-08 15:43:33

Re: Necessary kernel config for a minimal working system

#5 2020-07-08 16:00:06

Re: Necessary kernel config for a minimal working system

#6 2020-07-08 17:25:16

Re: Necessary kernel config for a minimal working system

#7 2020-07-08 17:31:50

Re: Necessary kernel config for a minimal working system

#8 2020-07-08 20:40:12

Re: Necessary kernel config for a minimal working system

#9 2020-07-09 15:13:13

Re: Necessary kernel config for a minimal working system

#10 2020-07-09 18:00:57

Re: Necessary kernel config for a minimal working system

#11 2020-07-10 07:07:57

Re: Necessary kernel config for a minimal working system

#12 2020-07-10 10:24:31

Re: Necessary kernel config for a minimal working system

Board footer