2
0
mirror of https://github.com/xcat2/xcat-core.git synced 2024-11-23 18:10:14 +00:00
9 Secure root support
Bin Xu edited this page 2019-03-29 15:43:40 +08:00

Design_Warning

Background

xCAT stateful provisioning (kickstart file for RHEL) and stateless provisioning (image tarball) include the root password hash inside, and they are exposed to a HTTP server. Here might be security issue.

To enforce the security consideration, it is required xCAT to offer a capability to send the root password hash in a secure method during the provisioning only.

Platform

stateful provision

In existing implementation for RHEL7, when run nodeset <cn> osimage=xxx, xCAT will generate the kickstart file and it will contains a line

rootpw --iscrypted <root password hash>

During the provisioning, anaconda will get the kickstart file and generate the corresponding root in /etc/shadow

And with the 'secure root support' enhancement, nodeset will do the following:

  • To check if Secure root is enabled (define secureroot=1 in table site), if not, same as previous.
If yes, then there are possible two option:
 1, User define `install` temporary password in `passwd` table, `nodeset` write temporary hash into kickstart file.  [**Current not support**]

2, No `install` temporary password defined, no root password hash into kickstart file.

When the node is in the end of provisioning and running xCAT default postscript, remoteshell will do the following:

  • To check if Secure root is enabled (define secureroot=1 in table site), if not, same as previous.
If yes, then it send `getcredential xcat_secure_pw:root` to xCAT master, and update the `/etc/shadow` with the right hash 

stateless provision

In existing implementation for RHEL7, when run packimage xxx, xCAT will update the <rootimagedir>/etc/shadow with the and pack it into image, so the image contains the root password hash directly.

And with the 'secure root support' enhancement, packimage will do the following:

  • To check if Secure root is enabled (define secureroot=1 in table site), if not, same as previous.
If yes, then there are possible two option:
 1, User define `install` temporary password in `passwd` table, `packimage` write temporary hash into `/etc/shadow`. [**Current not support**]

 2, No `install` temporary password defined, no root password hash into `/etc/shadow` file.

When the node is in the end of provisioning and running xCAT default postscript, remoteshell will do the following:

  • To check if Secure root is enabled (define secureroot=1 in table site), if not, same as previous.
If yes, then it send `getcredential xcat_secure_pw:root` to xCAT master, and update the `/etc/shadow` with the right hash 

Note: if you define /etc/shadow file in the synclist of the osimage, you must use packiamge --nosyncfiles xxx

getcredential is the existing API for compute node to get sensitive information form MN, it is secure enough, we just need to extend it to return the password hash per requesting.

Add a new site entry secureroot for this feature.

secureroot:  Using secure mode to transfer root password hash during the installation. (Only supports RHEL7.x)  Default is 0.

Platform

  • Support it for RHEL7 first
  • Other Platform will use the same design, but lower priority

Other Design Considerations

  • The interface to get the password hash must be secure enough

    • The client had to be verified to make sure it is from a managed compute node and with the privilege.
  • The interface must be extensible to support other user

  • To keep compatible, secure root capability is not enabled by default.

  • For some of the case, user might define shadow file into synclist. In such case, syncfiles will be run after remoteshell and override the /etc/shadow

  • As we may need to support user change password after installation for stateful, so not to change password when run updatenode.

Limitation

In secure root mode, as no root password, the console cannot be login via the real password before remoteshell executed. And just mentioned in above, a workaround is to set install temporary password for it. This password is not work during the provisioning.

Document

Out of Scope

Statelite provisioning other user password - Not support it now, just leave the API compatible.