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