[00/13] User support and client permissions
mbox series

Message ID 20181122233630.6303-1-sam@mendozajonas.com
Headers show
Series
  • User support and client permissions
Related show

Message

Samuel Mendoza-Jonas Nov. 22, 2018, 11:36 p.m. UTC
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.

Since non-root users can't init, mount, or kexec anything all normal
actions must be done via pb-discover. Unless the user authorises with
pb-discover (handled by a new nc-auth subscreen) they are restricted to
a subset of actions that don't affect the configuration or default boot
option of the system.
For platform-powerpc clients are restricted by default if we find a
"petitboot,password" value in NVRAM which is a hash of the password to
be used as the root password. Users can also set a password which will
be hashed and stored in NVRAM. In the future this could be something we
do with a TPM but as a first step this should be sufficient as NVRAM is
only accessible by root anyway.

Along the way we also pick up some fixes that make using the shell a
little nicer such as actual job control finally.
Thoughts, comments, and criticisms welcome, I'm sure I've stared at this
for too long and forgotten something. Note also that this depends on
proper user accounts being configured by Buildroot for example.

Samuel Mendoza-Jonas (13):
  utils/pb-console: Support agetty's autologin option
  utils/pb-sos: Don't create files in root by default
  utils/pb-console: Set up controlling terminal
  utils/pb-console: Ignore SIGINT
  lib/crypt: Add helpers for operating on /etc/shadow
  lib/pb-protocol: Add PB_PROTOCOL_ACTION_AUTHENTICATE
  discover/discover-server: Restrict clients based on uid
  discover/device-handler: Prevent normal users changing boot target
  discover/platform-powerpc: Read and write password hash from NVRAM
  ui/ncurses: Simplify starting shell
  ui/common: Client authentication helpers
  ui/ncurses: Add nc-auth and authenticate when required.
  ui/ncurses: Keep track of the default boot option

 configure.ac                  |  22 +++
 discover/device-handler.c     |  18 +-
 discover/device-handler.h     |   2 +-
 discover/discover-server.c    | 236 ++++++++++++++++++++++++++-
 discover/discover-server.h    |   3 +
 discover/pb-discover.c        |   3 +
 discover/platform-powerpc.c   |  29 ++++
 discover/platform.c           |  13 ++
 discover/platform.h           |   4 +
 discover/user-event.c         |   7 +-
 lib/Makefile.am               |   9 +
 lib/crypt/crypt.c             | 126 ++++++++++++++
 lib/crypt/crypt.h             |  49 ++++++
 lib/param_list/param_list.c   |   1 +
 lib/pb-protocol/pb-protocol.c |  94 +++++++++++
 lib/pb-protocol/pb-protocol.h |  26 +++
 lib/types/types.h             |   1 +
 ui/common/discover-client.c   |  81 +++++++++
 ui/common/discover-client.h   |  12 ++
 ui/ncurses/Makefile.am        |   4 +-
 ui/ncurses/nc-add-url.c       |  63 ++++---
 ui/ncurses/nc-auth.c          | 299 ++++++++++++++++++++++++++++++++++
 ui/ncurses/nc-auth.h          |  33 ++++
 ui/ncurses/nc-config.c        |  64 ++++++--
 ui/ncurses/nc-cui.c           | 204 ++++++++++++++++++++---
 ui/ncurses/nc-cui.h           |   6 +
 ui/ncurses/nc-lang.c          | 127 ++++++++++-----
 ui/ncurses/nc-plugin.c        |  44 ++---
 ui/ncurses/nc-plugin.h        |   2 -
 ui/ncurses/nc-scr.h           |   1 +
 ui/ncurses/nc-widgets.h       |   1 +
 utils/pb-console              |  18 +-
 utils/pb-sos                  |  13 +-
 33 files changed, 1479 insertions(+), 136 deletions(-)
 create mode 100644 lib/crypt/crypt.c
 create mode 100644 lib/crypt/crypt.h
 create mode 100644 ui/ncurses/nc-auth.c
 create mode 100644 ui/ncurses/nc-auth.h

Comments

Stewart Smith Nov. 23, 2018, 12:46 a.m. UTC | #1
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?
Samuel Mendoza-Jonas Nov. 26, 2018, 12:36 a.m. UTC | #2
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.
Samuel Mendoza-Jonas Nov. 27, 2018, 2:55 a.m. UTC | #3
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
Stewart Smith Nov. 27, 2018, 3:35 a.m. UTC | #4
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).