security-misc: Enhance Miscellaneous Security Settings

From Kicksecure
Jump to navigation Jump to search

Securitymisc.jpg

Stable Features[edit]

Described here.

system map[edit]

TODO: document

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.
  • 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:
    • Attackers which gained root compromise and/or malicious/compromised whitelisted applications have access to this information.
    • Cannot hide CPUID. [2]
  • 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.)

sudo addgroup user cpuinfo

For example, to add user user to group sysfs, run the following command. (Note, this is weakening protections.)

sudo addgroup user sysfs

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).

cpu-info

systemd[edit]

For example, to run a systemd service as the sysfs group, create a drop-in directory and add the following.

[Service] SupplementaryGroups=sysfs

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.

sudo chgrp sysfs /path/to/binary

Then make the binary setgid.

sudo chmod g+s /path/to/binary

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.

warning Warning:

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.

sudoedit /etc/hide-hardware-info.d/50_user.conf

2. Add.

sysfs_whitelist=0 cpuinfo_whitelist=0

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!

sudo touch /etc/noexec

Installation of security-misc[edit]

Whonix / Kicksecure ™ default admin password is: changeme 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.

su

3. Install sudo and adduser package.

1. Update the package lists.

apt update

2. Upgrade the system.

apt full-upgrade

3. Install sudo and adduser package.

apt install --no-install-recommends sudo adduser

5. Create group console.

/usr/sbin/addgroup --system console

6. Add user user to group console.

/usr/sbin/adduser user 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]

/usr/sbin/adduser user sudo

8. Reboot.

/sbin/reboot

1. Download the Signing Key.

wget https://www.kicksecure.com/derivative.asc

2. Optional: Check the Signing Key for better security.

3. Add Kicksecure ™ signing key.

sudo cp derivative.asc /usr/share/keyrings/derivative.asc

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.

echo "deb [signed-by=/usr/share/keyrings/derivative.asc] https://deb.kicksecure.com bullseye main contrib non-free" | sudo tee /etc/apt/sources.list.d/derivative.list

Install security-misc.

Install security-misc. To accomplish that, the following steps A. to D. need to be done.

A. Update the package lists.

sudo apt update

B. Upgrade the system.

sudo apt full-upgrade

C. Install the security-misc package.

Using apt command line parameter --no-install-recommends is in most cases optional.

sudo apt install --no-install-recommends security-misc

D. Done.

The procedure of installing security-misc is complete.

selinux[edit]

Community Support Only!:
Info

Community Support Only means Kicksecure ™ developers are unlikely to provide free support for wiki chapters or pages with this tag. See Community Support for further information, including implications and possible alternatives.

References[edit]

  1. ↑ https://github.com/Kicksecure/security-misc/-/blob/master/lib/systemd/system/user@.service.d/sysfs.conf
  2. ↑
  3. ↑ No reboot required: Use the execute command as different group ID command line utility sg to execute the cpu-info (from Debian package cpuinfo) application under group cpuinfo.
    sg cpuinfo cpu-info
  4. ↑ Also no reboot required:
    sudo -u user bash
    cpu-info
    Or.
    sudo -u user cpu-info
  5. ↑ One way or another.
  6. ↑ When a user is using su to gain administrative rights, the user is required to use full path to the programs addgroup, adduser, reboot because when using su the PATH environment variable is not adjusted for use with root rights. See echo "$PATH".
    echo "$PATH"
    user rights PATH 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.

  7. ↑ A root terminal is required to proceed which can be started from Qubes dom0 terminal as per the Qubes upstream documentation. Unspecific to Kicksecure ™].
  8. ↑ The following command /usr/sbin/adduser user sudo grants root rights to user user. If the user intents to use user user 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 ™].


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.

Retrieved from "https://www.kicksecure.com/w/index.php?title=Security-misc&oldid=56450"