| Message ID | 20181122233630.6303-1-sam@mendozajonas.com |
|---|---|
| Headers | show |
| Series | User support and client permissions | expand |
Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: > There has been interest in having methods to "lock down" Petitboot for a > while now (existing changes like restricting access to the shell, > requested features such as adding a big "Password" screen before being > able to do anything), and this makes a big jump in that direction as > part of the overall journey to trusted/secure boot. > > Rather than rely on implementing a bunch of password checks in ncurses > and keeping the user from getting shell access this instead leans on > having Linux do it for us for the most part by running all user facing > parts of Petitboot as an unprivileged user, with only pb-discover and > its utilities running with root permissions. Assuming the environment > has been set up correctly this means that when a user drops to the shell > they are completely unprivileged unless they know the root password. I'm just thinking how this would interact with op-test, we *may* not currently do the "su" thing correctly (or we might... it'd be good to check though). Maybe for some backwards-compat, if we don't have a root password, exiting to a shell should automatically "su" you to root?
On Fri, 2018-11-23 at 11:46 +1100, Stewart Smith wrote: > Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: > > There has been interest in having methods to "lock down" Petitboot for a > > while now (existing changes like restricting access to the shell, > > requested features such as adding a big "Password" screen before being > > able to do anything), and this makes a big jump in that direction as > > part of the overall journey to trusted/secure boot. > > > > Rather than rely on implementing a bunch of password checks in ncurses > > and keeping the user from getting shell access this instead leans on > > having Linux do it for us for the most part by running all user facing > > parts of Petitboot as an unprivileged user, with only pb-discover and > > its utilities running with root permissions. Assuming the environment > > has been set up correctly this means that when a user drops to the shell > > they are completely unprivileged unless they know the root password. > > I'm just thinking how this would interact with op-test, we *may* not > currently do the "su" thing correctly (or we might... it'd be good to > check though). > > Maybe for some backwards-compat, if we don't have a root password, > exiting to a shell should automatically "su" you to root? > I think op-test just uses 'sudo' which we're unlikely to have. Good idea, I'll have a look at adding a check in the drop-to-shell logic.
On Mon, 2018-11-26 at 11:36 +1100, Samuel Mendoza-Jonas wrote: > On Fri, 2018-11-23 at 11:46 +1100, Stewart Smith wrote: > > Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: > > > There has been interest in having methods to "lock down" Petitboot for a > > > while now (existing changes like restricting access to the shell, > > > requested features such as adding a big "Password" screen before being > > > able to do anything), and this makes a big jump in that direction as > > > part of the overall journey to trusted/secure boot. > > > > > > Rather than rely on implementing a bunch of password checks in ncurses > > > and keeping the user from getting shell access this instead leans on > > > having Linux do it for us for the most part by running all user facing > > > parts of Petitboot as an unprivileged user, with only pb-discover and > > > its utilities running with root permissions. Assuming the environment > > > has been set up correctly this means that when a user drops to the shell > > > they are completely unprivileged unless they know the root password. > > > > I'm just thinking how this would interact with op-test, we *may* not > > currently do the "su" thing correctly (or we might... it'd be good to > > check though). > > > > Maybe for some backwards-compat, if we don't have a root password, > > exiting to a shell should automatically "su" you to root? > > > > I think op-test just uses 'sudo' which we're unlikely to have. Good idea, > I'll have a look at adding a check in the drop-to-shell logic. > This is probably better handled in the Buildroot side of things, for example here in the .shrc as the shell starts: https://github.com/sammj/op-build/blob/users/openpower/package/petitboot/shell_config > _______________________________________________ > Petitboot mailing list > Petitboot@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/petitboot
Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: > On Mon, 2018-11-26 at 11:36 +1100, Samuel Mendoza-Jonas wrote: >> On Fri, 2018-11-23 at 11:46 +1100, Stewart Smith wrote: >> > Samuel Mendoza-Jonas <sam@mendozajonas.com> writes: >> > > There has been interest in having methods to "lock down" Petitboot for a >> > > while now (existing changes like restricting access to the shell, >> > > requested features such as adding a big "Password" screen before being >> > > able to do anything), and this makes a big jump in that direction as >> > > part of the overall journey to trusted/secure boot. >> > > >> > > Rather than rely on implementing a bunch of password checks in ncurses >> > > and keeping the user from getting shell access this instead leans on >> > > having Linux do it for us for the most part by running all user facing >> > > parts of Petitboot as an unprivileged user, with only pb-discover and >> > > its utilities running with root permissions. Assuming the environment >> > > has been set up correctly this means that when a user drops to the shell >> > > they are completely unprivileged unless they know the root password. >> > >> > I'm just thinking how this would interact with op-test, we *may* not >> > currently do the "su" thing correctly (or we might... it'd be good to >> > check though). >> > >> > Maybe for some backwards-compat, if we don't have a root password, >> > exiting to a shell should automatically "su" you to root? >> > >> >> I think op-test just uses 'sudo' which we're unlikely to have. Good idea, >> I'll have a look at adding a check in the drop-to-shell logic. >> > > This is probably better handled in the Buildroot side of things, for > example here in the .shrc as the shell starts: > https://github.com/sammj/op-build/blob/users/openpower/package/petitboot/shell_config Sure, makes enough sense (i think).