Implementing Users/Passwords in Petitboot

[Stewart Smith]

Samuel Mendoza-Jonas <sam at mendozajonas.com> writes:
> In some circles there has been talk of password-protecting Petitboot to
> restrict access to certain configuration options or the ability to modify disk
> contents for example.  Rather than attempt to implement this in ncurses and try
> to stop the user from accessing the root-shell my intent is to actually have
> real users in the Skiroot environment and run each petitboot-nc instance as a
> non-privileged user.

I thought the at-least-three-beers-in pub based agreement was for Containers :D

> A basic implementation of this is pretty straightforward:
> - Create a user & group at build time that only has the ability to connect to
>   the PB_SOCKET_PATH socket.
> - The pb-discover server still runs as root but sets permissions on
>   PB_SOCKET_PATH so that the non-privileged users can connect.
> - pb-discover reads, for example, "petitboot,password" from NVRAM which is a
>   hash of the desired root password.
> - pb-discover sets this as the current root password with putspent().
> - Use agetty to spawn petitboot-nc instances running as this user.

Sounds good to me!

We probably want to preserve the existing behaviour that if no password
set, exiting to shell does get you a root shell (even though we
*explicitly* say that anything in the shell isn't ABI)

> In this way connected users can't do anything except communicate with the
> pb-discover server to boot and change options.  I have a PoC of this that works
> as expected and the patches are fairly simple, but with a few interested
> parties I thought I would send out an overview that people can
> discuss.

What about restricting changing boot option? This would prevent
downgrade attacks.

> Some open questions:
> - Is NVRAM a sufficient storage method for the time being, without going
>   full-blown TPM?

I think so. It works everywhere. We should probably specify somewhere
that other passowrd storage methods may exist in the future, and may
take priority over what's in nvram.

> - How should we restrict config-access? Get the user to enter the root password
>   when trying to save settings, or make them enter an "elevated" instance which
>   runs as a different user, or something else?

I'm thinking that it should be required to enter setup screen.

> - If "petitboot,password" isn't present do we set some default
> password?

"turn to page 323 of the POWER9 User Manual, what is the 3rd word of the
4th paragraph?" (a-la old-school game copy protection).

-- 
Stewart Smith
OPAL Architect, IBM.