Introduce Code (BASH Script and Notebook) to fix default login

[unprovable]

The default login credentials for the default install are all xilinx... username, password, and notebook server password.

Whilst this is probably fine for initial setup environments, when it comes to development and later production deployment, this is a potential vulnerability in the system.

Many vulnerabilities of this type typically get a CVSS score of just above 7, which makes it of HIGH priority for production risk management and cybersecurity - see NIST's Guidance for more information. Some CVE's for Default Credentials with Admin Access have much higher scores - e.g. CVE-2020-26510 with a CVSSv3.0 of over 9. The relevant CWE's for this are CWE-1392 (Default Credential) and CWE-1188 (Initialisation of a Resource with an Insecure Default).

Whilst one of the quick start guides does mention the issue, the other one does not. And the recommendation for 'just change the password' doesn't necessarily give proper guidance. As such, we wanted to help and provide an option for helping users to generate a safe and secure environment. :)

What we provide in this PR:

• A jupyter notebook that can initialise and describe the security process for users: https://github.com/QuantumVillage/qicks/blob/main/qick_demos/001_Securing_The_Box.ipynb
• A BASH script that carries out the changes to the system: https://github.com/QuantumVillage/qicks/blob/main/qick_demos/secure-ssh.sh
• A forthcoming blog post to help people understand why 'quantum devops' is important.

This PR is part of a project we are starting at Quantum Village (the official Quantum village at the DEFCON conference) to help improve the baseline security posture for quantum technologies.

Some things to note:

• The code has not been tested on an official RFSOC device! It has, however, been tested on several versions of Ubuntu Linux upon which PYNQ is based.
• The notebook has some guidance and best practices - they are based on common best practices, but could probably do with referencing the parts that you think are relevant from the OWASP Cheatsheets (or similar public documentation):
  • https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
  • https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• We have tried to keep the security stuff separate from the physics stuff for now. However, it would be prudent to add references and links to the right sections of quickstart guides and/or other READMEs.

We hope that this is useful, and are happy to answer any questions!

[meeg]

Thanks, we appreciate your attention. We agree that the default Xilinx configuration and our setup instructions do not follow best practices for production environments and that these are weaknesses that can have consequences.

Give me a few days to work out the best solution (please feel free to follow up if you haven't heard from me by the end of the week). We work with groups who have QICK installations in places with specific security requirements, and in those cases we've developed configurations that address your concerns and others. So probably we will mix-and-match between that stuff and what you've developed, to get the standard QICK setup to be secure without compromising user experience.

[unprovable]

Thank you for the response and great to hear that this is something that you are proactive about! We're happy to help if any is needed. 👍

[meeg]

Hi - we think #265 addresses this issue. We now give instructions for changing the SSH passwords and binding Jupyter to localhost, and give recommendations about why this is important. We ended up doing this in a different way from what you offered in this PR, and we don't include everything you suggested, but we think it works. Of course we're happy to continue the discussion, and will leave this PR open in the meantime.

[unprovable]

I think that we'll need to synchronize properly to explain why this isn't enough, but for now it's better than nothing :) thanks @meeg M.