kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc

Enhances miscellaneous security settings

Kernel hardening

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://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
• https://kspp.github.io/Recommended_Settings
• https://github.com/KSPP/kspp.github.io

sysctl

sysctl settings are configured via the /usr/lib/sysctl.d/990-security-misc.conf configuration file and significant hardening is applied to a myriad of components.

Kernel space:

• Restrict access to kernel addresses through the use of kernel pointers regardless of user privileges.

• Restrict access to the kernel logs to CAP_SYSLOG as they often contain sensitive information.

• Prevent kernel information leaks in the console during boot.

• Restrict usage of bpf() to CAP_BPF to prevent the loading of BPF programs by unprivileged users.

• Restrict loading TTY line disciplines to CAP_SYS_MODULE.

• Restrict the userfaultfd() syscall to CAP_SYS_PTRACE, which reduces the likelihood of use-after-free exploits.

• Disable kexec as it can be used to replace the running kernel.

• Entirely disable the SysRq key so that the Secure Attention Key (SAK) can no longer be utilized. See documentation.

• Restrict user namespaces to CAP_SYS_ADMIN as they can lead to substantial privilege escalation. Optional - Disable all use of user namespaces.

• Restrict kernel profiling and the performance events system to CAP_PERFMON.

• Force the kernel to panic on "oopses" that can potentially indicate and thwart certain kernel exploitation attempts. Optional - Force immediate reboot on the occurrence of a kernel panic and also set panic limit to one (when using Linux kernel >= 6.2).

• Disable the use of legacy TIOCSTI operations which can be used to inject keypresses.

• Disable asynchronous I/O (when using Linux kernel >= 6.6) as io_uring has been the source of numerous kernel exploits.

User space:

• Restrict usage of ptrace() to only processes with CAP_SYS_PTRACE as it enables programs to inspect and modify other active processes. Optional - Disable usage of ptrace() by all processes.

• Maximize the bits of entropy used for mmap ASLR across all architectures.

• Prevent hardlink and symlink TOCTOU races in world-writable directories.

• Disallow unintentional writes to files in world-writable directories unless they are owned by the directory owner to mitigate some data spoofing attacks.

• Randomize the addresses (ASLR) for mmap base, stack, VDSO pages, and heap.

• Increase the maximum number of memory map areas a process is able to utilize.

• Optional - Disallow registering interpreters for various (miscellaneous) binary formats based on a magic number or their file extension to prevent unintended code execution. See issue: #267

Core dumps:

• Disable core dump files and prevent their creation. If core dump files are enabled, they will be named based on core.PID instead of the default core.

Swap space:

• Limit the copying of potentially sensitive content in memory to the swap device.

Networking:

• Enable hardening of the BPF JIT compiler protect against JIT spraying.

• Enable TCP SYN cookie protection to assist against SYN flood attacks.

• Protect against TCP time-wait assassination hazards.

• Enable reverse path filtering (source validation) of packets received from all interfaces to prevent IP spoofing.

• Disable ICMP redirect acceptance and redirect sending messages to prevent man-in-the-middle attacks and minimize information disclosure.

• Ignore ICMP echo requests to prevent clock fingerprinting and Smurf attacks.

• Ignore bogus ICMP error responses.

• Disable source routing which allows users to redirect network traffic that can result in man-in-the-middle attacks.

• Do not accept IPv6 router advertisements and solicitations.

• Optional - Disable SACK and DSACK as they have historically been a known vector for exploitation.

• Disable TCP timestamps as they can allow detecting the system time.

• Optional - Log packets with impossible source or destination addresses to enable further inspection and analysis.

• Optional - Enable IPv6 Privacy Extensions.

Boot parameters

Mitigations for known CPU vulnerabilities are enabled in their strictest form and simultaneous multithreading (SMT) is disabled. See the /etc/default/grub.d/40_cpu_mitigations.cfg configuration file.

Boot parameters relating to kernel hardening, DMA mitigations, and entropy generation are outlined in the /etc/default/grub.d/40_kernel_hardening.cfg configuration file.

Kernel space:

• Disable merging of slabs with similar size, which reduces the risk of triggering heap overflows and limits influencing slab cache layout.

• Enable sanity checks and red zoning via slab debugging. This will implicitly disable kernel pointer hashing, leaking very sensitive information to root.

• Enable memory zeroing at both allocation and free time, which mitigates some use-after-free vulnerabilities by erasing sensitive information in memory.

• Enable the kernel page allocator to randomize free lists to limit some data exfiltration and ROP attacks, especially during the early boot process.

• Enable kernel page table isolation to increase KASLR effectiveness and also mitigate the Meltdown CPU vulnerability.

• Enable randomization of the kernel stack offset on syscall entries to harden against memory corruption attacks.

• Disable vsyscalls as they are vulnerable to ROP attacks and have now been replaced by vDSO.

• Restrict access to debugfs by not registering the file system since it can contain sensitive information.

• Force kernel panics on "oopses" to potentially indicate and thwart certain kernel exploitation attempts.

• Optional - Modify the machine check exception handler.

• Prevent sensitive kernel information leaks in the console during boot.

• Enable the kernel Electric-Fence sampling-based memory safety error detector which can identify heap out-of-bounds access, use-after-free, and invalid-free errors.

• Disable 32-bit vDSO mappings as they are a legacy compatibility feature.

• Optional - Use kCFI as the default CFI implementation (when using Linux kernel >= 6.2) since it may be slightly more resilient to attacks that are able to write arbitrary executables in memory.

• Optional - Disable support for all x86 processes and syscalls (when using Linux kernel >= 6.7) to reduce attack surface.

Direct memory access:

• Enable strict IOMMU translation to protect against some DMA attacks via the use of both CPU manufacturer-specific drivers and kernel settings.

• Clear the busmaster bit on all PCI bridges during the EFI hand-off, which disables DMA before the IOMMU is configured. May cause boot failure on certain hardware.

Entropy:

• Do not credit the CPU or bootloader as entropy sources at boot in order to maximize the absolute quantity of entropy in the combined pool.

• Obtain more entropy at boot from RAM as the runtime memory allocator is being initialized.

Networking:

• Optional - Disable the entire IPv6 stack to reduce attack surface.

mmap ASLR

• The bits of entropy used for mmap ASLR are maxed out via /usr/libexec/security-misc/mmap-rnd-bits (set to the values of CONFIG_ARCH_MMAP_RND_BITS_MAX and CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX that the kernel was built with), therefore improving its effectiveness.

Kernel Modules

Kernel Module Signature Verification

Not yet implemented due to issues:

• https://forums.whonix.org/t/enforce-kernel-module-software-signature-verification-module-signing-disallow-kernel-module-loading-by-default/7880/64
• dell/dkms#359

See:

• /etc/default/grub.d/40_signed_modules.cfg

Disables the loading of new modules to the kernel after the fact

Not yet implemented due to issues:

• #152

A systemd service dynamically sets the kernel parameter modules_disabled to 1, preventing new modules from being loaded. Since this isn't configured directly within systemctl, it does not break the loading of legitimate and necessary modules for the user, like drivers etc., given they are plugged in on startup.

Blacklist and disable kernel modules

Conntrack: Deactivates Netfilter's connection tracking helper module which increases kernel attack surface by enabling superfluous functionality such as IRC parsing in the kernel. See /etc/modprobe.d/30_security-misc_conntrack.conf.

Certain kernel modules are blacklisted by default to reduce attack surface via /etc/modprobe.d/30_security-misc_blacklist.conf. Blacklisting prevents kernel modules from automatically starting.

• CD-ROM/DVD: Blacklist modules required for CD-ROM/DVD devices.

• Miscellaneous: Blacklist an assortment of other modules to prevent them from automatically loading.

Specific kernel modules are entirely disabled to reduce attack surface via /etc/modprobe.d/30_security-misc_disable.conf. Disabling prohibits kernel modules from starting. This approach should not be considered comprehensive; rather, it is a form of badness enumeration. Any potential candidates for future disabling should first be blacklisted for a suitable amount of time.

Hardware modules:

• Optional - Bluetooth: Disabled to reduce attack surface.

• FireWire (IEEE 1394): Disabled as they are often vulnerable to DMA attacks.

• GPS: Disable GPS-related modules such as those required for Global Navigation Satellite Systems (GNSS).

• Optional - Intel Management Engine (ME): Provides some disabling of the interface between the Intel ME and the OS. May lead to breakages in places such as firmware updates, security, power management, display, and DRM. See discussion: #239

• Intel Platform Monitoring Technology (PMT) Telemetry: Disable some functionality of the Intel PMT components.

• Thunderbolt: Disabled as they are often vulnerable to DMA attacks.

File system modules:

• File Systems: Disable uncommon and legacy file systems.

• Network File Systems: Disable uncommon and legacy network file systems.

Networking modules:

• Network Protocols: A wide array of uncommon and legacy network protocols and drivers are disabled.

Miscellaneous modules:

• Amateur Radios: Disabled to reduce attack surface.

• Optional - CPU MSRs: Disabled as can be abused to write to arbitrary memory.

• Floppy Disks: Disabled to reduce attack surface.

• Framebuffer (fbdev): Disabled as these drivers are well-known to be buggy, cause kernel panics, and are generally only used by legacy devices.

• Replaced Modules: Disabled legacy drivers that have been entirely replaced and superseded by newer drivers.

• Optional - USB Video Device Class: Disables the USB-based video streaming driver for devices like some webcams and digital camcorders.

• Vivid: Disabled to reduce attack surface given previous vulnerabilities.

Other

• A systemd service clears the System.map file on boot as these contain kernel pointers. The file is completely overwritten with zeroes to ensure it cannot be recovered. See:

/etc/kernel/postinst.d/30_remove-system-map

/lib/systemd/system/remove-system-map.service

/usr/libexec/security-misc/remove-system.map

• Coredumps are disabled as they may contain important information such as encryption keys or passwords. See:

/etc/security/limits.d/30_security-misc.conf

