ParrotOS hardening

So.distro has to be more secure than advertised.We havent taken many steps towards that so i’ll go first with some ideas.
We can have security-misc package from Whonix pre-installed.
Quoting from its stable features below,giving various resources as well:

enhances misc security settings

Inspired by Kernel Self Protection Project (KSPP)

Implements most if not all recommended Linux kernel settings (sysctl) and kernel parameters by KSPP.

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

kernel hardening:

deactivates Netfilter's connection tracking helper Netfilter's connection tracking helper module increases kernel attack surface by enabling superfluous functionality such as IRC parsing in the kernel. (!) Hence, this package disables this feature by shipping the /etc/modprobe.d/30_nf_conntrack_helper_disable.conf configuration file.

Kernel symbols in various files in /proc are hidden as they can be very useful for kernel exploits.

Kexec is disabled as it can be used to load a malicious kernel. /etc/sysctl.d/30_security-misc.conf

ASLR effectiveness for mmap is increased.

The TCP/IP stack is hardened by disabling ICMP redirect acceptance, ICMP redirect sending and source routing to prevent man-in-the-middle attacks, ignoring all ICMP requests, enabling TCP syncookies to prevent SYN flood attacks, enabling RFC1337 to protect against time-wait assassination attacks and enabling reverse path filtering to prevent IP spoofing and mitigate vulnerabilities such as CVE-2019-14899.

Avoids unintentional writes to attacker-controlled files.

Prevents symlink/hardlink TOCTOU races.

SACK can be disabled as it is commonly exploited and is rarely used by uncommenting settings in file /etc/sysctl.d/30_security-misc.conf.

Slab merging is disabled as sometimes a slab can be used in a vulnerable way which an attacker can exploit.

Sanity checks and redzoning are enabled.

Memory zeroing at allocation and free time is enabled.

Machine checks (MCE) are disabled which makes the kernel panic on uncorrectable errors in ECC memory that could be exploited.

Kernel Page Table Isolation is enabled to mitigate Meltdown and increase KASLR effectiveness.

Enables all mitigations for CPU vulnerabilities and disables SMT.

A systemd service clears System.map on boot as these contain kernel symbols that could be useful to an attacker. /etc/kernel/postinst.d/30_remove-system-map /lib/systemd/system/remove-system-map.service /usr/lib/security-misc/remove-system.map

Coredumps are disabled as they may contain important information such as encryption keys or passwords. /etc/security/limits.d/30_security-misc.conf /etc/sysctl.d/30_security-misc.conf /lib/systemd/coredump.conf.d/30_security-misc.conf

The thunderbolt and firewire kernel modules are blacklisted as they can be used for DMA (Direct Memory Access) attacks.

IOMMU is enabled with a boot parameter to prevent DMA attacks.

Bluetooth is blacklisted to reduce attack surface. Bluetooth also has a history of security concerns. https://en.wikipedia.org/wiki/Bluetooth#History_of_security_concerns

A systemd service restricts /proc/cpuinfo, /proc/bus, /proc/scsi and /sys to the root user only. 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 running systemctl enable hide-hardware-info.service as root. /usr/lib/security-misc/hide-hardware-info /lib/systemd/system/hide-hardware-info.service /lib/systemd/system/user@.service.d/sysfs.conf /etc/hide-hardware-info.d/30_default.conf

The MSR kernel module is blacklisted to prevent CPU MSRs from being abused to write to arbitrary memory.

Vsyscalls are disabled as they are obsolete, are at fixed addresses and are a target for ROP.

Page allocator freelist randomization is enabled.

The vivid kernel module is blacklisted as it's only required for testing and has been the cause of multiple vulnerabilities.

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.

The kernel panics on oopses to prevent it from continuing to run a flawed process and to deter brute forcing.

Restricts the SysRq key so it can only be used for shutdowns and the Secure Attention Key.

Restricts loading line disciplines to CAP_SYS_MODULE.

Improve Entropy Collection

Load jitterentropy_rng kernel module. /usr/lib/modules-load.d/30_security-misc.conf

Distrusts the CPU for initial entropy at boot as it is not possible to audit, may contain weaknesses or a backdoor.

https://en.wikipedia.org/wiki/RDRAND#Reception

https://twitter.com/pid_eins/status/1149649806056280069

For more references, see:

/etc/default/grub.d/40_distrust_cpu.cfg

Uncommon network protocols are blacklisted: These are rarely used and may have unknown vulnerabilities. /etc/modprobe.d/uncommon-network-protocols.conf The network protocols that are blacklisted are:

DCCP - Datagram Congestion Control Protocol
SCTP - Stream Control Transmission Protocol
RDS - Reliable Datagram Sockets
TIPC - Transparent Inter-process Communication
HDLC - High-Level Data Link Control
AX25 - Amateur X.25
NetRom
X25
ROSE
DECnet
Econet
af_802154 - IEEE 802.15.4
IPX - Internetwork Packet Exchange
AppleTalk
PSNAP - Subnetwork Access Protocol
p8023 - Novell raw IEEE 802.3
p8022 - IEEE 802.2

user restrictions:

remount /home, /tmp, /dev/shm and /run with nosuid,nodev (default) and noexec (opt-in). To disable this, run "sudo touch /etc/remount-disable". To opt-in noexec, run "sudo touch /etc/noexec" and reboot (easiest). Alternatively file /usr/local/etc/remount-disable or file /usr/local/etc/noexec could be used. /lib/systemd/system/remount-secure.service /usr/lib/security-misc/remount-secure

A systemd service mounts /proc with hidepid=2 at boot to prevent users from seeing each other's processes.

The kernel logs are restricted to root only.

The BPF JIT compiler is restricted to the root user and is hardened.

The ptrace system call is restricted to the root user only.

restricts access to the root account:

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 to make above work so login as a user in a virtual console is still possible. debian/security-misc.postinst

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

Logging into the root account from a virtual, serial, whatnot console is prevented by shipping an existing and empty /etc/securetty. (Deletion of /etc/securetty has a different effect.) /etc/securetty.security-misc

Console Lockdown. Allow members of group 'console' to use console. Everyone else except members of group 'console-unrestricted' are restricted from using console using ancient, unpopular login methods such as using /bin/login over networks, which might be exploitable. (CVE-2001-0797) Using pam_access. Not enabled by default in this package since this package does not know which users shall be added to group 'console' and would break console. /usr/share/pam-configs/console-lockdown-security-misc /etc/security/access-security-misc.conf

Protect Linux user accounts against brute force attacks. Lock user accounts after 50 failed login attempts using pam_tally2. /usr/share/pam-configs/tally2-security-misc

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.
/usr/share/pam-configs/tally2-security-misc
/usr/lib/security-misc/pam_tally2-info
/usr/lib/security-misc/pam-abort-on-locked-password

access rights restrictions:

Strong Linux User Account Separation. Removes read, write and execute access for others for all users who have home folders under folder /home by running for example "chmod o-rwx /home/user" during package installation, upgrade or pam mkhomedir. This will be done only once per folder in folder /home so users who wish to relax file permissions are free to do so. This is to protect previously created files in user home folder which were previously created with lax file permissions prior installation of this package. debian/security-misc.postinst /usr/lib/security-misc/permission-lockdown /usr/share/pam-configs/mkhomedir-security-misc

SUID / GUID removal and permission hardening. A systemd service removed SUID / GUID from non-essential binaries as these are often used in privilege escalation attacks. It is disabled by default for now during testing and can optionally be enabled by running systemctl enable permission-hardening.service as root. https://forums.whonix.org/t/disable-suid-binaries/7706 /usr/lib/security-misc/permission-hardening /lib/systemd/system/permission-hardening.service /etc/permission-hardening.d/30_default.conf

access rights relaxations:

Redirect calls for pkexec to lxqt-sudo because pkexec is incompatible with hidepid. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860040 https://forums.whonix.org/t/cannot-use-pkexec/8129 /usr/bin/pkexec.security-misc

This package does (not yet) automatically lock the root account password. It is not clear that would be sane in such a package. It is recommended to lock and expire the root account.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 resuce and emergency shell. This is the same solution that Debian will likely addapt for Debian installer. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211 Adverse security effects can be prevented by setting up BIOS password protection, grub password protection and/or full disk encryption. /etc/systemd/system/emergency.service.d/override.conf /etc/systemd/system/rescue.service.d/override.conf

Disables TCP Time Stamps:

TCP time stamps (RFC 1323) allow for tracking clock information with millisecond resolution. This may or may not allow an attacker to learn information about the system clock at such a resolution, depending on various issues such as network lag. This information is available to anyone who monitors the network somewhere between the attacked system and the destination server. It may allow an attacker to find out how long a given system has been running, and to distinguish several systems running behind NAT and using the same IP address. It might also allow one to look for clocks that match an expected value to find the public IP used by a user.

Hence, this package disables this feature by shipping the /etc/sysctl.d/30_security-misc.conf configuration file.

Note that TCP time stamps normally have some usefulness. They are needed for:

the TCP protection against wrapped sequence numbers; however, to trigger a wrap, one needs to send roughly 2^32 packets in one minute: as said in RFC 1700, "The current recommended default time to live (TTL) for the Internet Protocol (IP) [45,105] is 64". So, this probably won't be a practical problem in the context of Anonymity Distributions.
"Round-Trip Time Measurement", which is only useful when the user manages to saturate their connection. When using Anonymity Distributions, probably the limiting factor for transmission speed is rarely the capacity of the user connection.

