Comparison of secureblue with Kicksecure and Development Notes

Kicksecure ™

Download

On Computer USB Installation Debian morph to Kicksecure Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Secureblue and Kicksecure are both hardened operating systems prioritizing security. This wiki page provides a side-by-side comparison of some of their security features, development decisions, and the rationale behind various implementations. Explore how each system addresses security challenges. This guide serves as a resource for developers, security enthusiasts, and users seeking insight into cutting-edge OS security practices.

Quick, preliminary analysis version 0.1, only based on quote secureblue GitHub repository README.md as of Nov 30, 2024, commit hash e40b70df06a30c3a2d99f337f3cbfe3d5a54aa83 and related, linked files.

Hardening

Hardening

• Installing and enabling hardened_malloc globally, including for flatpaks.

Kicksecure is no longer using hardened_malloc for reasons elaborated in chapter Hardened Malloc, Deprecation in Kicksecure.

• Installing hardened-chromium, which is inspired by Vanadium.

Unavailable in Kicksecure at time of writing. See Kicksecure Default Browser - Development Considerations for general considerations and and chapter hardened-chromium specifically.

• Setting numerous hardened sysctl values

secureblue /etc/sysctl.d/hardening.conf file as of commit a6b58f042b0e9e9036a6d68a5b202eed96a1a892 was inspired by, more or less copied and pasted from Kicksecure as can be seen from the following comment found in that file.

## Prevent kernel info leaks in console during boot.
## https://phabricator.whonix.org/T950
kernel.printk = 3 3 3 3

Therefore, Kicksecure has mostly the same settings. These can be found in package security-misc, specifically in folder /usr/lib/sysctl.d.

If there are any differences, these can be discovered during ticket review secureblue sysctl.

Kicksecure might have more complete sysctl settings as per:

This section is inspired by the Kernel Self Protection Project (KSPP). It attempts to implement all recommended Linux kernel settings by the KSPP and many more sources.

https://kspp.github.io/Recommended_Settings

https://github.com/KSPP/kspp.github.iosecurity-misc readme

• Remove SUID-root from numerous binaries and replace functionality using capabilities

Kicksecure has SUID Disabler and Permission Hardener. See also chapter capabilities.

• Disable Xwayland by default (for GNOME, Plasma, and Sway images)

TODO Kicksecure:

• port to Wayland
• https://github.com/Kicksecure/security-misc/issues/168

At this point, Kicksecure (and Whonix) runs primarily inside VMs. GNOME and KDE are unsuitable for Kicksecure.

• GNOME due to security and privacy concerns elaborated on Dev/GNOME.
• In the past KDE was Whonix's default desktop environment but then ported to Xfce due to performance issues. See also Dev/KDE.

No desktop environment suitable for Kicksecure that is already using Wayland has been identified for Kicksecure yet.

• Mitigation of LD_PRELOAD attacks via `ujust toggle-bash-environment-lockdown`

TODO Kicksecure: research

• Disabling coredumps

Implemented in security-misc.

• Disabling all ports and services for firewalld

No open ports for Kicksecure by default.

• Adds per-network MAC randomization

TODO Kicksecure: https://github.com/Kicksecure/security-misc/issues/184

See also MAC Address.

• Blacklisting numerous unused kernel modules to reduce attack surface

secureblue /etc/modprobe.d/blacklist.conf as of git commit c8eff2ca0bc9f7f2db9e1e172dc70942e6983912

looks similar, might be inspired/forked from Kicksecure /etc/modprobe.d files but probably adjusted for secureblue.

• Enabling only the flathub-verified remote by default

Quote Kicksecure Flathub Repository Default Settings:

"Kicksecure mitigates the issues described in chapter Flathub Package Sources Security related to unverified applications and non-freedom software by using Flatpak's subset option with the verified_floss parameter, which means that only Flatpaks can be installed that are both verified apps and floss (Freedom Software)."