/etc/sysctl.d/30_security-misc.conf

/lib/systemd/coredump.conf.d/30_security-misc.conf

• An initramfs hook sets the sysctl values in /etc/sysctl.conf and /etc/sysctl.d before init is executed so sysctl hardening is enabled as early as possible. This is implemented for initramfs-tools only because this is not needed for dracut as dracut does that by default, at least on systemd enabled systems. Not researched for non-systemd systems by the author of this part of the readme.

Network hardening

Not yet implemented due to issues:

• #145

• #184

• Unlike version 4, IPv6 addresses can provide information not only about the originating network but also the originating device. We prevent this from happening by enabling the respective privacy extensions for IPv6.

• In addition, we deny the capability to track the originating device in the network at all, by using randomized MAC addresses per connection by default.

See:

• /usr/lib/NetworkManager/conf.d/80_ipv6-privacy.conf
• /usr/lib/NetworkManager/conf.d/80_randomize-mac.conf
• /usr/lib/systemd/networkd.conf.d/80_ipv6-privacy-extensions.conf

Bluetooth Hardening

Bluetooth Status: Enabled but Defaulted to Off

• Default Behavior: Although Bluetooth capability is 'enabled' in the kernel, security-misc deviates from the usual behavior by starting with Bluetooth turned off at system start. This setting remains until the user explicitly opts to activate Bluetooth.

• User Control: Users have the freedom to easily switch Bluetooth on and off in the usual way, exercising their own discretion. This can be done via the Bluetooth toggle through the usual way, that is either through GUI settings application or command line commands.

• Enhanced Privacy Settings: We enforce more private defaults for Bluetooth connections. This includes the use of private addresses and strict timeout settings for discoverability and visibility.

• Security Considerations: Despite these measures, it's important to note that Bluetooth technology, by its nature, may still be prone to exploits due to its history of security vulnerabilities. Thus, we recommend users to opt-out of using Bluetooth when possible.

Configuration Details

• See configuration: /etc/bluetooth/30_security-misc.conf
• For more information and discussion: GitHub Pull Request

Understanding Bluetooth Terms

• Disabling Bluetooth: This means the absence of the Bluetooth kernel module. When disabled, Bluetooth is non-existent in the system - it cannot be seen, set, configured, or interacted with in any way.

• Turning Bluetooth On/Off: This refers to a software toggle. Normally, on Debian systems, Bluetooth is 'on' when the system boots up. It actively searches for known devices to auto-connect and may be discoverable or visible under certain conditions. Our default ensures that Bluetooth is off on startup. However, it remains 'enabled' in the kernel, meaning the kernel can use the Bluetooth protocol and has the necessary modules.

Quick Toggle Guide

• Turning Bluetooth On: Simply click the Bluetooth button in the settings application or on the tray, and switch the toggle. It's a straightforward action that can be completed in less than a second.

• Turning Bluetooth Off: Follow the same procedure as turning it on but switch the toggle to the off position.

Entropy collection improvements

• The jitterentropy_rng kernel module is loaded as early as possible during boot to gather more entropy via the /usr/lib/modules-load.d/30_security-misc.conf configuration file.

• Distrusts the CPU for initial entropy at boot as it is not possible to audit, may contain weaknesses or a backdoor. Similarly, do not credit the bootloader seed for initial entropy. For references, see: /etc/default/grub.d/40_kernel_hardening.cfg

• Gathers more entropy during boot if using the linux-hardened kernel patch.

Restrictive mount options

A systemd service is triggered on boot to remount all sensitive partitions and directories with significantly more secure hardened mount options. Since this would require manual tuning for a given specific system, we handle it by creating a very solid configuration file for that very system on package installation.

Not enabled by default yet. In development. Help welcome.

• https://www.kicksecure.com/wiki/Dev/remount-secure
• #157
• https://forums.whonix.org/t/re-mount-home-and-other-with-noexec-and-nosuid-among-other-useful-mount-options-for-better-security/

Root access restrictions

• su is restricted to only users within the group sudo which prevents users from using su to gain root access or to switch user accounts - /usr/share/pam-configs/wheel-security-misc (which results in a change in file /etc/pam.d/common-auth).

• Add user root to group sudo. This is required due to the above restriction so that logging in from a virtual console is still possible - debian/security-misc.postinst

• Abort login for users with locked passwords - /usr/libexec/security-misc/pam-abort-on-locked-password.

• Logging into the root account from a virtual, serial, or other console is prevented by shipping an existing and empty /etc/securetty file (deletion of /etc/securetty has a different effect).

This package does not yet automatically lock the root account password. It is not clear if this would be sane in such a package, although it is recommended to lock and expire the root account.

In new Kicksecure builds, the root account will be locked by package dist-base-files.

See:

• https://www.kicksecure.com/wiki/Root
• https://www.kicksecure.com/wiki/Dev/Permissions
• https://forums.whonix.org/t/restrict-root-access/7658

However, a locked root password will break rescue and emergency shell. Therefore, this package enables passwordless rescue and emergency shell. This is the same solution that Debian will likely adopt for the Debian installer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211

See:

• /etc/systemd/system/emergency.service.d/override.conf
• /etc/systemd/system/rescue.service.d/override.conf

Adverse security effects can be prevented by setting up BIOS password protection, GRUB password protection, and/or full disk encryption.

Console lockdown

This uses pam_access to allow members of group console to use the console but restrict everyone else (except members of group console-unrestricted) from using the console with ancient, unpopular login methods such as /bin/login over networks as this might be exploitable. (CVE-2001-0797)

This is not enabled by default in this package since this package does not know which users should be added to group 'console' and thus, would break console access.

See:

• /usr/share/pam-configs/console-lockdown-security-misc
• /etc/security/access-security-misc.conf

Brute force attack protection

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

Informational output during Linux PAM:

• Show failed and remaining password attempts.
• Document unlock procedure if Linux user account got locked.
• Point out that there is no password feedback for su.
• Explain locked root account if locked.

See:

• /usr/share/pam-configs/tally2-security-misc
• /usr/libexec/security-misc/pam-info
• /usr/libexec/security-misc/pam-abort-on-locked-password

Access rights restrictions

Strong user account separation

Permission Lockdown

Read, write, and execute access for "others" are removed during package installation, upgrade, or PAM mkhomedir for all users who have home folders in /home by running, for example:

chmod o-rwx /home/user

This will be done only once per folder in /home so users who wish to relax file permissions are free to do so. This is to protect files in a home folder that were previously created with lax file permissions prior to the installation of this package.

See:

• debian/security-misc.postinst
• /usr/libexec/security-misc/permission-lockdown
• /usr/share/pam-configs/mkhomedir-security-misc

umask

Default umask is set to 027 for files created by non-root users such as user user. Broken. Disabled. See:

• #184

This is done using the PAM module pam_mkhomedir.so umask=027.

This means files created by non-root users cannot be read by other non-root users by default. While Permission Lockdown already protects the /home folder, this protects other folders such as /tmp.

group read permissions are not removed. This is unnecessary due to Debian's use of User Private Groups (UPGs). See also: https://wiki.debian.org/UserPrivateGroups

Default umask is unchanged for root because then configuration files created in /etc by the system administrator would be unreadable by "others" and break applications. Examples include /etc/firefox-esr and /etc/thunderbird.

See:

• /usr/share/pam-configs/umask-security-misc

SUID / SGID removal and permission hardening

SUID / SGID removal

A systemd service removes SUID / SGID bits from non-essential binaries as these are often used in privilege escalation attacks.

File permission hardening

Various file permissions are reset with more secure and hardened defaults. These include but are not limited to:

• Limiting /home and /root to the root only.
• Limiting crontab to root as well as all the configuration files for cron.
• Limiting the configuration for cups and ssh.
• Protecting the information of sudoers from others.
• Protecting various system-relevant files and modules.

permission-hardener

permission-hardener removes SUID / SGID bits from non-essential binaries as these are often used in privilege escalation attacks. It is enabled by default and applied at security-misc package installation and upgrade time.

There is also an optional systemd unit which does the same at boot time that can be enabled by running systemctl enable permission-hardener.service as root. The hardening at boot time is not the default because this slows down the boot process too much.

See:

• /usr/bin/permission-hardener
• debian/security-misc.postinst
• /lib/systemd/system/permission-hardener.service
• /etc/permission-hardener.d
• https://forums.whonix.org/t/disable-suid-binaries/7706
• https://www.kicksecure.com/wiki/SUID_Disabler_and_Permission_Hardener

Access rights relaxations

This is not enabled yet because hidepid is not enabled by default.

Calls to pkexec are redirected to lxqt-sudo because pkexec is incompatible with hidepid=2.

See:

• /usr/bin/pkexec.security-misc
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860040
• https://forums.whonix.org/t/cannot-use-pkexec/8129

Application-specific hardening

• Enables "apt-get --error-on=any" which makes apt exit non-zero for transient failures. - /etc/apt/apt.conf.d/40error-on-any.
• Enables APT seccomp-BPF sandboxing - /etc/apt/apt.conf.d/40sandbox.
• Deactivates previews in Dolphin.
• Deactivates previews in Nautilus - /usr/share/glib-2.0/schemas/30_security-misc.gschema.override.
• Deactivates thumbnails in Thunar.
  • Rationale: lower attack surface when using the file manager
  • https://forums.whonix.org/t/disable-preview-in-file-manager-by-default/18904
• Thunderbird is hardened with the following options:
  • Displays domain names in punycode to prevent IDN homograph attacks (a form of phishing).
  • Strips email client information from sent email headers.
  • Strips user time information from sent email headers by replacing the originating time zone with UTC and rounding the timestamp to the nearest minute.
  • Disables scripting when viewing PDF files.
  • Disables implicit outgoing connections.
  • Disables all and any kind of telemetry.
• Security and privacy enhancements for gnupg's config file /etc/skel/.gnupg/gpg.conf. See also:
  • https://raw.github.com/ioerror/torbirdy/master/gpg.conf
  • ioerror/torbirdy#11

