{{Header}} {{title|title= Security-Focused Operating System Comparison as Base for {{project_name_short}} }} {{#seo: |description=Comparison and Consideration of various Operating Systems as base for the {{project_name_long}} Anonymous Operating System. Design Documentation. }} {{intro| Comparison and Consideration of various Operating Systems as base for the {{project_name_short}} Anonymous Operating System. Design Documentation. }} = Introduction = This chapter applies to the host(s), {{project_name_gateway_long}} and {{project_name_workstation_long}}. ''{{project_name_short}} Example Implementation'' is currently based on Debian. Historically there have been development discussions about switching to BSD, Alpine Linux or other secure operating systems. {{project_name_short}} can't protect against malicious code inserted into upstream operating system infrastructure. Debian ensures some chain of trust as it requires contributors to sign commits. = Why not Use a Live CD/DVD as the {{project_name_workstation_short}} Operating System? = This option was previously discussed in depth and it was decided that Live CD/DVDs are not suitable for {{project_name_workstation_short}}. Advantages: * Often actively maintained. * Stabilized. * Hardened GNU/Linux distribution. * Advanced features. Disadvantages: * No timely security updates. * Limited persistence. * Inflexible design. Another serious disadvantage of Live CD/DVDs in the context of an anonymity-oriented OS is that they often have their own method of Tor enforcement included. In {{project_name_short}}, this would result in a [[Tips_on_Remaining_Anonymous#Refrain_from_"Tor_over_Tor"_Scenarios|Tor over Tor]] scenario. = Why don't you use for {{project_name_short}}? = == Generally == Why do you use Debian, and not...? General Base Operating System Requirements: * usability: acceptable usability * popularity: must be somewhat popular, because only that leads to sufficient public scrutiny and enough available documentation. * legal: For redistribution of {{project_name_short}}, there are no legal/trademark issues such as with Ubuntu, see [[#Ubuntu Legal Issues]] chapter below for details. * package manager security: Must have a secure operating system updater (package manager), i.e. must not fall through the [https://theupdateframework.io/security/ TUF Threat Model]. Not having a secure updater is [https://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix-finfisher-trojan-hole/ very dangerous]. * binary distribution: Source based distributions take a long time for upgrading and installation of packages, which users complain about. The same or even better security characteristics can be reached with deterministic (reproducible) builds. Debian is a good compromise of security and usability. The following list of distributions either fail or pass the requirements for the [[Dev/Threat Model|{{project_name_short}} threat model]]. == Ubuntu == === Ubuntu Introduction === Ubuntu is not used as {{project_name_gateway_short}}/Workstation operating system for legal reasons (see below) and was lately negatively perceived due to {{Code2|privacy issues}} [https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks] , so it is recommended against to use it as host operating system as well. {{project_name_short}} 0.4.4 and above based on Debian. Previously {{project_name_short}} was based on Ubuntu. From technical perspective, Ubuntu was a good choice, see [[Ubuntu Tips#About_Ubuntu|About Ubuntu]] if you are interested. The switch was due to Ubuntu Trademark issues, see below. {{Anchor|Switch from Ubuntu to Debian}} === Ubuntu Legal Issues === [https://ubuntu.com/legal/intellectual-property-policy About Ubuntu Trademark] and [https://www.ubuntu.com/legal Ubuntu terms] generally are complicated. Since {{project_name_short}} changes are beyond a ''remix'' (as defined by Ubuntu Licensing), {{project_name_short}} would either to have to ask for a license, which they reserve to revoke. Such a legally insecure state is not acceptable. Or {{project_name_short}} would have to rebrand Ubuntu. It would be possible in theory, but in practice it would require a lot work to remove all Ubuntu strings. [https://lists.ubuntu.com/archives/ubuntu-users/2012-September/263760.html Even new apt mirrors would be required], which is much beyond the manpower of the {{project_name_short}} project. References: * https://mjg59.dreamwidth.org/37113.html * https://www.fsf.org/news/canonical-updated-licensing-terms *
[https://www.cio.com/article/2949217/canonical-changes-licensing-terms-to-comply-with-gpl.html Later], the Linux Mint team ended up signing a deal with Canonical to use binaries for an undisclosed fee (if any).
* https://www.infoworld.com/article/2703648/will-canonical-force-linux-mint-to-license-ubuntu-binary-packages.html Debian is much more Libre without any legal issues. According to Debian project leader Stefano Zacchiroli (in private mail), there are no trademark issues as long as the derivative does not claim to be Debian. This is also clarified in [https://www.debian.org/trademark Debian trademark policy] which is easy to comply with. Derivatives of Debian are even encouraged to use Debian infrastructure, see [https://wiki.debian.org/Derivatives/Guidelines Derivatives/Guidelines]. Debian even supports derivatives. There is a lot documentation, see [https://wiki.debian.org/Derivatives Derivatives] and even a [https://lists.debian.org/debian-derivatives/ debian-derivatives mailing list]. === Mac OS X === Mac OS X can not be used for legal reasons. Even if that were not a problem, it is still a proprietary, closed source operating system, We don't like their attitude and how they (not) communicate with the security community. Also see: [https://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix-finfisher-trojan-hole/ Apple Took 3+ Years to Fix FinFisher Trojan Hole]. === Fedora === Fedora yet did '''not''' fall through {{project_name_short}} threat model and could be considered as host and future or alternative {{project_name_gateway_short}}/Workstation operating system. Also Qubes OS, an operating system focusing on security by isolation, is based on Fedora. Started considering it, help welcome, see [[Dev/Fedora]]. phone home issue (says closed but is unfixed): https://github.com/QubesOS/qubes-issues/issues/1814 https://github.com/QubesOS/qubes-issues/issues/1919#issuecomment-691545936 https://github.com/QubesOS/qubes-issues/issues/1919#issuecomment-689245921 https://arstechnica.com/information-technology/2016/12/how-to-make-linux-more-trustworthy/ https://forums.whonix.org/t/port-whonix-to-fedora-as-base-operating-system/16528 == Qubes == Implemented as [[Qubes|{{q_project_name_long}}]]. == Debian GNU/Hurd == Not ready for mainstream use, in active development. Microkernel makes device compatibility harder. == Gentoo / Hardened Gentoo == There was an effort to port Whonix to Gentoo a long time ago. * That effort has been abandoned. * Only preliminary research was done and a few contributions to [https://github.com/martinholovsky/Securix-Linux Securix-Linux] (a build script for Hardened Gentoo). * Was considered as an additional port of Whonix to Hardend Gentoo. Not necessarily leading to the deprecation of Debian based Whonix. * Historical archive of that effort can be found here: https://github.com/Whonix/Gentoo-Port/issues * Started in December 2014. * Only 2 years after Whonix had been founded. By that time, Whonix had a much smaller feature set and its base distribution (Debian), user base, focus on usability was much less enshrined at that time. In other words, Whonix was less established and more flexible at the time. * Ended in January 2015. * Something similar would most likely not be interesting anymore nowadays. Insecure package manager. Back then bug reports got closed down without much regard. * https://github.com/{{project_name_short}}/Gentoo-Port/issues/19 - https://bugs.gentoo.org/show_bug.cgi?id=539954 * https://github.com/{{project_name_short}}/Gentoo-Port/issues/10 - https://archives.gentoo.org/gentoo-portage-dev/message/94425239fcaedcee6c49ef398f12aa85 * https://phabricator.whonix.org/T212#5691 * [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers: https://archives.gentoo.org/gentoo-portage-dev/message/bda425ee6c676ec7a6b3c9500a9b00bf * [gentoo-portage-dev] Portage and Update Security: https://archives.gentoo.org/gentoo-portage-dev/message/94425239fcaedcee6c49ef398f12aa85 In this regard, Hardened Gentoo does not differ from Gentoo. Due to the way these bug reports were handled, Gentoo was removed from the candidates of secure base operating systems. In Patrick's opinion mortal users are unlikely to learn how to use them. Examples of usability issues. 
emerge firefox
* There is NOT at least 4 GiB disk space at "/var/tmp/portage/www-client/firefox-31.5.0/temp"
What to do? Increase tmpfs size as per [https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs]. == Alpine Linux == Quote https://www.alpinelinux.org/about/
Alpine Linux was designed with security in mind. All userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.
That doesn't sound super secure since other distributions do that too. Any other security features? At first sight it looks like alpine's package manager suffers from the same issues as gentoo's. (Being vulnerable to indefinite freeze and downgrade attacks.) [https://phabricator.whonix.org/T212 TODO research] The question to ask is "Does the package manager pass the TUF Threat Model?" The Update Framework (TUF) - Attacks and Weaknesses: * https://theupdateframework.io/security/ ** Made by similar people who created the research paper [https://web.archive.org/web/20220330200223/http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html attacks on package managers], which resulted as far as I understand in greatly improved package manager security in many distributions. One can ask the TUF people, who are in my experience very friendly and helpful, for their opinion on their mailing list: https://groups.google.com/g/theupdateframework == Arch Linux == [https://forums.whonix.org/t/arch-linux-distro-preview/13387 Arch Linux Distro Preview] == Devuan == Whonix is systemd based distribution. Whonix is not anti-systemd. Whonix lead developer isn't convinced of anti-systemd arguments justifying moving to a non-systemd distribution. Non-systemd is [[unsupported]] because no contributors support this use case. https://forums.whonix.org/t/why-whonix-uses-linux-with-systemd/6920 https://linuxiac.com/devuan-forgot-to-renew-the-key-that-signs-system-updates/ == NixOS == * Does not use MAC/Namespaces by default. ** (MAC: [https://search.nixos.org/packages?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=apparmor Apparmor] and Namespaces: [https://search.nixos.org/packages?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=firejail firejail] are turned OFF by default, While SElinux is [https://github.com/NixOS/rfcs/pull/41 unsupported] yet) * https://forums.whonix.org/t/nixos-distro-preview/19883 * [https://search.nixos.org/packages?channel=unstable&show=tor-browser&from=0&size=50&sort=relevance&type=packages&query=tor-browser Tor Browser packaged by NixOS] == GuixOS == MAC/Namespaces support doesnt exist in GuixOS yet. More: [https://forums.whonix.org/t/guixsd-distro-preview/11727 GuixSD Distro preview] and [[Dev/Default_Application_Policy#guix]] == Hyperbola == * https://www.hyperbola.info * https://www.hyperbola.info/news/end-of-d-bus-support/ * FSDG: yes * package manager: pacman (Arch Linux also using pacman) -> [[#Arch Linux]] package manager security? * Not reviewed yet. Would need to be added to [[#Criteria for Choosing a Base Distribution|Criteria for Choosing a Base Distribution]] for further consideration. == Voidlinux == * Their main developer left the project,they [https://itsfoss.com/void-linux-crisis/ lost access to their resources] like github, IRC, Domain..etc. (some of them regained access to only) * Another sad loss of the project was the passing away of [https://voidlinux.org/news/2021/03/In-memoriam-pullmoll.html Jürgen Buchmüller (pullmoll)], one of their main maintainers. * After almost 6 years they [https://voidlinux.org/news/2021/02/OpenSSL.html switched back] from libressl to openssl * They do not sandbox their packages with MAC/Namespaces by default. Only xbps-src which is the package builder but not for sandboxing packages within their distro. == SubgraphOS == There are several reasons why {{project_name_short}} has decided not to use the [https://subgraph.com/ Subgraph project] platform. '''Table:''' ''{{project_name_short}} Rationale'' {| class="wikitable" |- ! scope="col"| '''Domain''' ! scope="col"| '''Reasoning''' |- ! scope="row"| Development | * Future Roadmap: Basing {{project_name_short}} on Subgraph would tie our future to the viability of another project. It is not ideal to rely on an OS in alpha status, particularly when the Debian alternative is rock solid and has decades of development behind it. * Features: Subgraph has some [[Comparison_with_Others/SubgraphOS|undesirable feature additions]] that add no value. {{project_name_short}} cannot benefit from Subgraph's manpower if the goals for the development roadmap are fundamentally different. * Bugs: The plentiful [https://github.com/subgraph/subgraph-os-issues/issues Subgraph bugs] would become {{project_name_short}} bugs and developers would depend on them for fixes. * Programming Language: Subgraph choose different programming languages (like Golang) that are unfamiliar to lead {{project_name_short}} developers, making customization or modification very difficult. * Desktop Environment: {{project_name_short}} Developer HulaHoop has noted that Subgraph features completely rely on the GNOME desktop environment. This is undesirable because it is visually unappealing, has an over-simplified interface and would require any "cloud integration" elements to be removed. Configuring GNOME to approach the specifications already achieved in {{project_name_short}} would require a lot of effort. |- ! scope="row"| Source Code / Software | * Code Availability: No full source code release to date (mid-2019). https://github.com/subgraph/subgraph-os-issues/issues/153 https://github.com/subgraph/subgraph-os-issues/issues/250 * Packaging: The publicly available software exists in a form that is not easily packaged. This would pose a significant maintenance burden for the {{project_name_short}} team. * Constraints: Arbitrary limitations are in place, such as repository choices. This can of course be changed, but it is an example of wasted effort in patching the base OS to adapt to our vision. * Meta-packages: There is no Subgraph meta package that can be installed using [https://github.com/subgraph/subgraph-os-issues/issues/239 "sudo apt install subgraph-os" / "debootstrap Subgraph OS"] in order to convert vanilla Debian into Subgraph OS. Subgraph is a Debian derivative. (Similar to {{kicksecure_wiki |wikipage=chroot |text=Install {{kicksecure}} inside a folder (chroot) }} or [[Dev/Installation_from_Repository|{{project_name_short}} Installation from {{project_name_short}} APT Repository]].) |- ! scope="row"| Collaboration | To date, there has been no cooperation from the Subgraph project developers to correct any of the issues outlined in this section. |- |} {{Anchor|Why aren't you using OpenBSD, it is the most secure OS ever!!!1!}} == OpenBSD == This FAQ entry addresses the suggestion that {{project_name_short}} should be based on OpenBSD rather than Debian. The opinion provided below is based on the perspective of {{project_name_short}} developers. Last updated in 2019. The OpenBSD FAQ states: [https://www.openbsd.org/faq/faq1.html#WhyUse source]
OpenBSD is thought of by many security professionals as the most secure UNIX-like operating system, as the result of a never-ending comprehensive source code security audit.
The landing page for OpenBSD also notes: https://www.openbsd.org/
Only two remote holes in the default install, in a heck of a long time!
To OpenBSD's credit, they have a solid reputation for taking security seriously. For example, the development team has adopted these principles: https://www.openbsd.org/security.html * A strong focus on cryptographic approaches towards fixing security problems. * Full disclosure of security bugs and speedy fixes. * An auditing team of 6-12 members (including ex-corporate security researchers) continuously searches for and fixes security holes; a process underway since 1996. This has resulted in the discovery of entire new classes of security problems. * Development of new technologies, such as additional memory protections. * Shipping the OS in a "Secure by Default" mode with all non-essential services disabled. * Contributing to research -- a number of security papers have been written by OpenBSD team members. Despite these strengths, the primary downside to adopting OpenBSD relates to the estimated size of the user base: * [https://www.bsdstats.org/ bsdstats.org], suggests OpenBSD has few users. While bsdstats is not representative of the total population of OpenBSD users due to the opt-in data collection program, 9 systems at the time of writing is a very small figure. By comparison, TrueOS has over 15,000 users in 2019. * Although unscientific, [https://distrowatch.com/dwres.php?resource=popularity DistroWatch] also shows OpenBSD attracts far less interest than popular Linux distributions. * OpenBSD is estimated to have less than 10 percent of total BSD market share. https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#Popularity * Estimates of BSD market share across all categories (desktops, servers etc.) is [https://en.wikipedia.org/wiki/Usage_share_of_operating_systems tiny]. One valid concern is that if a critical mass of users does not gravitate to OpenBSD, then naturally less human resources ("eyeballs") in the population will be searching for, identifying, and remedying security flaws. While the audit team is skilled, a relatively small number of people must inspect code across an entire operating system. As a result, this could ''potentially'' aid targeted attacks or other exploits. One example previously cited is this years old bug which remains unfixed: [https://web.archive.org/web/20170324012358/http://thread.gmane.org/gmane.os.openbsd.bugs/18754 security vulnerability - NTP not authenticated]. Possibly limited human resources has impacted this bug which affects everyone using the distribution. This bug would also impact {{project_name_short}} -- the suggested solution was to authenticate the connection to the NTP server, but this would not be possible for several reasons: * The {{project_name_short}} design focuses on distributing trust and not using only one NTP server. * Further, {{project_name_short}} depends on free services which are available to anyone, ruling out a solution that requires a personal server. * Even if {{project_name_short}} used authenticated NTP, it has been [https://archive.ph/FobRy pointed out] that the clock could not be moved more than 600 seconds. This is better than nothing, but still inadequate for adversaries who are capable of moving the clock more than 600 seconds, harming anonymity/privacy in the process (see [[Dev/TimeSync]] for further details). In comparison, alternatives like Debian have a large user/contributor base, a similar [https://www.debian.org/security/ focus on security], renowned stability, and a solid reputation in security-critical environments such as web servers. In fact, Debian's popularity and large contributor base has resulted in its adoption in around [https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Market_share_by_category one-third of all Linux web servers] and led to an expansive software library of over 50,000 packages. It is also strongly contested that BSD variants have [https://www.openbsd.org/innovations.html innovative security improvements] that provide greater protection than modern platforms like Qubes OS; see [[Qubes/Why_use_Qubes_over_other_Virtualizers#Security|Qubes Security]]. * https://isopenbsdsecu.re/ * https://isopenbsdsecu.re/mitigations/ * https://isopenbsdsecu.re/quotes/ == openSUSE == * https://forums.whonix.org/t/port-to-opensuse/17400 * https://forums.whonix.org/t/opensuse-tumbleweed-distro-preview/20561 * https://github.com/Kicksecure/security-misc/issues/138 * {{kicksecure_wiki |wikipage=Dev/openSUSE |text=Dev/openSUSE }} == FreeBSD == This FAQ entry addresses the suggestion that {{project_name_short}} should be based on FreeBSD rather than Debian. The opinion provided below is based on the perspective of {{project_name_short}} developers. Last updated in January 2018. It is difficult and time consuming to try and list all the disadvantages of using FreeBSD, such as highlighting non-existent security features. The onus is on FreeBSD proponents to manually search for relevant features (or lack thereof) and present an objective case for its adoption. To avoid presenting information that will quickly become out-of-date or that may insult FreeBSD adherents, it is better to avoid definitive security statements and instead ask appropriate questions which might affect the usability, security, anonymity and wide-scale adoption of {{project_name_short}}. For instance: * Does FreeBSD have a secure-by-default update mechanism? * By default, will every (new) user download come from an existing ''signed'' repository? ** If not, what special settings are required? ** Are users expected to run their own repository? * Does FreeBSD defend against outdated metadata; for example, can a man-in-the-middle use a roll back or freeze attack against the repository? * Does FreeBSD defend against [https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html various attacks on package managers?] * Does FreeBSD defend against attacks on the software update process by using the [https://theupdateframework.io/security/ TUF threat model]? Research which might provide a strong case for FreeBSD does not exclude the possibility of weaknesses or missing security features. The best way to determine the strength of the platform and its relative resilience is to directly ask the developers of that project. Honest replies can reasonably be expected from vibrant, open source communities.The only problem is, the Linux/BSD ecosystems have hundreds of distributions and it is a daunting prospect to rank their merits in this way. Ultimately, the burden of proof falls on FreeBSD advocates (and not {{project_name_short}} developers) to prove that it is the most secure distribution available. Properly researched contributions that answer the questions above would be a good start, along with possibly approaching FreeBSD developers directly. Alternatively, research into why various aforementioned protections are not necessary to improve security would also be welcomed. Until claims about FreeBSD are substantiated, one should not take offense that it has not already been adopted. To check for FreeBSD security features see: https://wiki.freebsd.org/CategorySecurity == OpenWRT == [https://openwrt.org/ OpenWRT] is not used for the same reasons outlined above. Further, in early 2018 OpenWRT [https://openwrt.org/packages/start did not have signed packages]. == Tails == === How is {{project_name_short}} Different from Tails? === See [[Comparison with Others]]. === Why not Merge with Tails and Collaborate? === The following is a ''subjective'' opinion by lead {{project_name_short}} developer Patrick Schleizer. Last updated in September 2018. Feedback, corrections and suggested improvements are welcome. [https://tails.boum.org/ Tails] is a respected project with similar goals to {{project_name_short}} - improved anonymity, privacy and security. Tails has existed for many years and has multiple developers, significant experience and a complete working infrastructure. {{project_name_short}} and Tails developers already cooperate to some degree and discuss things of mutual interest to both projects on various developers mailing lists like whonix-devel, tails-devel and secure-os. === {{project_name_short}} and Tails Collaboration === Several parts of {{project_name_short}} are based on Tails. For example, the development of [[sdwdate]] in {{project_name_short}} was reliant upon Tail's invention of tails_htp. {{project_name_short}} also profits from Tails' previous efforts to upstream packaging and other changes in Debian, current and historical discussions in various forums, Tails research, design documents, experience, feedback and so on. Other examples of Tails and {{project_name_short}} cooperation include: * [[Dev/onion-grater#onion-grater_by_Tails|onion-grater]] - a whitelisting filter for dangerous Tor control protocol commands - was developed by Tails developer {{Code2|anonym}} with {{project_name_short}} in mind. {{project_name_short}} then [[Dev/onion-grater#onion-grater_by_Tails_forked_by_{{project_name_short}}|forked the Python code]] to add a few necessary improvements. https://github.com/{{project_name_short}}/onion-grater * Tails has expressed interest in using [[Anon Connection Wizard]] in the future. === Why {{project_name_short}} is a Separate Project === Even though Tails is highly valued by {{project_name_short}} developers, it may not be clear to the reader why {{project_name_short}} remains a separate project and not just a contributor to Tails. There are several reasons for this decision: {{project_name_short}} cannot be merged into Tails by the {{project_name_short}} team on technical, skill and political grounds; implementing features or changes in Tails is an unfamiliar process; and it is unknown when/if {{project_name_short}} priorities will be implemented in Tails -- but it is known how to solve these in a separate project (at least with appropriate user documentation). Further examples are outlined in the table below. Note that some of these items are partially or nearly solved in Tails, but it is has been kept to justify the prior decision not to merge projects. '''Table:''' ''{{project_name_short}} and Tails Design and Functionality Comparison'' {| class="wikitable" ! align="left" | Tails Issue Tracker (TODO) ! align="left" | {{project_name_short}} Design / Instructions |- class="odd" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5551 Remember installed packages] | align="left" | By design, everything persists This is actually a disadvantage for anonymity because it is the opposite of an amnesic system, which many users prefer. |- class="even" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5769 Applications Audit] | align="left" | By design, protocol leaks cannot lead to deanonymization |- class="odd" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5748 Two-layered, virtualized system] | align="left" | By design, this is achieved by either software compartmentalization (VMs) or [[Dev/Build_Documentation/Physical_Isolation|Physical Isolation]] |- class="even" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5858 VPN support] | align="left" | [[Features#Tunnel_Support|VPN / Tunnel support]] |- class="odd" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/6078 Freenet] over Tor | align="left" | [[Freenet]] |- class="odd" | align="left" | [https://tails.boum.org/doc/anonymous_internet/tor/index.en.html obfsproxy] Bridges were not natively supported by Tails when {{project_name_short}} was founded. | align="left" | [[Bridges]] |- class="even" | align="left" | [https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html#fingerprint Can I hide the fact that I am using Tails?] | align="left" | [[Hide Tor from your Internet Service Provider|Hide Tor and {{project_name_short}} from your ISP]] |- class="odd" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/12264 I2P over Tor] The I2P feature was [https://tails.boum.org/news/version_2.11/ removed in Tails 2.11] due to the developer effort required. | align="left" | [[I2P]] |- class="even" | align="left" | [https://tails.boum.org/contribute/design/Tor_enforcement/ Transparent Proxy as a fallback mechanism] | align="left" | By design, everything not configured to use a SocksPort will automatically use Tor's TransPort |- class="odd" | align="left" | [https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html Use Tor Browser] | align="left" | [[Tor Browser]] |- class="odd" | align="left" | [https://tails.boum.org/contribute/design/stream_isolation/ Stream Isolation] Tails has basic stream isolation functionality compared to {{project_name_short}}. | align="left" | [[Stream Isolation]] |- class="even" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5362 Evaluate web fingerprint] See also: https://tails.boum.org/contribute/design/#index19h2 The bundling of uncommon extensions in Tor Browser like ''uBlock Origin'' increase the likelihood of fingerprinting Tails users specifically. | align="left" | Same as Tor Browser |- class="odd" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5412 Unsafe browser fingerprint] | align="left" | [[Logging in to captive portals]] |- class="even" | align="left" | [https://gitlab.tails.boum.org/tails/blueprints/-/wikis/tails_server/ Location Hidden/IP Hidden Servers] | align="left" | [[Hosting Location Hidden Services|Location/IP Hidden Servers]] |- class="odd" | align="left" | [https://gitlab.tails.boum.org/tails/tails/-/issues/5709 VoIP] | align="left" | [[VoIP|VoIP]] |- class="even" | align="left" | ... | align="left" | ... |} === Political and Design Considerations === There are also significant differences in political and design decisions which prohibit a merger: * As a code contributor to Tails, Patrick Schleizer would need to accept decisions made via internal Tails decision-making processes. {{project_name_short}} would lose the autonomy to simply modify anything in line with personal preferences or favored solutions. One major advantage of free software is developers are free to disagree about a project's direction, leading to the creation of a fork. At the time {{project_name_short}} was created, Schleizer did not favor a Live DVD/USB approach and personally found improving Tails to be far more difficult than starting a fresh project. * Source Code Merge Policy: ** Whonix: A comprehensive merge policy has not yet been developed. This would be ideal, but it is not compulsory to formulate such a design or associated documentation. ** Tails: In Schleizer's opinion, the [https://tails.boum.org/contribute/merge_policy/ Tails merge policy] is too strict. This is not a complaint or critique. No doubt there are good reasons for that decision and it should be noted that Tails is still a popular and effective solution for many users. Anyone who does not agree has the freedom to contribute to another project or to start a new project, leading Schleizer to make use of that freedom. * Another major design difference is Tails' reliance on a Live DVD/USB which inherits some restrictions and limitations. Tails must fit on a DVD/USB, while {{project_name_short}} does not have this requirement. {{project_name_short}} also has higher hardware requirements, but therefore more space to implement features. As a consequence, initially fewer people are able to use {{project_name_short}}, but this situation will improve in the future as available hardware improves. The {{project_name_short}} design is fluid and new designs (both theoretical and practical) are being discovered over time. Depending on user feedback and general interest, eventually a Live DVD or Blu-ray might be created in {{project_name_short}}. * Schleizer has found it easier to cooperate with the security by isolation focused operating system [https://www.qubes-os.org Qubes OS], which resulted in [[Qubes|{{q_project_name_short}}]]. = Minimal Distribution Disadvantages = The primary reason for the large size of the images is that small/er distributions do not meet {{project_name_short}} requirements; namely the upstream distribution must have a proactive security policy. In addition: * Most minimal distributions are small projects. Consequently, there is no dedicated security team that audits packages and quickly releases security patches. * {{project_name_short}} requires a distribution that cryptographically signs all updates. This is always desirable, particularly when updating over untrusted exit relays. * The security of minimal distributions is premised on reducing the potential attack surface and not much else. {{project_name_short}} also has a small attack surface, due to only installing a few select applications and not having any network listening services by default. However, on the upside a full distribution supports MAC, kernel patches, IDS and much more. * Large, established projects have many users and developers - the many eyeballs on the code implies greater trustworthiness. * Debian has a significant number of [https://wiki.debian.org/Security/Features security features] that are unavailable in smaller distributions. * For further reading on this topic, see [[Dev/Operating_System|Operating System]]. = Maintenance and Usability Concerns = Since {{project_name_short}} is based on Debian, it is a complete, anonymity-oriented, general purpose operating system. This greatly improves [[Design|usability]] in comparison to minimal systems which lack a host of [[Features|features]]. There are several other benefits of relying on Debian, rather than a minimal distribution: * A wider range of use cases is supported, such as hosting onion services. In contrast, small distributions usually have limited repositories. * Debian has comprehensive documentation about topics like security and hardening, unlike many small distributions. * Creating a slim system increases the maintenance burden, because it is difficult and requires significant development time. This is not and should not be the primary focus of the {{project_name_short}} team. * Minimal projects do not usually focus on anonymity, privacy and security-related matters; the core competence of the {{project_name_short}} project. * Attempts to slim down systems inevitably results in numerous "strange bugs". Users who are familiar with Debian or Ubuntu would then question why {{project_name_short}} is broken or lacks full functionality. It should be noted that by increasing usability, {{project_name_short}} actually improves security over time. This stems from a larger user pool, a more prominent profile in the press, increased development activity and additional security audits and research. On the contrary, a slimmed down system would only attract specialists or experts. This does not mean {{project_name_short}} cannot be significantly hardened, customized or reduced in size by those with specialist knowledge. An interesting analogy is [https://www.mixminion.net/ Mixminion], which was once touted as an alternative to Tor. Consider this interesting statement from Tor developer Roger Dingledine: [https://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00022.html Mixminion vs Tor]. Due to Mixminion being a high latency remailer, with cover traffic and protection against traffic confirmation (end-to-end correlation attacks), it should ''theoretically'' have been more secure than Tor. The only problem was that Mixminion did not attract a critical mass of users. Without a sizable population to help disguise traffic, the putative anonymity benefits were seriously degraded - making it no more or less (in)secure than Tor. This is also the reason development was discontinued. = Why don't you do what does? = Whonix is based on Kicksecure, which is a security-focussed operating system. For example, initramfs-tools gets broken by libpam-tmpdir and /tmp mounted with noexec. Bugs have been reported to upstream distributions Debian, Ubuntu. * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062756 Debian: initramfs-tools broken by libpam-tmpdir and /tmp mounted with noexec] * [https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2053153/ Ubuntu: initramfs-tools broken by libpam-tmpdir and /tmp mounted with noexec] Upstream distributions did not notice this because upstream, * is not (considering to) installing libpam-tmpdir by default, * is not (considering to) mounting /tmp with noexec by default. Upstream presumably therefore did not notice this bug. These upstream bug reports did not receive any upstream replies and no action taken upstream either. Potential reasons for this could be because upstream has no resources to look into that, has different priorities or is not interested in that. Another example, security issue [https://trojansource.codes Trojan Source - Invisible Source Code Vulnerabilities] ({{kicksecure_wiki |wikipage=Unicode |text=Invisible Malicious Unicode Risks }}) has been reported to Debian: * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014029 invisible malicious unicode in source code - detection and prevention] * Was automatically mirrored to the debian-development mailing list [https://lists.debian.org/debian-devel/2022/06/msg00178.html Bug#1014029: invisible malicious unicode in source code - detection and prevention]. The only action taken by Debian was closing the bug and locking further discussion. Debian: * trusts RDRAND by default but really should not. Details here: [[Dev/Entropy#RDRAND|RDRAND]] * No action was taken on Debian feature request [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927972 set jitterentropy_rng.ko to built-in]. See also [[Dev/Entropy#jitterentropy|jitterentropy]]. Therefore what another distribution does or not does is by itself not an argument. = Rolling Distribution = Regular upgrades on a rolling distribution help prevent attacks by fixing known vulnerabilities, but they also increase the risk of introducing less vetted packages, which might include malicious backdoors, such as the xz backdoor incident. This creates a trade-off between maintaining up-to-date security and ensuring system integrity. {{quotation |quote=However, as security researcher Sharp Security highlighted in a blog post, the team fixed a notable flaw without adequately informing the users about it and without assigning a CVE to the problem. |context=https://www.bleepingcomputer.com/news/security/qbittorrent-fixes-flaw-exposing-users-to-mitm-attacks-for-14-years/ }} = Debian = == General == {{project_name_short}} is based on Debian. Reasons for being based on Debian: * stable distribution * exists for years * will likely still be around in 10 years * attempts to sow dissent failed Debian is Free. Imagine how much money that must cost proprietary competiors from whom not all of them necessarily play by the law. * massive architecture support Not just i386, amd64 and perhaps arm. Should any platform become "evil", Debian as the universal operating system offers options and is most likely to port to new platforms. * secure package manager * As per {{Code2|[https://www.trapkit.de/tools/checksec/ checksec.sh] --kernel}}, reports good kernel protection: GCC stack protector support, enforce read-only kernel data, restrict /dev/mem and /dev/kmem access are all enabled. * https://snapshot.debian.org/, hosted and signed by a trusted third party (Debian) From perspective of {{project_name_short}}., allows implementation of robust build scripts Build script won't break due to upstream repository changes. and [[Verifiable_Builds|Verifiable Builds]] * [https://packages.debian.org/{{Stable project version based on Debian codename}}/config-package-dev config-package-dev] allows creation of robust configuration packages * [https://packages.debian.org/{{Stable project version based on Debian codename}}/grml-debootstrap grml-debootstrap] is a tool that allows creation of bootable raw images * Debian is working on [https://wiki.debian.org/ReproducibleBuilds ReproducibleBuilds] * huge knowledgeable community of Debian and their derivative users (stackexchange, debian forums, askubuntu and many more) * Debian Developers are very approachable at conferences * Tor has ties to Debian. * [[#Switch_from_Ubuntu_to_Debian|No legal/trademark issues.]] General explanation, why so many distributions are based on Debian: * [https://upsilon.cc/~zack/blog/posts/2011/09/why_there_are_so_many_debian_derivatives/ why there are so many debian derivatives] Also interesting: * [https://lists.debian.org/debian-security/2013/10/msg00065.html Debian APT Key Revocation Procedure] * [https://lists.debian.org/debian-security/2013/11/msg00019.html How (un)safe would Debian be when only using the security.debian.org repository?] Related: * [https://wiki.debian.org/Derivatives/Census/{{project_name_short}} Derivatives Census {{project_name_short}}] * {{kicksecure_wiki |wikipage=Dev/Relationship_With_Upstream |text=Dev/Relationship With Upstream }} See also: * {{kicksecure_wiki |wikipage=Dev/Debian |text=Dev/Debian }} {{Anchor|Why is {{project_name_short}} 8 based on Debian Stable, not Debian Testing?}} == Debian Security == Debian isn't (a | the most) security-focused Linux distribution. Under some threat models, Debian is judged insecure. Issues with Debian then would have to be considered deeper than technical, i.e. architectural, organizational, ideological issues. To put it another way (a lot | many | most) (?) Debian Developers don't prioritize security over everything else readily compromising other things such as package availability, features, usability, etc. That shouldn't come to a surprise. Debian slogan is "the universal operating system". Not "attempting to be the most secure operating system" and therefore Debian didn't attract that mindset. Debian consists of mostly volunteers that need to attend to day jobs which might arguably not be the best for security either. === Debian Signed Packages === prerequisite knowledge: * https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/ * http://unix.stackexchange.com/questions/285635/how-is-the-authenticity-of-debian-packages-guaranteed summary: * Debian build servers signs repository metadata. * Debian maintainers must sign their source packages. Otherwise uploads are automatically rejected. * Individual .deb packages are not signed by Debian maintainers. tools: * debsign: Signs the .changes before upload. Does not sign packages. Always used in Debian. * debsig: embeds signatures into .deb packages. Not commonly used. * dpkg-sig: embeds signatures into .deb packages. Not commonly used. [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 steps toward making dpkg-sig sign all packages] There was once a bounty [https://web.archive.org/web/20201214130930/https://github.com/Whonix/Whonix/issues/400 Build Debian Packages from Source Code] worth $ 3000 USD but no implementation was ever contributed. forum discussion:
https://forums.whonix.org/t/end-to-end-signed-debs-debsign-debsig-and-dpkg-sig/3446 == Why is {{project_name_short}} based on Debian Stable, not Debian Testing? == A long time ago, {{project_name_short}} was based on Debian Testing. Due to many issues documented below, for many releases already, {{project_name_short}} is based on Debian Stable. * Connectivity breaking bugs: Sometimes severe bugs are introduced in Debian testing, such as the AppArmor [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732578 bug], which prevented Tor from starting for everyone until a workaround was applied. * Build process breaking bugs: Sometimes bugs are introduced which break derivative-maker (build script), such as [https://web.archive.org/web/20220322233757/https://ml.grml.org/pipermail/grml/2014-January/011546.html this] bug related to mount, which breaks grml-debootstrap and therefore derivative-maker or [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734794 this] kpartx bug. * Boot breaking bugs: Often other disturbing bugs are introduced, such as the grub bug (not able to reproduce and report upstream yet). * VirtulaBox Guest Additions breaking bugs: Non-functional [[VirtualBox/Guest_Additions|VirtualBox Guest Additions]] or [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728399 issues] with shared folders. * Higher upgrade time effort: Too often, too many packages are upgraded (not just security fixes) (costs lots of time to keep up, bandwidth, system load). ** Lack of security support: Quote, [https://www.debian.org/security/faq.html#testing Debian Security FAQ]:
If you want to have a secure (and stable) server you are strongly encouraged to stay with stable.
** Debian stable receives security fixes faster than Debian testing. For example, by 12/15/2016 Debian jessie was Debian stable and Debian stretch was Debian testing. [https://lists.debian.org/debian-security-announce/2016/msg00316.html CVE-2016-1252] was fixed in Debian stable but not in Debian testing, see Debian security tracker by 12/15/2016. * Permanent package removal: Sometimes packages get entirely removed from Debian testing, such as enigmail wasn't available for a while in Debian testing. ** Support request overhead: This is confusing and constantly creating support requests. * (Temporary) package removal: Sometimes packages are (temporarily) removed from Debian testing. ** For example torsocks has been removed from Debian bookworm. *** https://bugs.debian.org/1066313 *** https://web.archive.org/web/20240518161618/https://release.debian.org/britney/update_excuses.html#torsocks *** https://web.archive.org/web/20240520135347/https://qa.debian.org/excuses.php?package=torsocks
torsocks (- to 2.4.0-1)
Migration status for torsocks (- to 2.4.0-1): BLOCKED: Rejected/violates migration policy/introduces a regression
Issues preventing migration:
Updating torsocks would introduce bugs in testing: [https://web.archive.org/web/20240520135343/https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066313 #1066313]
*** Quote https://web.archive.org/web/20240520134953/https://tracker.debian.org/pkg/torsocks
The package has not entered testing even though the delay is overnormal
The package has not entered testing even though the 5-day delay is over. Check why.
*** Such package removal would break the {{project_name_short}} build process due to the missing dependency. ({{project_name_short}} package uwt (implements stream isolation) Depends: on torsocks:.) *** System upgrade breaking bugs: Such package removal can break system [[update]]s (apt-get dist-upgrade) due to missing dependencies. (Kicksecure or Whonix packages are often depending on such packages.) https://lists.debian.org/debian-devel/2024/03/msg00299.html https://release.debian.org/doc/britney/short-intro-to-migrations.html == Debian Rolling == Does not exist. https://lists.debian.org/debian-devel/2011/05/msg00111.html == Popularity Contest == The Debian ''popularity-contest'' (popcon) package does not get installed on {{project_name_short}}. Installing it gets prevented by the [https://github.com/{{project_name_short}}/anon-meta-packages/blob/master/debian/control#L324 anon-banned-packages] package. [https://popcon.debian.org/README popcon readme] | [https://popcon.debian.org/FAQ popcon faq] | [https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=popularity-contest popcon bugs] | [https://lists.alioth.debian.org/cgi-bin/mailman/listinfo/popcon-developers popularity contest mailing list] | [https://lists.alioth.debian.org/pipermail/popcon-developers/2012-October/002172.html popularity contest mailing list: Drop atime and ctime for privacy reasons possible?] Some privacy considerations and reasons why it is not installed: * The connection would obviously need to go over its own Tor circuit (stream isolation). At the moment popcon tries to go through http and if it fails (no internet connectivity) it goes into the mail queue. (sendmail) Sendmail probably works though TransPort, but we don't know if it can be torified for proper stream isolation. * (From the popcon readme) "''Each popularity-contest host is identified by a random 128bit uuid (MY_HOSTID in /etc/popularity-contest.conf).''" - This would allow to enumerate a quite good guess about the amount number of {{project_name_short}} users. We are not sure if sourceforge could already have an insight about that (due to {{project_name_short}} News File downloads, see whonixcheck) or about any other negative implications. * MY_HOSTID would probably get created at {{project_name_short}} build time and all {{project_name_short}} users would have the same MY_HOSTID, which would make it useless. A new MY_HOSTID would have to be created at first boot of {{project_name_short}}. * Popcon runs at a random day. Good. * If the machine is powered on: it runs at 6:47, which is bad, because a local adversary (ISP or hotspot) could guess popcon runs over Tor which would likely be a {{project_name_short}} user. * If the machine is powered off at 6:47, it sends the report later, only if anachron is installed. It shouldn't run instantly after powering on, also for fingerprinting reasons. The time would have to be truly randomized. * The transmission is not encrypted, see [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480860 popularity-contest should encrypt contents] and it is not planned to encrypt it. Malicious Tor exit relays could modify the transmission, but this is only a minor issue. Such malicious Tor exit relays could send fake transmissions on their own. * It is questionable if and if yes, how long Debian will accept popularity contest transmissions from Tor exit relays. There is potential for electoral fraud. For these reasons it is not a good idea to add popcon to {{project_name_short}}. If you have suggestions or a different view, please get in contact. = Criteria for Choosing a Base Distribution = == Community Project versus Corporate Project == todo: research Under consideration. {{quotation |quote=Base distribution must be a community project. Not a corporate project. }} Corporations can quickly act against the interest of the Freedom Software community. Some examples of such are collected here. * [[Dev/Operating_System#Ubuntu_Legal_Issues|Ubuntu Legal Issues]] * https://www.reddit.com/r/openSUSE/comments/14571ig/is_anyone_else_concerned_about_the_future_of/ * https://techcrunch.com/2023/08/18/suse-goes-private-again/ * {{kicksecure_wiki |wikipage=Dev/openSUSE#Community_Project_versus_Corporate_Project |text=Community Project versus Corporate Project }} * RedHat ** https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes * RedHat versus CentOS ** https://www.phoronix.com/news/Red-Hat-CentOS-Stream-Sources ** https://itwire.com/business-it-news/open-source/red-hat-kills-off-centos,-users-frustrated-and-angry.html * RedHat versus Rocky Linux ** https://rockylinux.org/news/2023-06-22-press-release * Novell made a patent deal with Microsoft to outflank RedHat. {{quotation |quote= Novell basically conceded that its implementation of Linux violated Microsoft patents and agreed its customers needed patent-enforcement protection. |context=https://www.zdnet.com/article/microsoft-and-novell-at-two-was-the-patent-pact-worth-it/ }} * https://en.wikipedia.org/wiki/Stephen_Elop - keywords: Microsoft, Nokia, bankrupt * [https://www.zdnet.com/article/when-microsoft-met-suse-this-windows-linux-partnership-gets-stronger-every-day/ When Microsoft met SUSE: This Windows-Linux partnership gets stronger every day] * A Linux distribution company reliant on funding from Microsoft may see its decision-making and resources steered toward projects that benefit Microsoft and its cloud ecosystem. This redirection can detract from supporting and bankrolling independent, open-source initiatives that might otherwise strengthen the broader FLOSS (Free/Libre and Open Source Software) ecosystem. ** https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish == Previously Compared but Removed == * Devuan: Not useful to compare if the only difference is a different init system. == Missing Criteria == The following criteria are not yet part of the following comparison table but should be added. * check all dependencies are up-to-date versus multiple dependencies versions * This is is non-exhaustive. What else? Not applicable, valid, clear or related or suffers from a lack of information in general to be covered in the table yet: * The user's package manager verifies the package maintainer's and upstream developer's digital signature. * End-to-end signed packages * Untrusted packages (similar to Debian proposal [https://wiki.debian.org/UntrustedDebs UntrustedDebs]) == Previous Criteria == * [[Vanguards]] available: dropped because unmaintained upstream * Onionbalance available: dropped because not too important, if needed can be manually installed == Minimum Criteria == Since most distributions have it, this is considered a minimum criteria. If not available, the distribution does not need to be added below. * Tor available * Tor friendly ** either by action: providing onion repositories ** or by statement: writing down that they don't intent to ban Tor and VPN users ** check if already using CDNs since these often block Tor * Wayland available * Pipewire available * low deplatforming risk * commitment to Freedom Software (not only Open Source) * commitment to user freedom * no anti-features == Comparison Table == '''Figure:''' ''Base Operating Systems Criteria Comparison Table'' {| class="wikitable" style="background-color: #fff;text-align: center; .Systemd: red;" ! ! Debian GNU/Linux ! Void Linux ! Alpine Linux ! openSUSE Tumbleweed ! openSUSE MicroOS ! GNU Guix |- ! Good Usability | {{Yes}} Define of usability of "Debian Linux" as "good" since it is a baseline, a starting point since {{project_name_short}} is currently based on it. There are Linux distributions which might have better usability such as Ubuntu, Elementary OS but also distributions which have worse usability by comparison. The definition of "good" here is not the usability of mainstream operating systems such as Android or iOS. See also {{kicksecure_wiki |wikipage=Linux User Experience versus Commercial Operating Systems |text=Linux User Experience versus Commercial Operating Systems }}. | {{No}} | {{No}} | {{Yes}} Stable and brand new, plays along with new hardware without breaking. The default system snapshots and easy rollbacks. Everything can be configured with YaST, arguably the most powerfull installation and configuration tool on GNU/Linux. Being able to configure the system in detail using a GUI very rare and valuable for usability for desktop GNU/Linux. | {{Yes}} Same as Tumbleweed, but also immutable, so it is really hard for the user to break the system. | {{No}} ? |- ! [https://theupdateframework.io/security/ The Update Framework (TUF) threat model] Pass / Secure Package Manager | {{Yes}} | ? | ? | {{Yes}} ? | {{Yes}} ? | {{Yes}} ? |- |- ! Minimal Number of Services by Default * Daemons (systemd units) do not automatically start once package is installed. * https://forums.whonix.org/t/disable-newly-all-installed-services-by-default/9381 | {{No}} | {{Yes}} Since there is no default per se | {{Yes}} Since there is no default per se | {{Yes}} | {{Yes}} | {{Yes}} Since there is no default per se |- |- ! Mandatory Access Control Policy Enforced by Default | {{Yes}} | {{No}} | {{No}} | {{Yes}} | {{Yes}} | {{No}} |- |- ! Transactional updates by default / auto-upgrades not risking broken boot | {{No}} | {{No}} | {{No}} | {{Yes}} | {{Yes}} | {{No}} |- |- ! Option to secure rollback after update by default | {{No}} | {{No}} | {{No}} | {{Yes}} | {{Yes}} | {{No}} |- |- ! Distribution package source code signed by distribution package maintainer | {{Yes}} {{CodeSelect|code= apt-get source hello }} If it shows: 
gpgv: Can't check signature: public key not found
To fix: {{CodeSelect|code= sudo apt install debian-keyring }} Signatures are in .dsc files and can be verified using dscverify, apt-get or manually using gpg. | {{Yes}} | ? | {{Yes}} | {{Yes}} | ? |- |- ! Package maintainer digital signature is verified by the distribution's build server. | {{Yes}} | ? | ? | {{Yes}} | {{Yes}} | ? |- ! Package Manager Explicitly Uses HTTPS only | {{No}} Can be configured to be this way | ? | ? | {{No}} Can be configured to be this way | {{Yes}} | ? |- ! [https://reproducible-builds.org Reproducible Builds] (deterministic builds) | {{No}} Debian is working on it. | ? | {{No}} Alpine was taking action on this from 2019-2020, but https://reproducible-builds.org/citests/ has Alpine currently listed as Disabled due to its continuous testing longer being maintained. | ? Is there are reproducible ISO? | ? | ? |- ! Source-based distribution | {{No}} | ? | ? | {{No}} | {{No}} | {{Yes}} Also binary on demand |- ! {{kicksecure_wiki |wikipage=Verified_Boot |text=Verified Boot }} | {{No}} | ? | ? | {{Yes}}? | {{Yes}}? | ? |- ! Non-systemd Init | {{No}} | {{Yes}} | {{Yes}} Alpine uses OpenRC, see [https://wiki.alpinelinux.org/wiki/OpenRC the Alpine wiki page] | {{No}} | {{No}} | {{Yes}} |- ! Musl Libc | {{No}} | {{Yes}} | {{Yes}} Alpine says on their [https://alpinelinux.org/about/ organization home page] that it runs on musl and BusyBox | {{No}} | {{No}} | {{No}} |- ! Hardened Memory Allocator | {{No}} | {{No}} | ? | {{No}} | {{No}} | {{No}} |- ! Hardened Kernel | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} |- ! Microkernel | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} |- ! Clang CFI | {{No}} | {{No}} | ? | {{No}} | {{No}} | {{No}} |- ! Rolling Release | {{No}} | {{Yes}} | {{Yes}} Alpine offers repositories for stable branch as well as their edge rolling release branch, as described in their wiki [https://wiki.alpinelinux.org/wiki/Repositories here] | {{Yes}} | {{Yes}} | {{Yes}} |- ! No packages with many unfixed high severity security issues For a prolonged amount of time. https://web.archive.org/web/20201022174657/https://tracker.debian.org/pkg/chromium
* 104 security issues in sid high * 104 security issues in buster high * 104 security issues in bullseye
| {{No}} | ? | {{Yes}} | {{Yes}} This problem is only relevant for stable release distros, where the trust to keep things secure is on distro maintainers. A rolling release being always upstream does not suffer from such problems. Only way this would be possible is if the distro provides abandoned packages in their repositories, which openSUSE does not. | {{Yes}} | {{Yes}} |- ! No packages security issues which are exploited in-the-wild For a prolonged amount of time. Debian version of Chromium reported to be exploited in the wild. Quote https://www.theregister.com/2020/11/04/google_chrome_critical_updates/
Patch Google Chrome with the latest updates – if you don't, you're vulnerable to a zero-day that is actively being exploited, the US Cybersecurity and Infrastructure Security Agency (CISA) has warned. Criminals are targeting users of Chrome with outdated installations, CISA said in an advisory note urging folk to update their browsers immediately. "Google has released Chrome version 86.0.4240.183 for Windows, Mac, and Linux addressing multiple vulnerabilities, including vulnerability '''CVE-2020-16009'''. Exploit code for this vulnerability exists in the wild," said the agency in a statement.
Debian affected by '''CVE-2020-16009''' at time of writing, see: [https://web.archive.org/web/20201109070427/https://security-tracker.debian.org/tracker/CVE-2020-16009 https://web.archive.org/web/20201109070427/https://security-tracker.debian.org/tracker/'''CVE-2020-16009'''] https://forums.whonix.org/t/chromium-browser-for-kicksecure-discussions-not-whonix/10388/49 | {{No}} | ? | {{Yes}} | {{Yes}} | {{Yes}} | {{No}} Despite being up-to-date, not having the proprietary firmware blobs and cpu microcode updates means no update can fix some vulnurabilities |- ! VirtualBox Available | {{Yes}} | {{Yes}} | ? | {{Yes}} | {{Yes}} | ? |- ! KVM Available | {{Yes}} | {{Yes}} | {{Yes}} https://wiki.alpinelinux.org/wiki/KVM | {{Yes}} | {{Yes}} | {{Yes}} |- ! flatpak Available | | | | | | |- ! Tor Browser available as a package | | | | | | |- ! EFI Booting Available | {{Yes}} | {{Yes}} | {{Yes}} https://wiki.alpinelinux.org/wiki/Bootloaders | {{Yes}} | {{Yes}} | ? |- ! Secure Boot Compatibility with Firmware Default Keys * for usability / hardware compatibility, not necessarily as a security feature * default key: Microsoft key | {{Yes}} | ? | {{No}} | {{Yes}} | {{Yes}} | {{No}} |- ! LibreSSL by Default https://forums.whonix.org/t/libressl-by-default/9024 | {{No}} | {{No}} https://voidlinux.org/news/2021/02/OpenSSL.html | {{No}} Setting libressl as default is under consideration per [https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28 here] | {{No}} | {{No}} | {{No}} |- ! [[Dev/Stateless|Stateless/Immutable]] | {{No}} | {{No}} | {{No}} | {{No}} | {{Yes}} | {{No}} |- ! [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942303 Weak Dependencies] (to avoid [[Debian_Packages#Technical_Information|the metapackage issue]]) | {{No}} | ? | ? | {{Yes}} https://en.opensuse.org/openSUSE:Package_dependencies#Strong_and_Weak_dependencies | {{Yes}} | ? |- ! no legal issues (such as [[#Ubuntu_Legal_Issues|this]]) / not forbidden for derivatives to use upstream repositories For example, derivatives of Debian such as {{project_name_short}} are permitted to use the packages.debian.org APT repository. / no excessive, complicated rebranding required / package name changes in the repository required | {{Yes}} | ? | {{Yes}} | ? | ? | {{Yes}} |- ! On [https://www.gnu.org/distros/free-system-distribution-guidelines.en.html GNU FSDG] [https://www.gnu.org/distros/free-distros.html good list] and not on [https://www.gnu.org/distros/common-distros.en.html bad list] | {{No}} | {{No}} | {{No}} | {{No}} | {{No}} | {{Yes}} |- ! Up-to-date Compile Time Flags Hardening | | | | | | |- ! Onion Repositories | | | | | | |- ! Architecture Support (ARM64, POWER9, RISC-V) | | | | | | |- |} offline instalation = ToDo List for Porting to another Base Distribution = Depending on base distribution: * make deprecation of Debian base clear to all {{project_name_short}} users * porting deb packages to another package format * rewrite systemd unit files for another init system, possibly including using Bubblewrap to sandbox these * List non-exhaustive. What else? = Comparison of Hardening Compile Flags = Could be outdated! Debian jessie: 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/bin/curl

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   /usr/bin/gpg

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/bin/gpg2

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   /bin/sed

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /bin/grep

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/bin/tor

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   /bin/bash

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   /usr/bin/gwenview

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
No RELRO        Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/lib/iceweasel/iceweasel

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   /usr/lib/icedove/icedove
Securix (a derivative of Hardened Gentoo): 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/bin/curl

Error: Not an ELF file: /usr/bin/gpg: symbolic link to gpg2

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/bin/gpg2

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /bin/sed

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /bin/grep

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/bin/tor

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /bin/bash

TODO
  /usr/bin/gwenview

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/lib64/firefox/firefox

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   /usr/lib64/thunderbird/thunderbird
= Requesting a Port to a Different Base Operating System = Would you like to propose a transition of {{project_name_short}} from Debian to another base distribution? Below are the procedural steps: '''1.''' Establishing Expectations: This most likely isn't as simple as a feature request. At the time of writing, * [https://github.com/derivative-maker derivative-maker has 1 repository.] * [https://github.com/Kicksecure Kicksecure has 57 repositories.] * [https://github.com/Whonix Whonix has 17 repositories.] Porting these to a different base distribution different base distribution would be a monumental effort. Therefore the argument to change the base distribution would need to be compelling. The probability of this happening is therefore small. The probability would be higher if volunteers would contribute to this goal through source code contributions. For example by contribution to [https://github.com/Kicksecure/genmkfile genmkfile] (code review, bug fixing, unit tests, refactoring, adding support for other operating systems). As an analogy, {{project_name_short}} is similar to a super tanker. Once it's moving at speed it is difficult to change directions. It is not a racing car that can perform stunts. '''2.''' Open an "informal" forum discussion. This is because input from the community is desirable as well as there might be some weird distributions in theory where there would be instant rejection reasons. Perhaps a deprecated distribution or closed source distributions. This is an example of how such a forum thread would go: [https://forums.whonix.org/t/porting-whonix-to-void-linux/9369 Porting Whonix to Void Linux] '''3.''' Add the base distribution to the comparison table. The first request that the project lead developer would probably make is "please add it to the comparison table" here: [[Dev/Operating_System#Criteria_for_Choosing_a_Base_Distribution|Criteria for Choosing a Base Distribution]] Should this task appear excessively challenging, tedious, unrealistic etc. then this needs to be discussed. Perhaps there are easier ways to edit such a comparison table. related discussions: * https://github.com/Kicksecure/security-misc/issues/138 * https://github.com/Kicksecure/security-misc/issues/162 = See Also = * [[Deprecated/grsecurity|About grsecurity]] * [[Operating System Hardening]] * [[Dev/Default_Application_Policy|{{project_name_short}} Default Application Policy]] * See also {{kicksecure_wiki |wikipage=Linux User Experience versus Commercial Operating Systems |text=Linux User Experience versus Commercial Operating Systems }} to learn about organizational issues in the Open Source ecosystem. = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Design]]