Implementing Users/Passwords in Petitboot
Samuel Mendoza-Jonas
sam at mendozajonas.com
Fri Mar 16 14:57:12 AEDT 2018
On Fri, 2018-03-16 at 14:28 +1100, Stewart Smith wrote:
> 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
Baby steps ;)
>
> > 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.
Yep as Jeremy says we'll need to do this to avoid users trivially
avoiding the restrictions.
>
> > 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).
>
"Turn to page 323 of the what?" :D
But as above, yeah we should probably revert to root access if no
password is set.
Cheers,
Sam
More information about the Petitboot
mailing list