Project scope of application-specific hardening

Added in December 2023.

Before sending pull requests to harden arbitrary applications, please note the scope of security-misc is limited to default installed applications in Kicksecure and Whonix. This includes:

• Thunderbird, VLC Media Player, KeePassXC
• Debian Specific System Components (APT, DPKG)
• System Services (NetworkManager IPv6 privacy options, MAC address randomization)
• Actually used development utilities such as git.

It will not be possible to review and merge "1500" settings profiles for arbitrary applications outside of this context.

The main objective of security-misc is to harden Kicksecure and its derivatives, such as Whonix, by implementing robust security settings. It's designed to be compatible with Debian, reflecting a commitment to clean implementation and sound design principles. However, it's important to note that security-misc is a component of Kicksecure, not a substitute for it. The intention isn't to recreate Kicksecure within security-misc. Instead, specific security enhancements, like recommending a curated list of security-focused default packages (e.g., libpam-tmpdir), should be integrated directly into those appropriate areas of Kicksecure (e.g. kicksecure-meta-packages).

Discussion: #154

Development philosophy

Added in December 2023.

Maintainability is a key priority [1]. Before modifying settings in the downstream security-misc, it's essential to first engage with upstream developers to propose these changes as defaults. This step should only be bypassed if there's a clear, prior indication from upstream that such changes won't be accepted. Additionally, before implementing any workarounds, consulting with upstream is necessary to avoid future unmaintainable complexity.

If debugging features are disabled, pull requests won't be merged until there is a corresponding pull request for the debug-misc package to re-enable these. This is to avoid configuring the system into a corner where it can no longer be debugged.

[1] https://www.kicksecure.com/wiki/Dev/maintainability

Opt-in hardening

Some hardening is opt-in as it causes too much breakage to be enabled by default.

• An optional systemd service mounts /proc with hidepid=2 at boot to prevent users from seeing another user's processes. This is disabled by default because it is incompatible with pkexec. It can be enabled by executing systemctl enable proc-hidepid.service as root.

• A systemd service restricts /proc/cpuinfo, /proc/bus, /proc/scsi, and /sys to the root user. This hides a lot of hardware identifiers from unprivileged users and increases security as /sys exposes a lot of information that shouldn't be accessible to unprivileged users. As this will break many things, it is disabled by default and can optionally be enabled by executing systemctl enable hide-hardware-info.service as root.

Miscellaneous

• Hardened malloc compatibility for haveged workaround /lib/systemd/system/haveged.service.d/30_security-misc.conf

• Set dracut reproducible=yes setting

Legal

/usr/lib/issue.d/20_security-misc.issue

#167

Related

• Linux Kernel Runtime Guard (LKRG)
• tirdad - TCP ISN CPU Information Leak Protection.
• Kicksecure (TM) - a security-hardened Linux Distribution
• And more.
• https://www.kicksecure.com/wiki/Linux_Kernel_Runtime_Guard_LKRG
• https://github.com/Kicksecure/tirdad
• https://www.kicksecure.com
• https://github.com/Kicksecure

Discussion

Happening primarily in forums.

https://forums.whonix.org/t/kernel-hardening/7296

How to install security-misc

See https://www.kicksecure.com/wiki/Security-misc#install

How to Build deb Package from Source Code

Can be build using standard Debian package build tools such as:

dpkg-buildpackage -b

See instructions. (Replace generic-package with the actual name of this package security-misc.)

• A) easy, OR
• B) including verifying software signatures

Contact

• Free Forum Support
• Professional Support

Donate

security-misc requires donations to stay alive!

security-misc's Issues

Secure Remounting

Is there any particular reason to have a systemd service remount partitions rather than editing /etc/fstab accordingly? This seems cause extra complexity without any benefit that I could see of.

As a reference, the recommended options from the lynis documentation can be used. I have tested this and no application seems to break that a debian user would normally install, let alone any whonix default packages.

#            ---------------------------------------------------------
#               Mount point              nodev  noexec  nosuid
#               /boot                            v            v            v
#               /dev                              v            v
#               /dev/shm                      v            v            v
#               /home                           v                         v
#               /run                               v                         v
#               /tmp                              v            v            v
#               /var                               v                         v
#               /var/log                         v            v            v
#               /var/log/audit                v            v            v
#               /var/tmp                        v            v            v
#            ---------------------------------------------------------

This can be achieved with a simple bind for those without literal partitions on disk. And for the literal partitions, a basic sed operation can be used on fstab. The old fstab can be backed up to be restored upon package removal.

So what would be the reason to use a service here? If this is not necessary, I can create a pull request for modifying the fstab. If there is a reason that I do not know of, the same recommended options can be adapted by the service, I assume.

Serious Question - Porting to new distro - Procedure

Since I have previously made the suggestion to base kicksecure to Tumbleweed, I can't unsee all the benefits everywhere. Our suid disabler is one of them. The Qubes vulnurability ticket. The package that causes the vulnurability to escelate privileges to root, is whitelisted in our hand written service.

On Tumbleweed, we would just do suid whitelisting on the default shipped secure file permissions configuration. See here.

I also can't unsee the fact that we maintain our service that is not as efficient and we also have to play along with dpkg seperately so that our secure permissions don't get overridden. These are all automatically managed in Tumbleweed.

In most cases, a Tumbleweed base would reduce the complexity of Kicksecure from maintaining a lot of services to maintaining a lot of mere configuration files.

What is the procedure to switch to Tumbleweed? It seems kicksecure is tied too much to debian. What packages need to be ported, very specifically. Which ones. Tell me. Even if you don't want to port at all, you do you, I still want to try for myself to port. I want to try to create a Kicksecure SUSE edition, or whatever I'm allowed call it while respecting all the trademarks.

Someone has to do this to prove it possible. I did research. Even tho challenging in the beginning, I sincerely believe Tumbleweed will make development and maintaining easier in the long run, not to mention all the security benefits already in place in openSUSE Tumbleweed.

consider excluding hardened malloc from SUID Disabler

As per:
https://gist.github.com/SkewedZeppelin/7f293d64c1c651bdc21526519d9e192b

Harden Network

I am not sure if this package would be the right place for this task, but I think there is no other kicksecure repo that is more suited.

We have to take upon ourselves to harden the interaction with network. This has several steps:

• Set up a really hardened firewall using nftables. Alternatively we can depend on a high level firewall service.
• Block all incoming connections.
• Block all forwarding and routing.
• Allow forwarding and routing and incoming connections for a few select network daemons and applications, like cups, ssh, avahi etc., so that the average user won't notice a thing at all.
• For all the select daemons that are allowed to bypass the firewall, set the environment variable Environment="LD_PRELOAD='libhardened_malloc.so' in their systemd service config.
• Also for those, set After=apparmor.service and AppArmorProfile=profile.
• Profiles will be from apparmor.d, which I am hoping kicksecure will package soon, because it is really already ready and there is a deb target specifically for whonix upstream. We would have to depend on this package, which I think is ok. We should not be afraid to depend on packages, especially those that belong to kicksecure.
• We would also have to depend on hardened malloc as you can guess.

What is achieved after: No connection from outside can enter the system aside from select services, which are forcibly protected and heavily limited and confined with mandatory access control and significantly hardened against memory and heap safety vulnurabilities. This won't be suited for servers. About that I am opening another issue.

test Remount Secure in Qubes

improve output by permission-hardener

Too verbose and not particularly helpful. I plan on removing:

• parsing messages
• whitelist notifications
• does not exist notifications

Running SUID Disabler and Permission Hardener... See also:
https://www.kicksecure.com/wiki/SUID_Disabler_and_Permission_Hardener

/var/lib/dpkg/info/security-misc.postinst: INFO: run: /usr/libexec/security-misc/permission-hardening
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_passwd.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_passwd.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_sudo.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_sudo.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_bubblewrap.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_bubblewrap.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_chromium.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_chromium.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_dbus.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_dbus.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_firejail.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_firejail.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_fuse.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_fuse.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_mount.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_mount.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_pam.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_pam.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_policykit.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_policykit.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_qubes.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_qubes.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_selinux.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_selinux.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_spice.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_spice.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_sudo.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_sudo.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_unix_chkpwd.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_unix_chkpwd.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_virtualbox.conf'
INFO: END parsing config_file: '/etc/permission-hardening.d/25_default_whitelist_virtualbox.conf'
INFO: START parsing config_file: '/etc/permission-hardening.d/30_default.conf'
INFO: fso: '/usr/local/etc/permission-hardening.d' - does not exist. This is likely normal.
INFO: fso: '/etc/syslog.conf' - does not exist. This is likely normal.
INFO: fso: '/etc/ssh/sshd_config' - does not exist. This is likely normal.
INFO: SKIP whitelisted - set-user-id  found - file_name: '/bin/pkexec' | existing_mode: '4755'
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/bin/fusermount3' | existing_mode: '4755' | matchwhite_list_entry: '/fusermount'
INFO: SKIP whitelisted - set-user-id  found - file_name: '/bin/sudo' | existing_mode: '4755'
INFO: SKIP whitelisted - set-user-id  found - file_name: '/usr/bin/pkexec' | existing_mode: '4755'
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/usr/bin/fusermount3' | existing_mode: '4755' | matchwhite_list_entry: '/fusermount'
INFO: SKIP whitelisted - set-user-id  found - file_name: '/usr/bin/sudo' | existing_mode: '4755'
INFO: fso: '/usr/local/usr/bin/' - does not exist. This is likely normal.
INFO: SKIP whitelisted -  set-group-id found - file_name: '/sbin/unix_chkpwd' | existing_mode: '2755'
INFO: SKIP whitelisted -  set-group-id found - file_name: '/usr/sbin/unix_chkpwd' | existing_mode: '2755'
INFO: fso: '/usr/local/usr/sbin/' - does not exist. This is likely normal.
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/lib/dbus-1.0/dbus-daemon-launch-helper' | existing_mode: '4754' | matchwhite_list_entry: 'dbus-daemon-launch-helper'
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/lib/qubes/qfile-unpacker' | existing_mode: '4755' | matchwhite_list_entry: '/qubes/qfile-unpacker'
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/lib/polkit-1/polkit-agent-helper-1' | existing_mode: '4755' | matchwhite_list_entry: 'polkit-agent-helper-1'
INFO: SKIP matchwhitelisted -  set-group-id found - file_name: '/lib/x86_64-linux-gnu/utempter/utempter' | existing_mode: '2755' | matchwhite_list_entry: '/utempter/utempter'
INFO: fso: '/usr/local/lib32/' - does not exist. This is likely normal.
INFO: fso: '/usr/local/lib64/' - does not exist. This is likely normal.
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/usr/lib/dbus-1.0/dbus-daemon-launch-helper' | existing_mode: '4754' | matchwhite_list_entry: 'dbus-daemon-launch-helper'
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/usr/lib/qubes/qfile-unpacker' | existing_mode: '4755' | matchwhite_list_entry: '/qubes/qfile-unpacker'
INFO: SKIP matchwhitelisted - set-user-id  found - file_name: '/usr/lib/polkit-1/polkit-agent-helper-1' | existing_mode: '4755' | matchwhite_list_entry: 'polkit-agent-helper-1'
INFO: SKIP matchwhitelisted -  set-group-id found - file_name: '/usr/lib/x86_64-linux-gnu/utempter/utempter' | existing_mode: '2755' | matchwhite_list_entry: '/utempter/utempter'
INFO: fso: '/usr/local/usr/lib/' - does not exist. This is likely normal.
INFO: fso: '/usr/local/usr/lib32/' - does not exist. This is likely normal.
INFO: fso: '/usr/local/usr/lib64/' - does not exist. This is likely normal.
INFO: fso: '/usr/local/opt/' - does not exist. This is likely normal.
INFO: END parsing config_file: '/etc/permission-hardening.d/30_default.conf'
/var/lib/dpkg/info/security-misc.postinst: INFO: Permission hardening success.

RPM packaging

How much work would it require to package this source as an .rpm? I would really like to test this on opensuse. I can also a tool like alien, but a native solution would be better, like if this package supported building as an rpm. Would this be merged if I implement it?

Originally posted by @monsieuremre in #136 (comment)

remounting `/usr` as read-only for better security

I have tested on a debian VM the following:

*First, mount /usr as read only
mount -o ro --bind /usr /usr

Try creating or modify any files under /usr
touch /usr/bin/bad-binary
touch: cannot touch '/usr/bin/bad-binary': Read-only file system

So we know it is read only. Then create the file with the following content:

echo "
Dpkg::Pre-Invoke {"mount -o remount,nodev,rw /usr";};
Dpkg::Post-Invoke {"mount -o remount,nodev,ro /usr";};
" >> /etc/apt/apt.conf.d/security-usr

Try apt update and apt upgrade or anything apt. It works.
Post and pre invoke make sure /usr is remounted everytime before apt is invoked, no matter for what purpose.

This hardens against any modification in binaries or libraries in the system. For this a remount is necessary. Only root can do this.

Redundant kernel args

According to the kernel's documentation:

auto,nosmt:
Mitigate all CPU vulnerabilities, disabling SMT if needed. This is for users who always want to be fully mitigated, even if it means losing SMT. Equivalent to:

• l1tf=flush,nosmt [X86]
• mds=full,nosmt [X86]
• tsx_async_abort=full,nosmt [X86]
• mmio_stale_data=full,nosmt [X86]
• retbleed=auto,nosmt [X86]

Why are these other args being explicitly set in /etc/default/grub.d if mitigations=auto,nosmt is already being set?

There is a limit on number of characters that can be in the kernel args as well, and the kernel args we set will just get longer and longer over time. I don't think it is a good idea to waste the precious characters on these redundant args. Either we use mitigations=auto,nosmt (which should be the default anyways), or explicitly spell out which args to set so the user can easily customize them. There is really no reason to have both.

allow only loading signed kernel modules / module.sig_enforce=1

related:
https://forums.whonix.org/t/enforce-kernel-module-software-signature-verification-module-signing-disallow-kernel-module-loading-by-default/7880/63

Perhaps a separate issue.

(Not suggested as a replacement. Enforcing signature verification would be in addition.)

Originally posted by @adrelanos in #148 (comment)

The claim about DSACK causing security issues is not actually backed by evidence

The comment here

security-misc/etc/sysctl.d/tcp_sack.conf

Lines 1 to 2 in c19942f

	# Disables SACK as it is commonly exploited and likely not needed.
	# https://forums.whonix.org/t/disabling-tcp-sack-dsack-fack/8109

makes it appear as if using DSACK would be a security problem. However, the discussion linked doesn't seem to provide any evidence for this. The linked SUSE material only speaks about disabling DSACK in 10 Gbit networks to reduce CPU usage.

`hide-hardware-info.service`: hide `/proc/kallsyms`

Add /proc/kallsyms to the list as well, as this contains all the memory addresses for each kernel symbol.

Originally posted by @monsieuremre in #172

Maybe not needed if we implement:

• #205

fix Bluetooth readme

Bluetooth is left enabled but users are highly discouraged from ever turning it on, due to its history of numerous security vulnerabilities. Unlike the default settings, we start the system with bluetooth turned off. We also enforce private addresses and strict timeout settings for discoverability and visibility.

Sounds like a contradiction.

Restrict umask to 027 except for sudo/root broken

Currently umask is set to 027 (read, write for owner and group only).
(Group is OK because Debian uses usergroups by default, UPG (UserPrivateGroups)).

This however should not be the case for files created by root as this is super confusing, causing issues when creating files in /etc (or /usr) as these won't be readable by applications normally suppose to be able to read these running as non-root. That part is broken.

Therefore unfortunately this feature has to be reverted until this can be fixed.

This was discussed before here:

• #18

The following unfortunately has to be removed.

/usr/share/pam-configs/umask-security-misc

Name: Restrict umask to 027 (by package security-misc)
Default: yes
Priority: 100
Session-Type: Additional
Session-Interactive-Only: yes
Session:
	[success=1 default=ignore]	pam_succeed_if.so uid eq 0
	optional	pam_umask.so umask=027

I cannot even just out-comment it to make it easier to tinker as folder /usr/share/pam-configs does not support comments. Populating /etc/pam.d from /usr/share/pam-configs is a Debian / Ubunut feature.

• https://unix.stackexchange.com/questions/337808/where-is-the-official-documentation-for-the-files-in-usr-share-pam-configs-in
• https://wiki.ubuntu.com/PAMConfigFrameworkSpec

---

Command for testing:

touch a && ls -la a && rm a

I tried various stuff to fix it:

• delete Session-Interactive-Only: yes

        [success=2 default=ignore]      pam_succeed_if.so debug uid eq 0
        [success=1 default=ignore]      pam_succeed_if.so debug use_uid uid eq 0
	optional	pam_umask.so debug umask=027

---

This issue is only happening in non-Qubes. Not reproducible in Qubes Debian. This might be because Qubes login session work differently. This is probably also why I did not spot this issue beforehand.

---

Contributing: I don't necessarily need the config snippet for /usr/share/pam-configs as I might be able to figure that out but the config snipped required for /etc/pam.d would very useful.

MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic

https://github.com/Kicksecure/security-misc/blob/master/usr/lib/NetworkManager/conf.d/80_randomize-mac.conf

[device-mac-randomization]
wifi.scan-rand-mac-address=yes

[connection-mac-randomization]
ethernet.cloned-mac-address=random
wifi.cloned-mac-address=random

1. Breaks root servers, namely broke kicksecure.com. This is what the server provide sent by e-mail.

We have detected that your server is using different MAC addresses from those allowed by your Robot account.

Please take all necessary measures to avoid this in the future and to solve the issue.
We also request that you send a short response to us. This response should contain information about how this could have happened and what you intend to do about it.
In the event that the following steps are not completed successfully, your server can be locked at any time after 2024-01-17 16:51:11 +0100.

How to proceed:
- Solve the issue
- Please note, in case you have fixed the problem, please wait at least 10 minutes before rechecking: ...
- After successfully testing that the issue is resolved, send us a statement by using the following link:...

Please visit our FAQ here, if you are unsure how to proceed:
https://docs.hetzner.com/robot/dedicated-server/faq/error-faq/#mac-errors

Important note:
When replying to us, please leave the abuse ID [...] unchanged in the subject line. Manual replies will only be handled in the event of a lock.
Please note that we do not provide telephone support in our department. If you have any questions, please send them to us by responding to this email.

Kind regards

Network department

2. Breaks VirtualBox DHCP when using Network Manger (in Kicksecure) after VM reboot (sudo reboot). It is functional for the first start after powering off and powering on the VM. [1]

Might be related:
https://forums.virtualbox.org/viewtopic.php?t=86753

Could be a Network Manager issue:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1116421
https://askubuntu.com/questions/307717/networkmanager-problem-with-cloned-mac-address

---

[1] Before someone says that's a VirtualBox issue, no, I mean, maybe, but that doesn't matter.
VirtualBox is a valid environment. If that breaks, other environments will break as well.
Broken networking is extremely frustrating. MAC randomization would be suitable for Kicksecure, but only if stable.

It's not important enough to break common network configurations in common environments.

---

TODO: This bug has to be reported to Network Manager (NM) as above bug reports apparently never have reached upstream NM.

Linux security

