- Messages
- 6,144
These standards are currently at: v0.6
MUCH MORE TO COME AT A LATER DATE
This is a project to develop a set of security standards by the Sanctuary community in an attempt to harden a chosen Linux distro against direct attacks by hostile state actors and military groups. By following these proposed security standards, the following listed goals should all be realized:
1. Resist attacks at all OS levels from bootup to shutdown.
2. Construct an OS that is both lightened as much as possible and has a greatly reduced attack surface.
3. Ensure maximum reliability of both software and hardware in use.
4. Ensure data integrity and redundancy.
5. Remain easy to deploy, manage, and use for authorized personnel.
6. Allow for multiple different use cases from server duties and sensitive data handling to operating military weapon systems.
Certain questions should probably be answered though before we proceed with this. Security standards in computing are literally as old as computers themselves, and there are already many such standards out on the internet and employed by governments around the world. Not only that, hardened Linux distros are also hardly a new concept. Most notably, Red Hat Enterprise Linux has filled the majority of this space for a very long time. So, it would be natural to ask just what the hell Sanctuary would even be accomplishing in developing these security standards.
Well, having looked at such security standards myself, I found a few key issues with them. For one, it would seem that a lot of them are rather vague in their standards. 'Have an OS that does X thing. Have the password manager employ so-and-so rule...' But what OS? What password manager? Furthermore, I feel these security standards could perhaps be greatly streamlined. There are many rules for IT security, but I feel a rule that is very often overlooked is that security that gets too much in the way of authorized users sometimes ironically results in LESS security as the users get frustrated and attempt ways themselves to bypass security restrictions in the name of better usability and convenience.
Putting aside the security standards for a moment, let's look at our selection of currently available security-hardened Linux distros. At the time of this writing, there are about four.
- Red Hat Enterprise Linux -
A seemingly very good choice, but as one looks closer, the cracks begin to show. For starters, Red Hat has been rather infamous lately for making weird and anti-consumer calls. The most notable of these is the CentOS debacle surrounding CentOS 8 and CentOS 8 Stream. For those who don't know, CentOS was the "free" version of Red Hat Enterprise Linux that anyone could use, though besides security updates, professional support from Red Hat was restricted entirely to Red Hat Enterprise Linux users only. In December of 2020, Red Hat made the announcement that they would be cuttting off security updates for CentOS 8 incredibly early and transition CentOS 8 to CentOS 8 Stream. To understand why this is a big deal, RHEL is a fixed release distro that is focused on stability and security. CentOS 8 Stream however is a distro that is a rolling release, and thus, is unsuitable for a lot of server work. Putting that aside, there are other instances in which RHEL has made short-sighted and anti-consumer decisions such as the changes in source code access in 2023, but this explanation should suffice for now.
- AlmaLinux/Rocky Linux -
These two are derivatives of RHEL and lean heavily on RHEL's resources. AlmaLinux seems to have the most solid plan to transition away from RHEL, but until that happens, these two are not suitable for reasons explained above.
- SUSE Enterprise Linux -
Seems to be a better alternative to RHEL now, but a big issue is that security updates are withheld entirely after the trial period of, if I recall correctly, 90 days until you pay for support. For a large business or government, this is nothing, but for more financially constrained parties, this simply will not do. There's also a question of security where SUSE can, at any time for any reason, deny security updates to a particular subscriber. For a Linux distro that could be used to store highly sensitive and classified data or operate military weapon systems, this is an unacceptable risk.
- Tails -
Tails is purpose-built for anonymity and privacy, and so, on the surface, would seem to be a great choice, but Tails has its own issues directly related to its purposes. For one, it is not a server OS in any way as it is made to run entirely off a USB stick and nothing more, so this alone would immediately disqualify it. Not to say though that Tails is entirely useless for our purposes here. Far from it. It could, in fact, serve in tandem to be a Linux distro for those working abroad and needing a quick and effective distro for communications and very basic work. Nevertheless, for anything more than that, Tails is just not suitable at all.
---
And so, due to all of the above, I believe it to be proper to construct new and precise security standards along with selecting a suitable distro to work off of as a base. I would also like to add, lastly, that I, personally, would like to attempt this project regardless of whether anyone at all decides to use these standards or not. The mental challenge of trying to construct such a distro fascinates me, though it probably won't for most other people here, and that's absolutely fine. But if you also have a desire to do this with me, then I greatly welcome your input and help in this endeavor.
1. Resist attacks at all OS levels from bootup to shutdown.
2. Construct an OS that is both lightened as much as possible and has a greatly reduced attack surface.
3. Ensure maximum reliability of both software and hardware in use.
4. Ensure data integrity and redundancy.
5. Remain easy to deploy, manage, and use for authorized personnel.
6. Allow for multiple different use cases from server duties and sensitive data handling to operating military weapon systems.
Certain questions should probably be answered though before we proceed with this. Security standards in computing are literally as old as computers themselves, and there are already many such standards out on the internet and employed by governments around the world. Not only that, hardened Linux distros are also hardly a new concept. Most notably, Red Hat Enterprise Linux has filled the majority of this space for a very long time. So, it would be natural to ask just what the hell Sanctuary would even be accomplishing in developing these security standards.
Well, having looked at such security standards myself, I found a few key issues with them. For one, it would seem that a lot of them are rather vague in their standards. 'Have an OS that does X thing. Have the password manager employ so-and-so rule...' But what OS? What password manager? Furthermore, I feel these security standards could perhaps be greatly streamlined. There are many rules for IT security, but I feel a rule that is very often overlooked is that security that gets too much in the way of authorized users sometimes ironically results in LESS security as the users get frustrated and attempt ways themselves to bypass security restrictions in the name of better usability and convenience.
Putting aside the security standards for a moment, let's look at our selection of currently available security-hardened Linux distros. At the time of this writing, there are about four.
- Red Hat Enterprise Linux -
A seemingly very good choice, but as one looks closer, the cracks begin to show. For starters, Red Hat has been rather infamous lately for making weird and anti-consumer calls. The most notable of these is the CentOS debacle surrounding CentOS 8 and CentOS 8 Stream. For those who don't know, CentOS was the "free" version of Red Hat Enterprise Linux that anyone could use, though besides security updates, professional support from Red Hat was restricted entirely to Red Hat Enterprise Linux users only. In December of 2020, Red Hat made the announcement that they would be cuttting off security updates for CentOS 8 incredibly early and transition CentOS 8 to CentOS 8 Stream. To understand why this is a big deal, RHEL is a fixed release distro that is focused on stability and security. CentOS 8 Stream however is a distro that is a rolling release, and thus, is unsuitable for a lot of server work. Putting that aside, there are other instances in which RHEL has made short-sighted and anti-consumer decisions such as the changes in source code access in 2023, but this explanation should suffice for now.
- AlmaLinux/Rocky Linux -
These two are derivatives of RHEL and lean heavily on RHEL's resources. AlmaLinux seems to have the most solid plan to transition away from RHEL, but until that happens, these two are not suitable for reasons explained above.
- SUSE Enterprise Linux -
Seems to be a better alternative to RHEL now, but a big issue is that security updates are withheld entirely after the trial period of, if I recall correctly, 90 days until you pay for support. For a large business or government, this is nothing, but for more financially constrained parties, this simply will not do. There's also a question of security where SUSE can, at any time for any reason, deny security updates to a particular subscriber. For a Linux distro that could be used to store highly sensitive and classified data or operate military weapon systems, this is an unacceptable risk.
- Tails -
Tails is purpose-built for anonymity and privacy, and so, on the surface, would seem to be a great choice, but Tails has its own issues directly related to its purposes. For one, it is not a server OS in any way as it is made to run entirely off a USB stick and nothing more, so this alone would immediately disqualify it. Not to say though that Tails is entirely useless for our purposes here. Far from it. It could, in fact, serve in tandem to be a Linux distro for those working abroad and needing a quick and effective distro for communications and very basic work. Nevertheless, for anything more than that, Tails is just not suitable at all.
---
And so, due to all of the above, I believe it to be proper to construct new and precise security standards along with selecting a suitable distro to work off of as a base. I would also like to add, lastly, that I, personally, would like to attempt this project regardless of whether anyone at all decides to use these standards or not. The mental challenge of trying to construct such a distro fascinates me, though it probably won't for most other people here, and that's absolutely fine. But if you also have a desire to do this with me, then I greatly welcome your input and help in this endeavor.
Before one even starts to install anything, one must keep in mind the hardware that is in use and remember the very first goal of ours, and that is to resist attacks at all OS levels. Of course, securing a machine from someone who has local access can only go so far, and disk encryption will be serving as the prime deterrent for resisting local attempts to access the system or systems. Nevertheless, due to our assumed threat model, we must strive to build as many walls and hinderances between a malicious actor and the system as we can, although we do also have to do this while keeping in mind that the system or systems also need to be as user-friendly as possible too. And so, returning back to our area of focus and to our very first security standard,
Standard 1.x - All hardware must have open-source drivers available for them.
Proprietary drivers could have certain vulnerabilities in them, intentional or otherwise, that wouldn't be able to be patched by the wider Linux community if ever found out, and the time needed for the proprietary vendor to ship out a patch would very probably also be slower, assuming that the vendor even still supports the hardware in question. Proprietary drivers are also more vulnerable to internal sabotage and do not allow any customization or self-patching of the driver if at all needed or desired. (It is said that System76 makes systems with fully open-source drivers from top to bottom. Another possibility is TUXEDO Computers.)
Standard 1.x - RAM should be ECC only and should be tested before installation.
Reliability/durability standard. A deep memory test should not be necessary. Just a basic one will do.
Standard 1.x - Hard drives must be from a reputable brand and tested with SMART before use.
Possible reputable brands are Delkin, Kioxia, and Micron. For cheaper options, Seagate Exos and old Intel drives will suffice but SMART needs to be analyzed more closely and the drives put on a trial run for one month with no sensitive data on them.
Standard 1.x - CPUs should be at least two years old or at least manufactured by AMD.
Intel CPUs have suffered major failures recently. While these problems seem to be fixed now, taking unnecessary risks is not appropriate for reliability standards, so only known good Intel CPUs should be chosen if it is decided for whatever reason that an Intel CPU is needed.
Standard 1.x - Desktop motherboards should be manufactured by ASRock.
Old ASUS boards all the way up to those made in 2020 are also acceptable but not ideal as they are no longer new.
Standard 1.x - Desktop PSUs should be from Seasonic or Super Flower.
Alternatively, you may use this list. Only PSUs in Tier A are acceptable.
Standard 1.x - All hardware should be bought anonymously and shipped to a PO box.
This better ensures that your hardware will not be tampered with before or during shipping.
Standard 1.x - Test all buttons and ports on the system.
Reliability/durability standard. If any are found to not work, request a replacement system from the vendor.
Standard 1.x - Update BIOS firmware.
Reliability/durability standard and security standard. If the system fails this for whatever reason, then request a replacement system or request a refund and look for another vendor depending on the context of the failure.
Standard 1.x - Physically secure the system in a locked cabinet or with a Kensington lock.
This may not be applicable depending on one's situation. Apply this standard accordingly.
Standard 1.x - Connect the system power to a matching uninterruptible power supply if the system is a server or desktop.
Reliability/durability standard. Make sure to do a test of the UPS once installed to ensure that it is working properly and within specs.
Standard 1.x - All hardware must have open-source drivers available for them.
Proprietary drivers could have certain vulnerabilities in them, intentional or otherwise, that wouldn't be able to be patched by the wider Linux community if ever found out, and the time needed for the proprietary vendor to ship out a patch would very probably also be slower, assuming that the vendor even still supports the hardware in question. Proprietary drivers are also more vulnerable to internal sabotage and do not allow any customization or self-patching of the driver if at all needed or desired. (It is said that System76 makes systems with fully open-source drivers from top to bottom. Another possibility is TUXEDO Computers.)
Standard 1.x - RAM should be ECC only and should be tested before installation.
Reliability/durability standard. A deep memory test should not be necessary. Just a basic one will do.
Standard 1.x - Hard drives must be from a reputable brand and tested with SMART before use.
Possible reputable brands are Delkin, Kioxia, and Micron. For cheaper options, Seagate Exos and old Intel drives will suffice but SMART needs to be analyzed more closely and the drives put on a trial run for one month with no sensitive data on them.
Standard 1.x - CPUs should be at least two years old or at least manufactured by AMD.
Intel CPUs have suffered major failures recently. While these problems seem to be fixed now, taking unnecessary risks is not appropriate for reliability standards, so only known good Intel CPUs should be chosen if it is decided for whatever reason that an Intel CPU is needed.
Standard 1.x - Desktop motherboards should be manufactured by ASRock.
Old ASUS boards all the way up to those made in 2020 are also acceptable but not ideal as they are no longer new.
Standard 1.x - Desktop PSUs should be from Seasonic or Super Flower.
Alternatively, you may use this list. Only PSUs in Tier A are acceptable.
Standard 1.x - All hardware should be bought anonymously and shipped to a PO box.
This better ensures that your hardware will not be tampered with before or during shipping.
Standard 1.x - Test all buttons and ports on the system.
Reliability/durability standard. If any are found to not work, request a replacement system from the vendor.
Standard 1.x - Update BIOS firmware.
Reliability/durability standard and security standard. If the system fails this for whatever reason, then request a replacement system or request a refund and look for another vendor depending on the context of the failure.
Standard 1.x - Physically secure the system in a locked cabinet or with a Kensington lock.
This may not be applicable depending on one's situation. Apply this standard accordingly.
Standard 1.x - Connect the system power to a matching uninterruptible power supply if the system is a server or desktop.
Reliability/durability standard. Make sure to do a test of the UPS once installed to ensure that it is working properly and within specs.
Standard 2.x - Use standard Debian Stable as the distro base.
The reasoning for this is that it must be a distribution with a fixed release and must have a sufficiently long dev time and support window for reliability and security. It must also run on as many systems as possible and must have as community support behind it as well. Due to all this, Debian Stable is a shoe-in for this category. MX Linux was also heavily considered but, in the end, dropped for security reasons as there was just too many people between up-stream and down-stream. Debian is already a huge project with many maintainers. If MX Linux is used, better reliability and tools are available, yes, but it means relying on more "links in the chain" and we are trying to eliminate as many middle-men as possible. It is a big shame though because MX has many tools that would make both distributing this project and the use of this security-hardened distro easier.
Standard 2.x - Use the XFCE LiveUSB ISO edition of Debian.
XFCE is the best combination of security, features, performance, and reliability. It is perhaps a bit more heavy than is ideal, at least in comparison to something like IceWM or Fluxbox, but that aside, it should be the best desktop environment for the job. Beyond that, this ISO has everything needed for both a minimal server install to a full desktop install.
Standard 2.x - Boot up and use Tails to download the Debian ISO and check the hashes of the downloaded ISO.
You can find the ISO here. To check the hashes of a downloaded Debian ISO, follow this guide from Debian official. Once verified, use Ventoy (preferred) or Balena Etcher to put the ISO onto a bootable medium.
The reasoning for this is that it must be a distribution with a fixed release and must have a sufficiently long dev time and support window for reliability and security. It must also run on as many systems as possible and must have as community support behind it as well. Due to all this, Debian Stable is a shoe-in for this category. MX Linux was also heavily considered but, in the end, dropped for security reasons as there was just too many people between up-stream and down-stream. Debian is already a huge project with many maintainers. If MX Linux is used, better reliability and tools are available, yes, but it means relying on more "links in the chain" and we are trying to eliminate as many middle-men as possible. It is a big shame though because MX has many tools that would make both distributing this project and the use of this security-hardened distro easier.
Standard 2.x - Use the XFCE LiveUSB ISO edition of Debian.
XFCE is the best combination of security, features, performance, and reliability. It is perhaps a bit more heavy than is ideal, at least in comparison to something like IceWM or Fluxbox, but that aside, it should be the best desktop environment for the job. Beyond that, this ISO has everything needed for both a minimal server install to a full desktop install.
Standard 2.x - Boot up and use Tails to download the Debian ISO and check the hashes of the downloaded ISO.
You can find the ISO here. To check the hashes of a downloaded Debian ISO, follow this guide from Debian official. Once verified, use Ventoy (preferred) or Balena Etcher to put the ISO onto a bootable medium.
Standard 3.x - Booting Windows (any version) or MacOS (any version) is not allowed on the machine in any capacity.
These OSes have major privacy, security, or reliability concerns.
Standard 3.x - Do not make a root account. Use sudo only for root actions.
This way, attackers will have to get through two password barriers instead of just one.
Standard 3.x - All passwords must have at least two spaces in them and have a minimum of 12 chars with at least one letter.
You may use this site to test out sample passwords. DO NOT TYPE IN REAL PASSWORDS OR PASSWORDS CONSIDERED FOR USE INTO THE SITE.
Standard 3.x - Use GPT as a partition table.
This allows for much more flexible partition formatting.
Standard 3.x - Use the ext4 filesystem as default unless another filesystem like ZFS is specifically needed.
Both a security and reliability/durability standard. Ext4, at this point, is a very well-known quantity with an awful lot of development and support behind it. Other filesystems can be more unstable and/or lacking in features and/or overly complicated for what most organizations and people need them for.
Standard 3.x - Encrypt all partitions in use on the machine.
Use the criteria for passwords set out in Standard 3.(PLACEHOLDER).
Standard 3.x - Create a separate partition for /home.
Reliability/durability standard. This way, if the system partition fails, the data in /home will not suffer any loss. This also allows for easier system management.
Standard 3.x - Only allow security updates. Disable backported software and release updates.
Once software is confirmed working, only security updates to the software should be allowed to it to prevent regressions as much as possible.
These OSes have major privacy, security, or reliability concerns.
Standard 3.x - Do not make a root account. Use sudo only for root actions.
This way, attackers will have to get through two password barriers instead of just one.
Standard 3.x - All passwords must have at least two spaces in them and have a minimum of 12 chars with at least one letter.
You may use this site to test out sample passwords. DO NOT TYPE IN REAL PASSWORDS OR PASSWORDS CONSIDERED FOR USE INTO THE SITE.
Standard 3.x - Use GPT as a partition table.
This allows for much more flexible partition formatting.
Standard 3.x - Use the ext4 filesystem as default unless another filesystem like ZFS is specifically needed.
Both a security and reliability/durability standard. Ext4, at this point, is a very well-known quantity with an awful lot of development and support behind it. Other filesystems can be more unstable and/or lacking in features and/or overly complicated for what most organizations and people need them for.
Standard 3.x - Encrypt all partitions in use on the machine.
Use the criteria for passwords set out in Standard 3.(PLACEHOLDER).
Standard 3.x - Create a separate partition for /home.
Reliability/durability standard. This way, if the system partition fails, the data in /home will not suffer any loss. This also allows for easier system management.
Standard 3.x - Only allow security updates. Disable backported software and release updates.
Once software is confirmed working, only security updates to the software should be allowed to it to prevent regressions as much as possible.
Standard 4.x - If on a desktop or laptop installation, remove the following packages specified below.
Use the command
bc coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 debian-reference-common debian-reference-es debian-reference-it exfalso fortunes-mod fortunes-debian-hints fortunes-it gimp-help-common gimp-help-sv goldendict lynx lynx-common maint-guide-it
Package list in a more readable format:
bc
coinor-libcbc3
coinor-libcgl1
coinor-libclp1
coinor-libcoinmp1v5
coinor-libcoinutils3v5
coinor-libosi1v5
debian-reference-common
debian-reference-es
debian-reference-it
exfalso
fortunes-mod
fortunes-debian-hints
fortunes-it
gimp-help-common
gimp-help-sv
goldendict
lynx
lynx-common
maint-guide-it
Use the command
sudo apt purge - <remove.txt, where remove.txt holds the names of the packages (separated by spaces) you desire be removed. This command will also remove all now unused config files associated with the removed packages as well. After that, do a apt autoremove --purge to get rid of all orphaned packages that are no longer needed plus their config files.bc coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 debian-reference-common debian-reference-es debian-reference-it exfalso fortunes-mod fortunes-debian-hints fortunes-it gimp-help-common gimp-help-sv goldendict lynx lynx-common maint-guide-it
Package list in a more readable format:
bc
coinor-libcbc3
coinor-libcgl1
coinor-libclp1
coinor-libcoinmp1v5
coinor-libcoinutils3v5
coinor-libosi1v5
debian-reference-common
debian-reference-es
debian-reference-it
exfalso
fortunes-mod
fortunes-debian-hints
fortunes-it
gimp-help-common
gimp-help-sv
goldendict
lynx
lynx-common
maint-guide-it
MUCH MORE TO COME AT A LATER DATE
Last edited:
