search

lavabit / robox

The tools needed to robotically create/configure/provision a large number of operating systems, for a variety of hypervisors, using packer.
620 stars 139 forks source link

Reduce disparities with default Debian installer settings #247

Closed EmmanuelKasper closed 1 year ago

EmmanuelKasper commented 2 years ago

Debian developer here speaking, while looking at https://github.com/lavabit/robox/blob/master/http/generic.debian11.vagrant.cfg I noticed one setting installer config, which are not strictly required by Vagrant, and also diverges for a standard Debian install for no clear reason.

    sed -i -e "s/.*PermitRootLogin.*/PermitRootLogin yes/g" /target/etc/ssh/sshd_config ; \

considering Vagrant is supposed to run with the vagrant user, then sudo to root, I think we could remove this setting ?

The previous Debian boxes from the Debian project did not use that setting either.

Tell me if you would consider a pull request here, or if changing this setting would break something I don't see in the test suite.

ladar commented 2 years ago

@EmmanuelKasper hi, thank you for speaking up but I believe you're looking at the auto install config. The way things work, root is only enabled our install. And that is so once the guest reboots packer can connect via SSH using the root account..

The way it's supposed to work is that once all of the config modules (aka bash scripts) are done running the password for the root account is randomized, the root account is locked (and or pointed at the nologin shell), and SSHD is reconfigured to deny root logins. Although I'd have to double check, as we might not do all 4 things for every distro.

The bottom line is that when you actually download and run the vagrant image, you can't login directly as root, but only sa the vagrant user, who can then sudo up to root.

If you're concerned about security, and a developer, there is actuallya much bigger issue I can discuss with you. But solving it properly will require writing logic that runs during the first login, so the appropriate steps can be taken to reconfigure and lockdown the vagrant user account properly.

ladar commented 1 year ago

@EmmanuelKasper I'm going to close this issue. Like I said in my reply above I'd welcome a PR which improves things. We could certainly undo the permit root login change in the cleanup scripts, or someplace that is appropriate. In fact, it might make sense to create a "common" script module which is against every distro, and disables root logins over SSH (perhaps even password logins as well).

It's just a tricky issue, which might break things. For example packer uses those root login credentials to login and issue the shutdown command at the end, which gracefully shuts down the image. So making a change in a module to early, and everything breaks (in theory it should as long sshd isn't restarted or HUP'ed). I'm also worried a distro might detect the config change and reload sshd automatically (more systemd magic), which which cause breakage as well. And assuming that isn't happening already, it's probably only a matter of time until someone adds that "feature".

Personally I haven't given this issue much thought because we DO randomize the root password. So And that st4ring is different for every box, on every release, and I don't keep or store that value. And the root account is also locked as added protection. So at least in theory the SSHD setting shouldn't matter. But theories can fail, so extra security layers never hurt.