Your main activity is silencing any critiques.
And BTW, in your publication [(https://madaidans-insecurities.github.io/linux.html)] you pretend that Linux is completely insecure, of course not telling in a single word how many good additions are available.
Hopefully nobody will finance you...

use SRSO spec_rstack_overflow kernel setting?

To test:

cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow

https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html

	spec_rstack_overflow=
			[X86] Control RAS overflow mitigation on AMD Zen CPUs

			off		- Disable mitigation
			microcode	- Enable microcode mitigation only
			safe-ret	- Enable sw-only safe RET mitigation (default)
			ibpb		- Enable mitigation by issuing IBPB on
					  kernel entry
			ibpb-vmexit	- Issue IBPB only on VMEXIT
					  (cloud-specific mitigation)

Best to use spec_rstack_overflow=ibpb?

Or not needed because we're already using spec_store_bypass_disable=on?

`flatpak remote-add` TOFU and TLS security issue / use stronger authentication than TLS

Issue

The command flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo for adding the Flathub repository has a security concern. That command downloads a Flatpak repository file. That file contains an OpenPGP (gpg) signing key under the GPGKey= keyword, but this key is not authenticated beyond the security provided by TLS.

The command relies on Trust on First Use (TOFU), which is a less secure approach compared to verification of signing keys. In essence, TOFU means trusting the initial connection and the credentials received without additional verification.

When a repository is added using the flatpak remote-add command, the Flatpak repository definition file is downloaded over TLS (Transport Layer Security). While TLS provides basic security, TLS CA system not very secure and has been hacked multiple times.. TLS alone does not provide strong verification of the authenticity of the software’s origin.

It would be more secure to verify the key fingerprinting through the OpenPGP web of trust or other means of key fingerprinting verification.

The reliance on TLS for verification lowers the overall security level. Ideally, software verification should be done through established and strong cryptographic signatures, ensuring that the software comes from a trusted source and has not been tampered with.

To enhance security, users could manually add the Flathub repository configuration. This can be done by placing a configuration snippet directly in the /etc/flatpak/remotes.d directory. A file like /etc/flatpak/remotes.d/flathub.flatpakrepo can be created for this purpose. The content of this file, especially the GPGKey= keyword, should be sourced from a more secure, authenticated method than TLS. This ensures that the repository’s signing key is verified and trusted beyond the initial TLS connection.

In other words, the flatpak remote-add command currently fails against a MitM capable of breaking TLS. This is sad because by comparison other package managers such as Debian's APT survives that (assuming there is no vulnerability in that gpg verification code). Once the user has installed the Linux distribution, the signing key is installed and used. The package manager can use TLS for an additional security layer but is also secure in case TLS is compromised.

---

Solution 1: Use properly formatted OpenPGP keys in flathub.flatpakrepo.

Add support for properly formatted OpenPGP keys in flathub.flatpakrepo files. At the end:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFlD2sABEADsiUZUOYBg1UdDaWkEdJYkTSZD68214m8Q1fbrP5AptaUfCl8K
-----END PGP PUBLIC KEY BLOCK-----

Because currently GPGKey= is hard to convert into a format that gpg understands. I tried to extract the key from GPGKey= , add BEGIN and END but that won't work. Error: gpg: invalid radix64 character 2D skipped
Probably because the lines are too long.

I tried formatting the lines.

awk '/-----BEGIN PGP PUBLIC KEY BLOCK-----/,/-----END PGP PUBLIC KEY BLOCK-----/ { if (!/-----BEGIN PGP PUBLIC KEY BLOCK-----/ && !/-----END PGP PUBLIC KEY BLOCK-----/) {print | "fold -w 64"} else print }' flathub-key-long.asc > flathub-key.as

Still same error. So that seems complicated and an uphill battle. Even if someone wanted do this is, that currently does not seem possible.

I don't think after downloading flathub.flatpakrepo there is any way to verify the key fingerprint?

---

Solution 2: Provide a detached gpg signature.

• repofile: https://flathub.org/repo/flathub.flatpakrepo
• signature: https://flathub.org/repo/flathub.flatpakrepo.asc

---

Solution 3: Allow specification of the long gpg fingerprint on the command line.

Something like this:

flatpak remote-add --fingerprint 0000000000000000000000000000000000000000 --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Then flatpak could use a setting in /etc/flatpak which makes --fingerprint mandatory.

---

Solution 4: Hardcode the gpg key fingerprint or TLS certificate fingerprint.

At least for Flathub it would be good if the gpg fingerprint and/or TLS certificate fingerprint for flathub.org would be hardcoded so that certificate authorities cannot mess with it.

`hide-hardware-info.service`: hide `/sys/kernel/notes` due to accidental pointer leaks on xen systems. Leak defeats KASLR

Looks like an upstream bug caused a leak of sensitive data inside this file on Xen systems. A kernel patch is on the way to fix it but it may be a long time before it's in stable Debian.
File permissions are 444.

https://lwn.net/Articles/962782/
https://lore.kernel.org/linux-hardening/202402180028.6DB512C50@keescook/

For example, the startup_xen is built at 0xffffffff82465180 and
commit_creds is built at 0xffffffff810ad570 which could read from
the /boot/System.map. And the loaded address of startup_xen is
0xffffffffbc265180 which read from /sys/kernel/notes. So the loaded
address of commit_creds is 0xffffffffbc265180 - (0xffffffff82465180

• 0xffffffff810ad570) = 0xffffffffbaead570.

I've cc: the hardening list on this, I'm sure the developers there have
opinions about this.

Oh eww, why is Xen spewing addresses into the notes section? (This must
be how it finds its entry point? But that would be before relocations
happen...)

But yes, I can confirm that relocations are done against the .notes
section at boot, so the addresses exposed in .notes is an immediate
KASLR offset exposure.

Wayland Default DE for Real Security

As the title says. I think whonix maintainers in the forum have discarded the idea of moving back to kde too quickly. Moreover, I find most all of the arguments to be for the most part unfounded. KDE being bloated or heavy for Whonix is just not true. KDE used to be 'heavier' when both Qubes and Whonix were using it. It is now much more optimized. Xorg is unironically massively more bloated than wayland. All the 'bloat' is not part of the DE. We do not have to install everything. Just install the shell and we are done.

And I want to make this clear, I propose we only install the shell. Not even the terminal, not the file manager, nothing from the debian repositories but the shell, and let me explain why. But before that, I want to recap once again why xfce severly slows whonix down.

• Xfce is now officially the only 'major' DE that does not have a plan to switch to wayland for good. They say they would try stuff, but that's it. It is not even certain that they will switch at all. Even Cinnamon has given a date now. Budgie, Mate, they are all switching, they have plans, they have dates. Stuff like Lxqt are already almost completely switched. Xfce is an outlier here. And this is expected. They for some reason agreed not to use wlroots or libmutter. That means they kinda have to develop their own compositor, which we all know is not possible with the little funding Xfce has. If they do not decide to suddenly base on wlroots, Xfce will never have wayland.
• Xfce is lags behind, massively. On everything. The desktop looks really, really, but I mean really outdated. Normally this is not as important but you have to keep in mind, compelling to the average user is something you probably want.
• It is really a shame whonix still unironically ships with xorg as default.
• The only reason this is still just passable is whonix designed to be run on a VM. But Kicksecure is planned to be a regular distro. That means, xorg gotta go, really. True and real.
• Xfce is small. You tell on the Whonix website that you base on Debian, and one of the reasons for that is that there is a good chance in 10 years Debian is still going to be around. Do you know what not might be around in 10 years? Xfce. And by 'might', I mean they won't definetely be around, if they don't catch the pace in switching to wayland.

So at the very least, before I make the argument for KDE, we should all more or less agree on this: Xfce bad. At least for security.

Now my argument for KDE.

• KDE e.V. is a well-established and well-funded non-profit organization based in Germany. They are not some random project.
• KDE is customizable. It is fast. It is optimized. It can be as simple and minimalistic, if not more minimalistic, than xfce on demand.
• KDE has a well functioning wayland compositor. Which is to be the default.
• KDE provides almost all of their software as flatpaks. I know this might not mean much to you. But this is the reason why I suggested we install the shell from the debian repository and literally stop there. For everything else KDE, let's use the flatpak. Cut out the middle man. Get our software directly from KDE developers as they intend. Much faster bug and security fixes. It is also possible to vastly increase the flatpak sandboxing provided by bubblewrap with some overrides. The file manager, the terminal, the literally everything, as a flatpak. This is the only case I would support flatpaks. Because we get the software directly from the developers, and we get bubblewrap default. Can be further hardened too. Want a secure system? It won't get more secure than getting your software directly from the developer with all the security fixes, in a sandboxed environment. (This clause is optional of course)

Switching to flatpak defaults would normally be a seperate suggestion of mine, but yeah consider that extra. Getting the latest KeePassXC officially from the developers or getting the latest Thunderbird officially and directly from Mozilla is a huge leap in security. Of course I trust the debian team to do the packaging well and port security issues. But they can't be as good at porting security fixing than directly having them fixed from the developers. Can't be as fast. Anyway this is a seperate topic, for now disregard. Only consider what relates KDE.

`proc-hidepid.service`: Fixing Systemd related issues

This is the script I use to prevent failures on startup when using proc-hidepid.service

I've had this configuration running for over a year now on a server host system, and a slew of server VMs. This is not tested on desktop systems.

sudo groupadd proc
mkdir -p /etc/systemd/system/proc-hidepid.service.d/
echo "[Service]
ExecStart=/bin/mount -o remount,nosuid,nodev,noexec,hidepid=2,gid=proc /proc
" > /etc/systemd/system/proc-hidepid.service.d/override.conf
 
mkdir -p /etc/systemd/system/systemd-logind.service.d/
echo "[Service]
SupplementaryGroups=proc" > /etc/systemd/system/systemd-logind.service.d/override.conf

mkdir -p /etc/systemd/system/[email protected]/
echo "[Service]
SupplementaryGroups=proc" > /etc/systemd/system/[email protected]/override.conf

Issues caused without this configuration, and said fixes, are mentioned here:
systemd/systemd#12955

I am unaware of exactly what security impact this may have, but it stops services from failing when booting.

Kicksecure Default Browser Discussion

I think it should be considered to move applicaiton specific hardening to its own repository.

Even if this happens or not, consider firefox as the default browser. Hardening might seem like a big undertaking, but it's not. There is a more maintainable way to harden mozilla applications, and that is to set policies. This allows more than just setting preferences. There are many useful macros to disable studies and/or telemetry. Ping and crash reports can also be disabled within the policy easily with preferences. To demonstrate the possibility of control and also the ease of maintainability, I want to present the following policy I created for firefox:

{
  "policies": {
    "Bookmarks": [
      {
        "Title": "Kicksecure",
        "URL": "https://kicksecure.com",
        "Favicon": "https://www.kicksecure.com/favicon.ico",
        "Placement": "toolbar",
        "Folder": "Kicksecure"
      }
    ],
    "DisableFeedbackCommands": true,
    "DisableFirefoxAccounts": true,
    "DisableTelemetry": true,
    "DisableFirefoxStudies": true,
    "DisableFormHistory": true,
    "DisablePocket": true,
    "DisableSystemAddonUpdate": false,
    
    "EncryptedMediaExtensions": {
      "Enabled": false,
      "Locked": false
    },

    "ExtensionSettings": {
      "[email protected]": {
        "installation_mode": "force_installed",
        "install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
      }
    },
    
    "ExtensionUpdate": true,
    "FirefoxHome": {
      "SponsoredTopSites": false,
      "SponsoredPocket": false,
      "Locked": true
    },
    "FirefoxSuggest": {
      "SponsoredSuggestions": false,
      "ImproveSuggest": false,
      "Locked": true
    },
   
    "PasswordManagerEnabled": false,

    "PDFjs": {
      "Enabled": false,
      "EnablePermissions": false
    },
    
    "Preferences": {
      "browser.contentblocking.category": {
        "Value": "strict",
        "Status": "locked"
      }
    },
    
    "PromptForDownloadLocation": true,
    
    "SearchEngines": {
      "Default": "DuckDuckGo",
      "PreventInstalls": true,
      "Remove": ["Google", "Amazon"]
    },
    
    "SearchSuggestEnabled": false,
    
    "StartDownloadsInTempDirectory": true,
    
    "UserMessaging": {
      "WhatsNew": false,
      "ExtensionRecommendations": false,
      "FeatureRecommendations": false,
      "UrlbarInterventions": false,
      "SkipOnboarding": false,
      "MoreFromMozilla": false,
      "Locked": true
    }
  }
}

What is done:

• Remove all sponsor junk
• Remove telemetry
• Remove studies
• Force install ublock origin and lock it
• Enable ETP in strict mode and lock it
• Remove mozilla recommending and shilling random stuff
• Disable scripting and permissions for pdf viewer
• Kicksecure default bookmark
• Privacy respectin search engine
• Disable drm
• And some other stuff, more can be added, possibilities are limitless

For this vast amount of settings, I would agree the policy file is very intuitive and human readable and brief and maintainable. It is also very solid, it provides more possibilites than just global preferences for firefox. We can control addons and stuff. A similar policy file can be maintained also for thunderbird. Kicksecure can lock security related settings this way too, like enforcing strong cipher, ssl etc. settings and locking them.

Locking settings results in this: the user can't change the setting in the browser, not in settings, not in about:config, nowhere, it is locked. Disabling the policy is the only way to get rid of our defaults, if we wish so.

Now, I already have some several suggestions for policies for firefox and thunderbird. I guarantee you they are all human understandable and reasonably brief to maintain. I suggest having a separate repository for ease.

I already suggest, we reconsider the default applications Kicksecure ships. My comments:

• Thunderbird - Already good, should stay
• Firefox - Should be included (doubles as a secure pdf viewer)
• Hexchat - Thunderbird has IRC, so why have this. Also, IRC is not common place, shipping a default application seems superfluous.
• Bitcoin - Ok, understandable, maybe, niche, but passable
• Electron - Superfluous since btc core is already present
• Monero - Passable, I guess, but not necessary, like bitcoin
• VLC - good, vital component for daily usage, should stay
• Some Office - Unsurprisingly, an office suite is probably more seeked by an average user than hexchat

harden modules load broken

Using "normal" (default settings) kernel. Not VM kernel.

sudo journalctl -u harden-module-loading.service

Nov 05 22:44:57 host systemd[1]: Starting harden-module-loading.service - Disable the loading of modules to the kernel after startup. 
Nov 05 22:44:57 host disable-kernel-module-loading[4406]: kernel.modules_disabled = 1
Nov 05 22:44:57 host disable-kernel-module-loading[4404]: The loading of new modules to the kernel has been disabled by security-misc
Nov 05 22:44:57 host systemd[1]: harden-module-loading.service: Deactivated successfully.
Nov 05 22:44:57 host systemd[1]: Finished harden-module-loading.service - Disable the loading of modules to the kernel after startup.

Ok, so it says it's done. But this contradicts it:

cat /proc/sys/kernel/modules_disabled                                       

0

sysctl kernel.modules_disabled

kernel.modules_disabled = 0

But maybe sysctl only looks at configs, not at actual kernel values.

cannot mount options harden separate /home volume?

Like if the user has a seperate /home volume, we can't harden it with our custom systemd unit. I think the reason behind this is, systemd dynamically overrides our unit with the unit it auto generates from fstab on startup.

Originally posted by @monsieuremre in #157 (comment)

Hardening file permissions

Hardening file permissions and removing suid bits from binaries are quite different tasks. Handling them in the same service is not optimal because on of the two is significantly simple and breaks nothing. That is file permissions. These two functionalities have to be seperated.

Manually removing suid bits essentially is not optimal because we would have to maintain a long whitelist. This has no place here. This can be implemented in the apparmor-profiles-everything repo by removing the set_suid capability from the init profile and having seperate profiles for all suid applications. These can be ported from https://github.com/roddhjav/apparmor.d.

When it comes to file permission hardneing, the following hardening options should be applied upon install and be reverted on uninstall:

    # Restrict access to compilers from user account to prevent creation of malicious binaries
    # Even if they are not there. When they are installed in the future, these will apply, because of the override.
    dpkg-statoverride --add --update root root 0700 /usr/bin/as
    dpkg-statoverride --add --update root root 0700 /usr/bin/g++
    dpkg-statoverride --add --update root root 0700 /usr/bin/gcc
    dpkg-statoverride --add --update root root 0700 /usr/bin/cc
    dpkg-statoverride --add --update root root 0700 /usr/bin/clang

    # Protect config files and cron
    dpkg-statoverride --add --update root root 0400 /etc/cups/cupsd.conf
    dpkg-statoverride --add --update root root 0600 /boot/grub/grub.cfg
    dpkg-statoverride --add --update root root 0600 /etc/syslog.conf
    dpkg-statoverride --add --update root root 0700 /root/.ssh
    dpkg-statoverride --add --update root root 0600 /etc/crontab
    dpkg-statoverride --add --update root root 0700 /etc/cron.d
    dpkg-statoverride --add --update root root 0700 /etc/cron.daily
    dpkg-statoverride --add --update root root 0700 /etc/sudoers.d
    dpkg-statoverride --add --update root root 0700 /etc/cron.hourly
    dpkg-statoverride --add --update root root 0700 /etc/cron.weekly
    dpkg-statoverride --add --update root root 0700 /etc/cron.monthly

    # Make sure CISOfy recommended options are applied to the following
    dpkg-statoverride --add --update root root 0644 /etc/group
    dpkg-statoverride --add --update root root 0644 /etc/group-
    dpkg-statoverride --add --update root root 0644 /etc/hosts.allow
    dpkg-statoverride --add --update root root 0644 /etc/hosts.deny
    dpkg-statoverride --add --update root root 0644 /etc/issue
    dpkg-statoverride --add --update root root 0644 /etc/issue.net
    dpkg-statoverride --add --update root root 0644 /etc/motd
    dpkg-statoverride --add --update root root 0644 /etc/passwd
    dpkg-statoverride --add --update root root 0644 /etc/passwd-

    # Protect root, boot, home
    dpkg-statoverride --add --update root root 0700 /root
    dpkg-statoverride --add --update root root 0700 /boot
    dpkg-statoverride --add --update root root 0755 /home

   # Each users home directory to himself
    for user in $(ls /home); do
        if [ "$user" != "lost+found" ]; then
            dpkg-statoverride --add --update $user $user 0700 /home/$user
        fi
    done

    # To not leak information
    dpkg-statoverride --add --update root root 0700 /usr/lib/modules
    dpkg-statoverride --add --update root root 0700 /usr/src
    dpkg-statoverride --add --update root root 0700 /lib/modules

As I said, this is to be done upon install. No daemon or service is needed. We will revert these on uninstall.

Backport Firmware and Kernel | Protect against spectre/meltdown and various hardware vulnurabilities

Ding dong. First and the biggest problem with Debian: package freezing. On some other distros like Fedora, developers are aware of the security implications of freezing packages. Thats why fedora freezes packages, but they don't freeze the kernel, and they don't freeze firmware.

Debian freezes firmware updates between point releases. Ouch. This is supposedly for 'testing'. But this more of a joke really. Because what are you testing? What are you going to do, it is non-free to begin with. Like, there is no point.

My solution: let's port these from sid, by default. I know it is not recommended to make 'FrankenDebian' or whatever, but we already are distromorphing, this is only just the kernel, which is the most backported thing in the universe. The counter argument here can be: oh no the debian security team does not give priority to sid. And this argument would be very moot, because the debian security team does not give any priority to non-free firmware on any of their distros at all, anyway. They just don't do anything. But they still freeze it still, for some reason.

And for the kernel, we really don't need the debian security team to do them security patches. The upstream kernel maintainers are the ones that recognize the security issues and fix them in the first place anyway. And since we are going to get the latest stable release, we are still going to be way faster to receive security updates, along with other bug fixes, which might also impact security, despite not receiving a CVE. All bugs are bad, and can be used against the user. Only patching CVE's is not the best approach, especially for the kernel.

Backport the kernel, backport the firmware. I will go ahead and raise you a more radical solution. It does not take a super genius to compile a kernel. It does not take a genius to write a pipeline to compile the kernel. A buildservice can also be used. The more radical solution is, we do our own kernel. We, as in actually you the maintainer, and not we the user. We won't do any complicated patches that would require review before compile. Just gonna compile with the hardened sysctl defaults, include the non free firmware, sign them all with kicksecure keys, and ship them in a deb package. I tell you. You want big security, this is big security, without having to change the base repo. If you don't trust yourself to maintain this, let's just packport these. Let's go. Waiting for counter arguments if any.

`hide-hardware-info.service`: hide `/proc/dynamic_debug/`

This is a file I would normally expect to be restricted by kernel.dmesg_restrict = 1 yet I can still read it on my system. Leaks hardware info, kernel module info.

Permissions of this file /proc/dynamic_debug/control are 644.

See also:
https://www.kernel.org/doc/html/v4.12/admin-guide/dynamic-debug-howto.html

`Depends:` vs `Recommends:` vs none

• libpam-tmpdir
  • #147
• usbguard
  • #166

Do we really need Depends:? This makes it difficult to remove the package for users.

Perhaps Recommends: is sufficient? Not ideal.

Or nothing.

Why? Because security-misc shouldn't be attempting to be a Linux distribution such as Kicksecure that installs by a number of pre-installed applications.

references:

• https://github.com/Kicksecure/kicksecure-meta-packages
• https://github.com/Kicksecure/kicksecure-meta-packages/debian/control

disable enforcement of user being in group sudo

Since we have modified home_folder_access_rights_lockdown to work for all users with all usernames all the time, I don't see any reason to require the user to have a user user in the sudo group. This rule is still enforced on package install. This could and should be removed I think. Is there any other reason to keep this condition that I do not know of?

Originally posted by @monsieuremre in #136 (comment)

`remount-secure`: use `procfs` mount option `subset` (`hide-hardware-info.service`)

But for sensitive proc, I think I found a better way. We can modify the mount options. Procfs has the mount option subset. We can set this to the subsets that we want to be available. If we set the option subset=pid, then pid is visible to everyone (the default), but everything else invisible, including /proc/dma /proc/consoles /proc/cmdline /proc/iomem and like a billion other things you can check them with ls /proc. I know for a fact that hiding memory access and device stuff and kernel arguments is good and does not break anything. i am not sure what can be hidden here without breakage, but I will test and find out the optimal mount options for proc.

Originally posted by @monsieuremre in #172 (comment)

usrmerge

• https://wiki.debian.org/UsrMerge
• https://packages.debian.org/UsrMerge

It's a done deal. Most distributions going for this. Not a big deal for Kicksecure. Just moving around a few files to a different location.

systemd-coredump

In response to

• #151

How to even re-enable coredumps as of now?
Is this implemented in debug-misc?

I don't want to configure us into a corner and then when somebody asks how to re-enable functionality, nobody knows the answer and it's a major effort to re-enable it.

Maybe not worth disabling coredumps anyhow.

Why not use systemd-coredump from packages.debian.org instead?
See this short and nice article on how to use that:
https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-tuning-systemd-coredump.html

Seems pretty sanely implemented at first sight. Core dumps are to be found in this folder:
/var/lib/systemd/coredump/

We could leave coredumps enabled by default, harden the permissions of that folder to read access only by root using permission-hardener (if that is possible without breaking systemd-coredump) and then call it a day.

See also /usr/lib/sysctl.d/50-coredump.conf after installing the systemd-coredump package.

cat /usr/lib/sysctl.d/50-coredump.conf | grep --invert-match "#"

kernel.core_pattern=|/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h
kernel.core_pipe_limit=16
fs.suid_dumpable=2

---

https://www.freedesktop.org/software/systemd/man/latest/systemd-coredump.html

pam-tmpdir-helper breaks certain initramfs-update actions on systems with noexec on the /tmp mount

The Bug

Initramfs related bootscripts may not add all dependencies needed for a system to boot when it's build directory has the noexec flag.

On Kicksecure systems still running initramfs or systems with initramfs-update installed, the pam-tmpdir-helper option being used for the root user will move the environment's tmp directory into /tmp/user/$UID using the TMPDIR variable.

If the noexec flag is also not set for /tmp, this violates assumptions in mkinitramfs related scripts, and may prevent boot, per mkinitramfs (9)

The given directory should be on a filesystem which allows the execution of files stored there, i.e. should not be mounted with the noexec mount option.

Environments Impacted

Environments using keyscripts to unlock LUKS volumes at bootup may be impacted.

The decrypt_keyctl keyscript, a default keyscript available in cryptsetup-initramfs, is used to unlock several LUKS volumes at the same time with the same password. When this keyscript is used, the keyscript itself is added to the initramfs by /etc/crypttab related hooks, although not all dependencies are added until the later initramfs build process.

The correct dependencies are then added by another script, which runs during the initramfs build. The cryptkeyctl script checks if the decrypt_keyctl script is present and executable in the temporary build directory that mkinitramfs uses.

update-initramfs:

Calling hook cryptkeyctl
+ PREREQ=cryptroot
+ . /usr/share/initramfs-tools/hook-functions
+ [ ! -x /tmp/user/0/mkinitramfs_LhQz6c/lib/cryptsetup/scripts/decrypt_keyctl ]
+ exit 0

Reproduction Instructions

1. Ensure /tmp has noexec set.
2. Ensure that /etc/pam.d/common-session contains session option pam_tmpdir.so per the recent security-misc patch.
3. In your /etc/crypttab, add this option: keyscript=decrypt_keyctl so it appears as below:

#<target>    <source>    <keyfile>        <options>
sda_crypt   /dev/sda2   main_data_raid   luks,discard,keyscript=decrypt_keyctl

4. Run update-initramfs
5. Reboot

You will get errors about missing dependencies to store the key in the kernel keystore using keyctl. The system will fail to boot since it attempts to pass an 0-byte password to cryptsetup.

Control test:

For a control test, follow the same instructions, but ensure that noexec is NOT set for /tmp.
The volume should unlock normally on reboot.

Causes

The default build directory without pam-tmpdir-helper would otherwise be /var/tmp, which would otherwise be executable.

This is activated by /etc/pam.d/common-session, using the session option pam_tmpdir.so line. I believe the dependency on libpam-tmpdir creates this line per commit 8e66a41, and the function that adds this is called via /usr/share/pam-configs/tmpdir in https://packages.debian.org/sid/amd64/libpam-tmpdir/filelist

I am unsure if this issue impacts dracut systems. Dracut seems to use a customizable temporary directory as well, but I have not studied how hook scripts function, or if they even do function.

Fixes?

I will attempt this workaround to exclude the root user:
https://serverfault.com/a/755956
edit: This does not appear to be functioning for session type modules.

Workaround:
Change the script to check if the file exists and contains greater than zero bytes with the -s flag.

if  [ ! -s "$DESTDIR/lib/cryptsetup/scripts/decrypt_keyctl" ]; then
        exit 0
fi

References

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062756
https://cryptsetup-team.pages.debian.net/cryptsetup/README.keyctl.html
https://manpages.debian.org/bookworm/initramfs-tools-core/mkinitramfs.8.en.html

run permission-hardener after APT package installation

To ensure newly installed SUID are promptly disabled.

Split the `security-misc` into `security-misc-shared`, `security-misc-desktop` and `security-misc-server`

Servers and workstations differ heavily, and there is no universal hardening that is also fine grained for both. A server is inherently a network. This package should prioritize workstations, as kicksecure is meant to be one. I do not support the idea of also being a server system. Firstly, some of hardening already eliminates the possibilty of kicksecure usage on specific server types, like a file sync or an email server might already face problems because of network hardening. They may have gone unnoticed, but this doesn't change the fact. The two reasonable options are:

• Primarily good option: Forget about servers, do not try to keep support for them universally. This strips us of a very very big area of possible hardening options. If we want to support both, in terms of security, we will be the "jack of all trades, master of none". Nothing would be hardened to its full extend in this case.
• Secondary, in my opinion the least favorable option, because of the unnecessary work it would require: Split this package in two. One package security-misc-desktop and one security-misc-server. At this point you can choose any other name you like.

But this has to be addressed in the near future, for the project to develop further.

running WINE with capabilities

https://github.com/Whonix/security-misc/blob/71ae6239168d829e25670ffa856ee0f011a168a9/etc/sysctl.d/30_security-misc.conf#L52-L58

I think you need to be careful that ptrace use is tightly restricted by other means (e.g. AppArmor), as otherwise the suggested setup is always one vulnerability short of giving wineserver and wine-preloader unrestricted root powers.
A related question is if WINE was written with capabilities in mind at all.

Proposing openSUSE as a security-focused base operating system for Kicksecure and by extension Whonix

I don't know if this is the right place for this, but I did not find any repository that is more suitable to open such an issue.

First and foremost, I have read the whonix wiki and how you people evaluate operating systems and what do you expect from them. OpenSUSE is not on the list. I want it to be considered for the following grounds:

• The openSUSE project is community driven and it is not for profit.
• The project has been around for 20 years and is well established and recognized and has many eyeballs on itself.
• I propose specifically openSUSE Tumbleweed. One of the most important points is: it rolls. And dare I say: it is also rock stable. It is fast to provide the newest microcode updates without any delay, unlike debian, so that users have the current protections. Everything is tested before release but no package freezing takes place. All the benefits of having a rolling distro + all the benefits of being stable. Need I say more?
• Zypper, the package manager used in openSUSE uses gpg verification for everything by default. All openSUSE packages are also reproducable.
• SUSE is one of the rare distros that make security a priority. Built from latest kernel releases, compiled with the latest Spectre / Meltdown mitigation patches, with firewall and strong security policies turned on by default, your security is covered out-of-the-box.
• openSUSE uses YaST. The most powerful installation and configuration tool ever. Kicksecure maintaining a secure installation configuration is way easier. Most anything can be maintained by just maintaining a file. See next point.
• Hardening file permissions is a piece of cake. Just add a custom file under /etc/permissions.d/ and apply changes. Zypper makes sure these permissions are applied at each package upgrade/install, no configuration needed, just put the file. SUSE even comes with various profiles to choose from, which would be helpful for Kicksecure to derive its own secure profile.
• SUID/GUID hardening is by extension also a piece of cake. But wait: they already ship the least amount of SUID's in the first place.

SUSE only sets the SUID/SGID bit on binary if it is really necessary.

• Anything and everything installation: that is partitions and their mounting options and their hardening settings. What repositories we set or services or anything firewall or anything ever really. We can export the installation configuration to a single file. Importing this file results in the very same installation in all aspects.
• One of the few distros that actually comes with a firewall active and preconfigured for security. We can further lock this down, of course.
• The security team actively works to harden systemd services and lock them down. See here.
• Comes with AppArmor pre-enabled and several profiles enforcing. Adding profiles is easy. This provides easy compatibility for Whonix's own profiles.
• openSUSE allows easily defining privileges in a more fine-grained way. See here.
• Plasma Desktop from KDE is the default workspace on openSUSE. SUSE's team actively fix bugs on KDE and the two projects have a good relationship. Having KDE means having wayland and pipewire. This means an infinetely more secure system.
• Creating a fork can be done via KIWI, the openSUSE Build Service or via your own build process.
• They provide helpful documentation as to how to create a fork and a trademark guideline.

Version logic broken in old 40-kernel-hardening.conf

My initial kernel version was a Debian-bullseye 5.10.4x.

and older 40-kernel-hardening.conf in /etc/default/grub.d directory is giving me “poison”settings despite the “is kernel older than 5.4” logic.

Pretty sure that the logic is doing non-numeric comparison or the kernel version retrieval is borked.

automatic trigger of permission-hardener after APT package installation broken

https://github.com/Kicksecure/security-misc/blob/master/debian/security-misc.triggers

interest-await /usr
interest-await /opt

symptom:

Setting up helper-scripts (3:22.1-1) ...
Processing triggers for man-db (2.11.2-2) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  security-misc -> security-misc
 packages' pending triggers which are or may be unresolvable:
  security-misc: /usr
dpkg: error processing package security-misc (--configure):
 triggers looping, abandoned
Errors were encountered while processing:
 security-misc

Force IOMMU

I noticed that IOMMU settings right now is on instead of forced_isolation on AMD. Is there a reason why we are not forcing it? I don't see the on option for AMD CPUs documented anywhere.

qfile-unpacker permission-hardener whitelist security issue

Originally posted here: #162

@monsieuremre

The Qubes vulnurability ticket. The package that causes the vulnurability to escelate privileges to root,

reference:

• QubesOS/qubes-issues#8633

Important to point out it the impact:

• Only applies to Qubes because binary qfile-unpacker is only a thing in Qubes. It's part of qubes-core-agent Debian package. Nobody installs this on plain Debian or Kicksecure ("non-Qubes Kicksecure"). It's unavailable from packages.debian.org. Only Qubes Templates have qfile-unpacker installed by default.

This issue would not be resolved by porting to another base distribution - if this is also to be made available as a Template for Qubes. The only options are to not whitelist qfile-unpacker or to fix the issue at the root by patching Qubes.

At time of writing by Qubes default (what presumably most usess use), this does not matter much because Qubes enabled passwordless sudo by default. So this only applies to users having at least "basic" sudo hardening or maybe systemd units under different user accounts (without access to passwordless sudo). References:

• https://www.qubes-os.org/doc/vm-sudo/
• QubesOS/qubes-issues#2695

is whitelisted in our hand written service.

https://github.com/Kicksecure/security-misc/blob/master/etc/permission-hardening.d/25_default_whitelist_qubes.conf

sgid (set-group-ID) pkexec to fix hidepid

So basically, I have this one but I gotta say. While we are at it, let's hide pid too. Our workaround solution is not good enough because like things with pkexec don't work. I see. Users under the group proc are exempt from our hardening. So like, why don't we just set group id for the pkexec binary. We will set the group id as proc for pkexec (or anything at all that might break). Like Stuid and setgid are not cool security wise, but we are sgid'ing to group rpoc, which is non root, only proc privileges. So worst case some program that uses pkexec may elevate privileges to get access to prov (literally requires vulnerability in the os), which still would be like, no issue because thats basically what we have as of now. Did you consider this? Has this been tried.

Originally posted by @monsieuremre in #172 (comment)

Various Improvement Options

Disabling bluetooth is a bold choice. But if we are concerned about even breaking some random apps when remounting, we should also be concerned about making the system unusable for ordinary people. We can set bluetooth configurations in a way that it starts turned off on boot, it uses private addresses and times out on discoverability. We can also make a systemd service to automatically turn off bluetooth when there are no devices connected for 10 minutes. This is implemented for example in graphene os.

Usb-hardening. We can harden the usage of usb devices with usb-guard. By default blocking everything and whitelisting what was plugged in in the time of install can be a choice. But if we don't want to be that extreme, we can just manually reject some stuff and allow others. For example, as I implemented in my script, the following:

allow with-interface equals { 08:*:* } # Allow usb devices with mass storage interface
reject with-interface all-of { 08:*:* 03:00:* } # These have both storage and keyboard. Suspicious.
reject with-interface all-of { 08:*:* 03:01:* }

This would for example protect from what is reviewed in this video.

Disabling x11 all together, including via xwayland. This requires, of course, the user being on wayland already. For this I suppose, kicksecure and whonix should first make the move to drop x11. Using wayland also means using pipewire, which much better. This option depends on external factors tho, so this is more of an idea only.

I think I can implement these things, considering they are rather simple solutions, If they should be of interest for the maintainers of this repo.

test remount-secure script and systemd unit

Developer discussion. Not for users since not the in the testers repository yet.

Based suggestions in #202 thanks to @monsieuremre, recently I have improved.

• systemd unit file: https://github.com/Kicksecure/security-misc/blob/master/usr/lib/systemd/system/remount-secure.service
• remount-secure script: https://github.com/Kicksecure/security-misc/blob/master/usr/bin/remount-secure

Enabling it should be as simple as:

sudo systemctl enable remount-secure.service

Risks: Breaking the boot.

Unbreaking the boot?

• A) Booting into recovery mode and disalbing the systemd unit or,
• B) kernel parameter remountsecure=0

