How to disable interactive shell from console?

[rdmitry0911]

Hi guys, for security reasons I'd like an option to disable interactive shell from console, leaving it available only via dropbear. it seams, that ZBM Command-Line Parameters might be the way to implement this feature. Maybe there are some recommendations on how best and easiest to do this, while remaining within the framework of ZBM?

[ahesford]

ZBM exposes a lot of filesystem manipulations and other potentially compromising capabilities right from the menu. You can chroot into a boot environment, roll-back snapshots, rewind pool checkpoints or drop to a recovery shell and have your way with the system. Limiting access to the recovery shell would only mitigate one avenue of attack, and incompletely. Because ZBM is written in shell, I assume it would be trivial for a determined user to interrupt its control flow and be dropped to a shell even if we tried to disable the Ctrl+R hot key.

This kind of hardening is not something we are interested in entertaining because it quickly balloons into a major consideration of what features to disable, when to do so, and whether they can truly be meaningfully disabled. The best way to protect the console from unauthorized access is to encrypt your filesystems; a local user will be unable to take any action until the pool is unlocked. Still, when coupled with dropbear, there is a small window of exposure where the local user can interrupt the password prompt after learning that a remote user has unlocked the pool. The local user could force access to a shell, kill dropbear to disconnect the remote user, and have control of the unlocked filesystem. This kind of problem can't be solved without a major redesign of some core parts of ZBM and some security expertise that this team lacks. Remote access to ZBM should be understood as favoring convenience over security.

[rdmitry0911]

What I want to achieve is to maintain control over the trusted boot environment during system boot, when the administrator is not at the computer. If an attacker does not have access to the local zbm console during boot, then he will have no way to intrude on the boot process, while the administrator will be able to perform all the functions he needs remotely via ssh. An additional key in zfsbootmenu, for example, zbm.disable_console_input could launch at startup
something like evtest --grab /dev/input/event1 >/dev/null (if the keyboard is event1) For me, this method effectively blocks input on the console, leaving it possible to work via ssh

[GregorKopka]

As soon as an attacker has physical access to the system... all bets are off anyway.
🤷‍♂️

[rdmitry0911]

Why do you think so? What he can do without input capability? I'm not talking about cold boot or DMA attack

[GregorKopka]

Boot from other media. Or smash the drives, should the goal be destruction.

Then he's in the same place as having a rescue shell with input capability.

[rdmitry0911]

No, I'm only worrying about data privacy during automatic decryption. Attacker can boot from another media or have a rescue shell, but in this case this will not be the trusted environment and stops automated disk decryption. Administrator will be notified, that the system is booted in compromised (not trusted) environment. This is the point. The attacker can not get inside the boot process without breaking the trusted environment if there are no physical input devices available

[ahesford]

This discussion is getting way off topic. You don't have to go home, but you can't stay here.