Application specific hardening:

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.
Enables punycode (network.IDN_show_punycode) by default in Thunderbird to make phising attacks more difficult. Fixing URL not showing real Domain Name (Homograph attack).

Testing and experimental features from the package are described here https://www.whonix.org/wiki/Security-misc#Testing_Features.
NTPSec could be preinstalled as NTPClassic is very insecure.Insecure time synchronizatioin and time leaks makes the user vulnerable to various advanced deanonymization attacks.
The folowing link describes the differences of NTPSec and NTPClassic and why NTPSec is a more secure alternative.We must keep in mind though that the ‘sec’ in NTPSec refers to the security of the code and not in the security of the protocol itself.NTP is a plaintext protocol open to manipulation and man in the middle attacks.Another easier solution is to disable any NTP client and use something like this https://gitlab.com/madaidan/secure-time-sync.
For time attacks protection in general both IPV4and IPV6 timestamps must be disabled and that can be done with the sysctl option net.ipv4.tcp_timestamps = 0.Also any ncoming ICMP requests should be blocked with either iptables or ufw,Furthermore TCP Initial Sequence numbers mitigatioin must be achieved.Quoting from Whonix:

An artificially induced CPU-load temperature influences the timer crystal and skews its frequency. TCP ISNs are a permanent feature and are necessary from a security standpoint to prevent arbitrary TCP connection hijacking by non-global network adversaries. (https://blog.patternsinthevoid.net/cve-2016-5696-and-its-.effects-on-tor.html) See the following reference about removing the timer output function from Linux’s TCP ISN code.(http://sec.cs.ucl.ac.uk/users/smurdoch/talks/eurobsdcon07hotornot.pdf) TCP ISN CPU Information Leak Protection - tirdad [archive]

For application-level mitigation clearnet traffic must be avoided. Without clock information leaking, network adversaries do not have non-anonymous timestamp sources to match this data with.

Last but not least i recommend the pre-installation maybe of LKRG(Linux Runtime Kernel Guard).LKRG is a kernel module that perfroms runtime integrity checking of the Linux kernel.To quote the official webpage of the project:

LKRG performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. As controversial as this concept is, LKRG attempts to post -detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials such as user IDs of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant access (such as open a file) based on the unauthorized credentials.

LKRG defeats many pre-existing exploits of Linux kernel vulnerabilities, and will likely defeat many future exploits (including of yet unknown vulnerabilities) that do not specifically attempt to bypass LKRG. While LKRG is bypassable by design , such bypasses tend to require more complicated and/or less reliable exploits.

LKRG also provides security through diversity , much like running an uncommon OS kernel would, yet without the usability drawbacks of actually running an uncommon OS. As free LKRG becomes somewhat popular and maybe a target of some exploits, we might introduce paid LKRG Pro as a means to fund the project and provide further diversity (with Pro’s smaller userbase being beneficial), extra and specialized functionality, and maybe distro-specific binary builds.

Like any software, LKRG may contain bugs and some of those might even be new security vulnerabilities. You need to weigh the benefits vs. risks of using LKRG, considering that LKRG is most useful on systems that realistically, despite of this being a best practice for security, won’t be promptly rebooted into new kernels (nor live-patched) whenever a new kernel vulnerability is discovered.

LKRG is currently in an experimental stage. We expect occasional false positives (integrity violations and/or exploits detected when there aren’t ones). LKRG’s current default response to kernel integrity violations is merely reporting those in kernel messages (which obviously doesn’t mitigate real attacks), but LKRG may be configured to panic the kernel instead. LKRG’s current response to unauthorized process credentials is killing the process (which does defeat many exploits, but is a rather mild response nevertheless). LKRG’s default response is changing as LKRG becomes more mature. In fact, current LKRG will by default panic the kernel if it finds SMEP (Supervisor Mode Execution Protection, a security feature of recent CPUs) unexpectedly disabled. We dare to do this because we reasonably expect no false positives with that specific LKRG feature.

To illustrate LKRG’s exploit detection capabilities, in our testing on vulnerable distro kernels LKRG successfully detected certain pre-existing exploits of CVE-2014-9322 (BadIRET), CVE-2017-5123 (waitid(2) missing access_ok), CVE-2017-6074 (use-after-free in DCCP protocol). However, it wouldn’t be expected to detect exploits of CVE-2016-5195 (Dirty COW) since those directly target the userspace even if via the kernel. While in case of Dirty COW the LKRG “bypass” happened due to the nature of the bug and this being the way to exploit it, it’s also a way for future exploits to bypass LKRG by similarly directly targeting userspace. It remains to be seen whether such exploits become common (unlikely unless LKRG or similar become popular?) and what (negative?) effect on their reliability this will have (for kernel vulnerabilities where directly targeting the userspace isn’t essential and possibly not straightforward).

A brief and nice introduction can be found on Whonix wiki as well: https://www.whonix.org/wiki/Linux_Kernel_Runtime_Guard_LKRG
Comment for discussion on the above and make a new topic for other ideas.
P.S.:All of the above have been thoroughly tessted by me for a long time and i had no issues.

4 Likes

Everything looks cool so far, but there are few things I would worry about:

This is a very sharp decision. Many users use bluetooth for different purposes, like bluetooth speakers, mouses, keyboards, and other pieces of hardware.
Although bluetooth had many critical flaws, their core recommendations always admonish how to resist. Like the KNOB vulnerability which had a place on all bluetooth chips 1.0 to 5.1, core specs now say “enforce a minimum encryption key length of 7 octets for BR/EDR connections”.
It’s better to accurately follow the recommendations and not to cut the technology.

Looks neat, but the project is run by one man, who has a fulltime job. I’m not saying his project is bad, moreover I had some similar ideas with Protecred Features he was talking about (old users remember my posts) https://www.youtube.com/watch?v=tOiPM692DOM.
It is a hard move to include anything at the kernel level, but we may help him, or collaborate w\ LKRG development in the future.

security-misc upstream maintainer here.

This shouldn’t be a blocker, though. It’s this config snippet:

If you decide to use security-misc, this could be patched out or shipping a lexical higher config snippet which nullifies this (dunno yet if modprobe.d supports that).

I will also discuss your feedback upstream. Was always wondering if we’d need two more packages. security-misc-vm (where blocking bluetooth makes sense) and security-paranoid (more experimental, more likely breaking things, probably non-default, optionally installed package).

2 Likes

If security-misc-vm then a host only security-0misc-host should be made where just some modules will not be blocked imho.
security-paranoid sounds good especially for tersters.

Bluetooth blocking is not a problem.As @adrelanos said it is just a snippet and we can easily remove it.As for LKRG There are a lot of discussions on its mailing list and lot of feedback.

@palinuro thoughts?
IMO we should test this out

1 Like

Will the access restrictions to root via changes to the /etc/pam.d/common-auth file mess up my settings (yubikey)

my common-auth file:

# Use this to use both your password + Yubikey. You can comment this line if you want to JUST use your Yubikey (NOT RECCOMENDED)
auth required pam_unix.so nullok_secure try_first_pass

# The line below is required to be able to use your Yubikey
auth   [success=1 new_authtok_reqd=ok default=die ignore=ignore]   pam_yubico.so mode=challenge-response 

# Default rules
auth   requisite         pam_deny.so
auth   required         pam_permit.so
auth   optional         pam_ecryptfs.so unwrap
auth   optional         pam_cap.so

I dont quite get what you mean.But if you are asking if the script will change your file iirc it wont. @adrelanos(the author) will know better.

1 Like

It does PAM configuration modifications.

https://github.com/Whonix/security-misc/tree/master/usr/share/pam-configs

These are documented in readme.

https://github.com/Whonix/security-misc/blob/master/README.md

1 Like

Thank you @disrupt_the_flow, and @adrelanos,
I was worried I might get locked out of sudo.

I noticed in todays update the below. I’ll check those documents!
I’ve got a new router, woohoo, so be a little tied up with that.

Setting up libpam-systemd:amd64 (244.3-1) ...
pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
pam-auth-update: Run pam-auth-update --force to override.

from /etc/pam.d/common-auth

# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

Translation for users: add your modifications either below that quote in that file or at the very bottom. If possible.

Also in any case - although a bit more difficult - “mostly” - it seems much more solid to use the “API” in /usr/share/pam-configs to make PAM config modification rather than writing into /etc/pam.d folder directly.

I would also like to point out that such issues are more likely to happen when installing security-misc on an already installed operating system such as Debian. When first installing Kicksecure and then having the user make modifications, such issues are less likely.

At the moment Kicksecure (security-misc is only a part of Kicksecure) is only available as downloadable VM images and for installation with apt-get. The plan however is to provide a Kicksecure ISO. Users who will later install Kicksecure using ISO (Calamares) installer will have less issues of that kind. (Since then PAM is pre-configured and what users add won’t cause conflicts - unless security-misc PAM will be further modified/hardened.)

In any cases, you could also consider to re-base on Kicksecure than “only” use security-misc.

1 Like
1 Like

I personally think this is must need, but we need to maintain some standard , like CIS benchmark or something else, like as we do for our tools.

Example Links:
https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html


https://nvd.nist.gov/ncp/checklist/887

Yes I see and that would be a nice idea. But as there are many many resources on how to harden your system writing our own doc does not have to be a priority.

Yes, Absolutely, We need to make a list for Common things to do, for security,home and arm version.

A to-do list would be nice sure. But first let us contribute ideas and then we can decide what we can implement or not. Right now our only to-do is hardening the distribution.