might work.

why kick secure uses frozen release cycle distribution debian instead of fedora or arch linux.

frozen release cycle distributions often don’t update package versions and fall behind on security updates.

For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer. Some security fixes do not receive a CVE (particularly less popular software) at all and therefore do not make it into the distribution with this patching model. As a result minor security fixes are sometimes held back until the next major release.

Debian is worst in handling security i wish kicksecure was based on fedora or arch linux.

improve hide-hardware-info.service, make `/sys` hiding optional

A systemd service restricts /proc/cpuinfo, /proc/bus, /proc/scsi and /sys to the root user. This hides a lot of hardware identifiers from unprivileged users and increases security as /sys exposes a lot of information that shouldn't be accessible to unprivileged users. As this will break many things, it is disabled by default and can optionally be enabled by executing systemctl enable hide-hardware-info.service as root.

Ok.

Although not tested, I am almost 100% sure practically all the breakage is caused by restricting /sys. My recommendation is, we leave this one out. Add /proc/kallsyms to the list as well, as this contains all the memory addresses for each kernel symbol. And enable what we already have, restricting the sub-directories under proc.

Should I follow with the respective pull?

Hide Proc | New Approach

An optional systemd service mounts /proc with hidepid=2 at boot to prevent users from seeing another user's processes. This is >disabled by default because it is incompatible with pkexec. It can be enabled by executing systemctl enable proc-hidepid.service as root.

