security-misc: Enhance Miscellaneous Security Settings
Stable Features[edit]
system map[edit]
TODO: document
- https://forums.whonix.org/t/kernel-hardening/7296/84
- https://forums.whonix.org/t/remove-system-map-cannot-work-lib-modules-is-mounted-read-only/13324
Testing Features[edit]
Reduce Kernel Information Leaks[edit]
- Security Impact: There are many of hardware, kernel, debug information, etc. in
/sys
, which is especially problematic and has been the cause of many infoleaks such as kernel pointer leaks. - Privacy/Anonymity Impact: Details about your hardware can be used for identification.
- Threat: This information is per Debian (and probably most popular Linux distributions) available to attackers with local code execution privileges which includes,
- malicious applications collecting such information and submitting it to data collectors,
- as well as both, compromised non-privileged users and the privileged root user.
- Non-Threat: This information does not randomly leak to third parties on clean (non-compromised) machines through use of legitimate applications such as the APT package manager.
- Goal: This information should by default be unavailable to non-privileged users and untrusted root.
- Solution: Therefore security-misc includes the
hide-hardware-info.service
systemd unit.- Restricts access to
/sys
,/proc/cpuinfo
,/proc/bus
, and/proc/scsi
to the root user only. - This also hides most hardware identifiers.
- Restricts access to
- Status: This setting is disabled by default because it might break many applications. Testers-only! Call for testers and forum discussion: Restrict Hardware Information to Root - Testers Wanted!
- Enable: It can optionally be enabled by running the following command.
- sudo systemctl enable hide-hardware-info.service
- Reboot required.
- A whitelist that allows specific applications to access
/sys
and/proc/cpuinfo
is enabled by default to maintain basic functionality. [1] For example, this allows the launching of applications like XFCE.
- Limitations of Solution:
- Possible Future Enhancements: untrusted root
Whitelisting Applications[edit]
To whitelist applications, they must be run under the sysfs
group (if allowing access to /sys
) and/or the cpuinfo
group (if allowing access to /proc/cpuinfo
).
Remember that any whitelisted applications add to the attack surface. An attacker can attempt to exploit a vulnerability in the whitelisted application(s) to gain access to hardware information.
addgroup method[edit]
For example, to add user user
to group cpuinfo
, run the following command. (Note, this is weakening protections.)
For example, to add user user
to group sysfs
, run the following command. (Note, this is weakening protections.)
Re-login required after changing groups. Easiest: reboot. [3] [4]
For example, after reboot it would be possible to run the cpu-info
utility (from Debian package cpuinfo
).
systemd[edit]
For example, to run a systemd service as the sysfs
group, create a drop-in directory and add the following.
setgid method[edit]
To run a specific binary as the sysfs
group, the binary must be owned by the sysfs
group and be made setgid. To achieve this, change the ownership of the binary by running the following.
Then make the binary setgid.
The binary will now run with the permissions of the sysfs
group and have access to /sys
.
All of these steps can also be applied to the cpuinfo
group.
Disable the Whitelist[edit]
In order to reduce the attack surface as much as possible, optionally the whitelist can be disabled entirely.
Note that this setting will break many applications; for example, the desktop environment will not even start. Do not perform this action unless you understand the implications and can reverse the change.
1. Open file /etc/hide-hardware-info.d/50_user.conf
in an editor with root rights.
(Kicksecure ™ inside Qubes: In Template)
This box uses sudoedit
for better security. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Kicksecure ™, please refer to this link.
2. Add.
3. Save.
4. Done.
SUID Disabler and Permission Hardener[edit]
See SUID Disabler and Permission Hardener.
hidepid[edit]
TODO: document
sudo systemctl enable proc-hidepid.service
Experimental Features[edit]
Unreleased. (Developers only.) Will flow into other repositories as per usual.
Remount Secure[edit]
Feature not ready!
- https://forums.whonix.org/t/re-mount-home-and-other-with-noexec-and-nosuid-among-other-useful-mount-options-for-better-security/7707/27
- https://github.com/Kicksecure/security-misc/blob/master/lib/systemd/system/remount-secure.service
- https://github.com/Kicksecure/security-misc/blob/master/usr/libexec/security-misc/remount-secure
- Dev/remount-secure
Installation of security-misc[edit]
This chapter is only required for users which aren't users of Kicksecure ™ or its derivatives (such as Whonix ™). That is because security-misc is installed by default in Kicksecure ™ and Kicksecure ™ derivatives.
Prerequisites:
1. Essentials.
The user needs to verify that the following prerequisites are met.
- Debian
bullseye
installed. - User account
user
exists.
2. Gain administrative (root) rights. [5]
Becoming root is required because the following commands need to be run with administrative (root) rights as documented below. [6]
- A) Debian: Use
su
as documented below. - B) Most Qubes users: same as above.
- C) Advanced Qubes users: If using a Debian minimal template or not having the
passwordless-root
package installed, see footnote. [7]
Run the following command in a terminal.
3. Install sudo
and adduser package.
1. Update the package lists.
2. Upgrade the system.
3. Install sudo
and adduser package.
5. Create group console
.
6. Add user user
to group console
.
7. Add user user
to group sudo
.
Note:
- A) Most users: No special notice.
- B) Advanced users: If the user is intending to lockdown user
user
by not granting root rights, see footnote. [8]
8. Reboot.
1. Download the Signing Key.
2. Optional: Check the Signing Key for better security.
3. Add Kicksecure ™ signing key.
4. Kicksecure ™ APT repository choices.
Optional: See Kicksecure ™ Packages for Debian Hosts and Kicksecure ™ Host Enhancements instead of the next step for more secure and complex options.
5. Add Kicksecure ™ APT repository.
Install security-misc
.
Install security-misc
. To accomplish that, the following steps A. to D. need to be done.
A. Update the package lists.
B. Upgrade the system.
C. Install the security-misc
package.
Using apt
command line parameter --no-install-recommends
is in most cases optional.
D. Done.
The procedure of installing security-misc
is complete.
selinux[edit]
Community Support Only!: | |
---|---|
![]() |
|
- https://github.com/Kicksecure/security-misc/pull/100
- https://forums.whonix.org/t/restrict-hardware-information-to-root/7329/88
References[edit]
- ↑
https://github.com/Kicksecure/security-misc/-/blob/master/lib/systemd/system/user@.service.d/sysfs.conf
- ↑
- ↑
No reboot required: Use the execute command as different group ID command line utility
sg
to execute thecpu-info
(from Debian packagecpuinfo
) application under groupcpuinfo
.sg cpuinfo cpu-info - ↑
Also no reboot required:
sudo -u user bashcpu-infoOr.sudo -u user cpu-info
- ↑ One way or another.
- ↑
When a user is using
su
to gain administrative rights, the user is required to use full path to the programsaddgroup
,adduser
,reboot
because when usingsu
thePATH
environment variable is not adjusted for use with root rights. Seeecho "$PATH"
.echo "$PATH"user rightsPATH
printout:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
root rights
PATH
printout:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
By comparison, when using
sudo
using /full/path/to/application is not required. - ↑ A root terminal is required to proceed which can be started from Qubes dom0 terminal as per the Qubes upstream documentation. Unspecific to Kicksecure ™].
- ↑
The following command
/usr/sbin/adduser user sudo
grants root rights to useruser
. If the user intents to use useruser
without root rights for better security, the user should omit running the/usr/sbin/adduser user sudo
and instead, in case of:- Debian: Use
su
. - Kicksecure ™ for Qubes: If not installing the
passwordless-root
package and/or when distribution morphing a Debian minimal template into Kicksecure ™, root terminal is required to proceed which can be started from Qubes dom0 terminal as per the Qubes upstream documentation. Unspecific to Kicksecure ™].
- Debian: Use
Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.