• Sets numerous hardening kernel arguments (Inspired by Madaidan's Hardening Guide)

Kicksecure has the same because Madaidan contributed to Kicksecure. Also see KSPP as mentioned above.

• Require wheel user authentication via polkit for `rpm-ostree install`

Not directly appreciable to Kicksecure. User documentation: root. Future enhancements: Role-Based Boot Modes (user versus admin) for Enhanced Security.

• Brute force protection by locking user accounts for 24 hours after 50 failed login attempts, hardened password encryption and password quality suggestions

User accounts are locked after 50 failed login attempts using pam_faillock.

https://kspp.github.io/Recommended_Settings

https://github.com/KSPP/kspp.github.iosecurity-misc readme

• Developer documentation: Bruteforcing Linux User Account Passwords Protection
• User documentation: Default Passwords and Passwords

• Installing usbguard and providing `ujust` commands to automatically configure it

TODO Kicksecure:

• https://forums.whonix.org/t/usbguard-on-kicksecure-to-prevent-hardware-keyloggers-badusb/11988
• https://github.com/Kicksecure/security-misc/pull/166

• Installing bubblejail for additional sandboxing tooling

TODO Kicksecure: sandbox-app-launcher

• Set opportunistic DNSSEC and DNSOverTLS for systemd-resolved

Kicksecure does not use systemd-resolved by default.

systemd-resolved and other tools would require further research. This and systemd-resolved is mentioned here: DNS Security

TODO Kicksecure: Use DNSCrypt by default in Kicksecure?

• Configure chronyd to use Network Time Security (NTS)

Kicksecure uses sdwdate.

• Disable KDE GHNS by default

Probably useful for secureblue but not essential for KDE since it not using GNOME by default.

user documentation: Other Desktop Environments

• Disable install & usage of GNOME user extensions by default

Probably useful for secureblue but not essential for Kicksecure since it not using GNOME by default.

user documentation: Other Desktop Environments

• Use HTTPS for all rpm mirrors

Kicksecure uses tor+https for APT as configured in anon-apt-sources-list and documented on the About wiki page.

• Set all default container policies to `reject`, `signedBy`, or `sigstoreSigned`

Not applicable to Kicksecure since it is not a container focused operating system at time of writing. Probably useful for secureblue if using containers' images.

• Disable a variety of services by default (including cups, geoclue, passim, and others)

Kicksecure does not install these by default and comes with Application-specific hardening.

• Removal of the unmaintained and suid-root fuse2 by default

Kicksecure has SUID Disabler and Permission Hardener.

• (Non-userns variants) Disabling unprivileged user namespaces

Disabling unprivileged user namespaces breaks flatpak, AppImages and Firefox's sandbox. Therefore reverted, not implemented.

• https://forums.kicksecure.com/t/unprivileged-user-namespaces-kernel-unprivileged-userns-clone-can-not-run-flatpak-apps-appimages-after-kicksecure-update/592/
• https://github.com/Kicksecure/security-misc/issues/274

• (Non-userns variants) Replacing bubblewrap with suid-root bubblewrap so flatpak can be used without unprivileged user namespaces

SUID is also a risk. (Hence, SUID Disabler and Permission Hardener exists.)

This mode is not recommended, and some Flatpak apps and features will not work.

[...]

This is a security trade-off. Disallowing unprivileged use of user namespaces reduces the kernel's attack surface, which mitigates some attacks; but it also disallows some sandboxing techniques, which prevents other attacks from being mitigated. Making bwrap or flatpak-bwrap setuid root also carries some risk: an attacker might be able to exploit vulnerabilities in bwrap to achieve root privilege escalation.flatpak wiki, chapter Setuid bubblewrap

Therefore Kicksecure does not use suid-root bubblewrap.

capabilities

• Remove SUID-root from numerous binaries and replace functionality using capabilities

Kicksecure has SUID Disabler and Permission Hardener. As for capabilities, these can be useful but adding capabilities, while sometimes useful, can also add attack surface.

set_caps_if_present "cap_dac_read_search,cap_audit_write=ep" "/usr/bin/chage"

Kicksecure prefers not re-adding capabilities for chage.

These tools probably are used much nowadays on Linux desktop single user computers. If you need any of this, you are better off using root.

• chage man (change user password expiry information)Kicksecure, SUID Disabler and Permission Hardener, SUID SGID Hardening Issues

No user has reported yet that they need the ability to use chage. For the benefit of security hardening, chage remains non-functional in Kicksecure (lower attack surface) for non-root user.

set_caps_if_present "cap_chown,cap_dac_override,cap_fowner,cap_audit_write=ep" "/usr/bin/chfn"

Same as above.

set_caps_if_present "cap_dac_read_search,cap_audit_write=ep" "/usr/sbin/unix_chkpwd"

Same as above.

cap_dac_read_search is dangerous.

CAP_DAC_READ_SEARCH

• Bypass file read permission checks and directory read and execute permission checks;https://man7.org/linux/man-pages/man7/capabilities.7.html

set_caps_if_present "cap_dac_read_search=ep" "/usr/libexec/openssh/ssh-keysign"

TODO: Kicksecure: While cap_dac_read_search is still dangerous, it's better than SUID.

set_caps_if_present "cap_sys_admin=ep" "/usr/bin/fusermount3"

• Kicksecure whitelists fusermount SUID, which is dangerous. (Optional user opt-in: Disable All SUID Binaries) In the future, when Dev/boot modes has been implemented, fusermount might only be accessible for user "admin".
• secureblue sets fusermount cap_sys_admin is dangerous. CAP_SYS_ADMIN: the new root
• Most other Linux desktop distributions: Neither SUID nor capabilities hardening.

sudoless

The term "sudoless" can confusing. See also definition of "sudoless".

v4.2.0 - secureblue goes sudoless! In a continuing effort to minimize and eventually eliminate suid-root binaries, sudo, su, and pkexec have all been removed from the images. As noted at the end of this section of the postinstall readme, polkit prompts and manual polkit invokations via run0 can be used to accomplish the same functionality without suid-root, notably even for non-wheel users (by prompting for the wheel user's password). In addition, suid-root has been removed from numerous other binaries that don't require it.secureblue release announcement: v4.2.0 - secureblue goes sudoless!

Kicksecure won't be using run0 anytime soon.

It’s larger than doas. Way larger. run0 (really systemd-run) is 2642 lines long (including newlines and whatnot), and is heavily tied into the systemd codebase, which is about 1.3 million lines of C code. It’s unclear how much of that could be used to exploit run0, but some of it quite possibly can. doas on the other hand is relatively isolated (the only library it uses beyond the C standard library is PAM), and is only 1,850 lines long. Ergo, less attack surface.Kicksecure developer, Aaron Rainbolt], forum post

Instead, Kicksecure will implement Role-Based Boot Modes (user versus admin) for Enhanced Security, where sudo, su, and pkexec will be non-executable by user user.

See Also

• https://www.kicksecure.com/#security
• About

Footnotes

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!