This not only breaks pkexec but breaks a lot of other thing as well and requires manually adding some services into groups that are exepmted from the policy. What we should do is, instead of hidepid=2, we set hidepid=4.

hidepid=ptraceable or hidepid=4 means that procfs should only contain /proc// directories that the caller can ptrace.

So basically root processes can access other users stuff, because they can ptrace the processes anyway. But non privileged users/processes are limited. This is a massive improvement from not hiding anything.

I did some little testing on Debian on Gnome Wayland and it does not seem to break anything, for now.

I suggest we go with this option. massive leap without breakage. This option is also somewhat new. There used to be only 0, 1 and 2. 4 seems to be added recently (in a relative sense).

We would need no service for this. We could just remount it the good old way in the secure remount thing. I can add this to the branch, that might get merged as the new secure mounting solution.

Scope of application-specific hardening?

#146 (which looks nice at first sight) and 1500 AppArmor profiles (impressive scope) woke me up to set the expectations straight for application-specific hardening.

How many applications should be hardened through this repository?

Maybe best to limit security-misc to "global" / "system" wide hardening, have a separate repository for application specific hardening?

Or I could arbitrarily limit the applications to those pre-installed in Kicksecure, Whonix and perhaps some other popular/important applications (even more arbitrary).

However, ~1500 pull requests for all sorts of applications hardening I've never used and reviewing the details of this with DOS the development so this isn't possible.

These expectations need to be set straight in the readme to respect contributor's time.

For a hypothetical ~1500 application hardening settings a separate repository would need to be maintained by somebody else.

why remount-secure even needed? fix insecure mount options at the root, not here

Which software / source code sets the initial insecure mount options anyhow?

Could we fix it there instead of adding a band-aid on top?

Unable to disable dccp , ticp , rds and other blacklisted modules in Arch Linux

i added rules to disable them in a security.conf inside /etc/modprobe.d/ folder and in /etc/mkinitcpio.conf added line FILES=(/etc/modprobe.d/security.conf) and ran sudo mkinitcpio -P and then rebooted system and verified output using lynis which showed rds , dccp , sctp , ticp not disabled.

the contents of security.conf was copied from https://github.com/Kicksecure/security-misc/blob/master/etc/modprobe.d/30_security-misc.conf