hardened desktop

[orionbelt]

I have a desktop system running usual desktop stuff, and also occasionally compiling and running some CPU-intensive stuff. It would be nice to have some of the extra security afforded by the hardened project while keeping the degradation in ease of compilation and performance down to a minimum. The most recent discussions that i could find on this topic date 4 or 5 years back, so i thought i'd seek recent opinions about what might be a good compromise.

I don't think that i, and perhaps most desktop users, would want to go as far as mandatory access control, as it's probably a bit too annoying, especially considering the ever-changing desktop usage patterns. PaX sounds great, but from what i am reading i am getting the impression that quite a few ebuilds would give up, or at least start coughing, at least up to some years ago. In this respect, i think that the hardened project basically protects from attacks originating from the internet, and the main ways in which my desktop is exposed to the internet is via firefox and sshd, and intermittently via vsftpd and lighttpd when i fire them up for some brief period of time. It would be nice if programs such as these could be built with PaX etc. enabled without bothering the rest of the system. However, my understanding is that this would require setting up a hardened toolchain separately, e.g. in a chroot environment, and also running a hardened kernel, and i am not sure whether a hardened kernel would be happy if the rest of the system was compiled without PaX & co. The concern is not just about compilation issues but also about slowing down the CPU-intensive stuff for no good reason, since it is not exposed to the outside world and so compiling it with PaX enabled would serve no purpose. However, i have no sense of how big of a slow-down that would be, and i wouldn't mind so much if it were less than a few percent or so.

I read that simply switching to a hardened profile, which activates the "hardened" and "a few other" USE flags still helps with security while causing minimum interference with package compilation and no noticeable performance degradation. However, a number of flags that are enabled in desktop profiles would then have to be enabled by hand and possibly by trial and error... Might it be better to stay on a desktop profile and simply add the "hardened" USE flag in make.conf instead? Would doing so add any useful security features to the system?

I would appreciate any thoughts and comments about the validity of my statements above, and of course any other suggestions that you may have.

[xanderal]

I would be very interested in this as well, especially concerning the following part:

I read that simply switching to a hardened profile, which activates the "hardened" and "a few other" USE flags still helps with security while causing minimum interference with package compilation and no noticeable performance degradation. However, a number of flags that are enabled in desktop profiles would then have to be enabled by hand and possibly by trial and error... Might it be better to stay on a desktop profile and simply add the "hardened" USE flag in make.conf instead? Would doing so add any useful security features to the system?

I would appreciate any thoughts and comments about the validity of my statements above, and of course any other suggestions that you may have.

[Phoenix591]

you can easily create your own profiles that combine multiple official profiles (and/or contain your own flags) by setting up a custom repository and looking at the profile wiki page,

what it boils down to is a profile folder with an eapi file and a parent file (and another file describing the arch to display the profile for and its dev status), with all the meat being in the parent file... an example

Code: Select all

gentoo:default/linux/amd64/17.1/desktop/plasma
gentoo:default/linux/amd64/17.1/hardened/selinux

this combines the 17.1 plasma profile with the selinux profile... another way that's equivalent (that combines the contents of several of the official profiles' parent files) is

Code: Select all

gentoo:default/linux/amd64/17.1
gentoo:targets/desktop/plasma
gentoo:features/hardened/amd64
gentoo:features/selinux

stuff lower on the list overrides stuff higher on the list, so you want to put important things like systemd and hardening/selinux on the bottom.

[depontius]

In addition, it's worth looking at Kees Cook's "Linux Kernel Self Protection Project". It's basically some kernel configuration settings that can help improve security a bit. (and a few entries for /etc/sysctl.conf) Not the old hardened-sources, but a useful step. Look at "Recommended Kernel Settings" on this page: https://kernsec.org/wiki/index.php/Kern ... on_Project

[maxxim]

In addition, it's worth looking at Kees Cook's "Linux Kernel Self Protection Project". It's basically some kernel configuration settings that can help improve security a bit. (and a few entries for /etc/sysctl.conf) Not the old hardened-sources, but a useful step. Look at "Recommended Kernel Settings" on this page: https://kernsec.org/wiki/index.php/Kern ... on_Project

There's a very nice utility to help with that:
https://github.com/a13xp0p0v/kconfig-hardened-check

It will provide an overview of options related to hardening and their current / advised settings:

Code: Select all

[+] Trying to detect architecture in "/usr/src/linux/.config"...
[+] Detected architecture: X86_64
[+] Trying to detect kernel version in "/usr/src/linux/.config"...
[+] Found version line: "# Linux/x86 5.4.48-gentoo Kernel Configuration"
[+] Detected kernel version: 5.4
[+] Checking "/usr/src/linux/.config" against X86_64 hardening preferences...
=========================================================================================================================
                 option name                 | desired val | decision |       reason       |   check result
=========================================================================================================================
CONFIG_INTEL_IOMMU                           |      y      |defconfig |  self_protection   |   FAIL: "is not set"
CONFIG_AMD_IOMMU                             |      y      |defconfig |  self_protection   |   OK
CONFIG_VMAP_STACK                            |      y      |defconfig |  self_protection   |   OK
CONFIG_RANDOMIZE_BASE                        |      y      |defconfig |  self_protection   |   OK
CONFIG_THREAD_INFO_IN_TASK                   |      y      |defconfig |  self_protection   |   OK
CONFIG_BUG_ON_DATA_CORRUPTION                |      y      |   kspp   |  self_protection   |   FAIL: "is not set"
CONFIG_DEBUG_WX                              |      y      |   kspp   |  self_protection   |   FAIL: "is not set"
CONFIG_SCHED_STACK_END_CHECK                 |      y      |   kspp   |  self_protection   |   FAIL: not found
CONFIG_SLAB_FREELIST_HARDENED                |      y      |   kspp   |  self_protection   |   FAIL: "is not set"
CONFIG_SLAB_FREELIST_RANDOM                  |      y      |   kspp   |  self_protection   |   FAIL: "is not set"
CONFIG_SHUFFLE_PAGE_ALLOCATOR                |      y      |   kspp   |  self_protection   |   FAIL: "is not set"
CONFIG_FORTIFY_SOURCE                        |      y      |   kspp   |  self_protection   |   OK
CONFIG_DEBUG_LIST                            |      y      |   kspp   |  self_protection   |   FAIL: not found
[...]

[pietinger]

There's a very nice utility to help with that:
https://github.com/a13xp0p0v/kconfig-hardened-check

Great Link ! Thanks a lot !
(I just have copied it into my german installation guide)

[sdauth]

There's a very nice utility to help with that:
https://github.com/a13xp0p0v/kconfig-hardened-check

Great Link ! Thanks a lot !
(I just have copied it into my german installation guide)

Indeed. Thanks maxxim, very handy.

[maxxim]

You're welcome.

You might be interested in this script I created, it checks kernel configs using the utility mentioned above and a second (somewhat simpler) one:
https://gist.github.com/fonic/9af8deaae ... 7bde7b530a

[maxxim]

I think it's worth mentioning that one should be careful when hardening kernel configurations. Some of the settings may result in an unbootable system as they require additional tasks to be performed (e.g. CONFIG_SECURITY_LOADPIN*, CONFIG_SECURITY_LOCKDOWN_LSM*, CONFIG_MODULE_SIG*).

Thus, one should make sure to:
- backup the current kernel configuration before hardening
- backup the current kernel image before hardening

Also, there are some settings that may reduce performance significantly (e.g. CONFIG_DEBUG_VIRTUAL; not tested myself, judged by the help text).

To cut a long story short:
One should not blindly modify settings just because they are advised for hardening, always check their impact first.

[halcon]

maxxim,

I wish to thank you for that information as well. It's very useful for me as I have compiled custom kernels for years, consulting mainly cateee.net.

they require additional tasks to be performed (e.g. CONFIG_SECURITY_LOADPIN*, CONFIG_SECURITY_LOCKDOWN_LSM*, CONFIG_MODULE_SIG*).

may reduce performance significantly (e.g. CONFIG_DEBUG_VIRTUAL; not tested myself, judged by the help text).

One should not blindly modify settings just because they are advised for hardening, always check their impact first.

I have already understood that a13xp0p0v's list is not for blind copying by more obvious symbols:

CONFIG_MODULES - should be disabled on servers, but can't be disabled on desktops (AFAIK)
CONFIG_HIBERNATION - hardly makes sense to disable it on laptops
CONFIG_IA32_EMULATION/CONFIG_X86_X32 - possible to disable it on non-multilib only? not sure
CONFIG_FB - when disabled, can make "beautiful" console not possible (and reduce X capabilities too, on some hardware, AFAIK)

It would be very interesting to see an analysis of all those symbols, made more in the context of hardening desktop than on cateee.net, and in one place.

[maxxim]

I have already understood that a13xp0p0v's list is not for blind copying by more obvious symbols:

CONFIG_MODULES - should be disabled on servers, but can't be disabled on desktops (AFAIK)
CONFIG_HIBERNATION - hardly makes sense to disable it on laptops
CONFIG_IA32_EMULATION/CONFIG_X86_X32 - possible to disable it on non-multilib only? not sure
CONFIG_FB - when disabled, can make "beautiful" console not possible (and reduce X capabilities too, on some hardware, AFAIK)

Exactly, most desktop users likely want to keep those enabled.

It would be very interesting to see an analysis of all those symbols, made more in the context of hardening desktop than on cateee.net, and in one place.

I can at least tell you what I did on my desktops. I applied everything kconfig-hardened-check advises except the following (with explanations):

Code: Select all

[+] Trying to detect architecture in "/usr/src/linux/.config"...
[+] Detected architecture: X86_64
[+] Trying to detect kernel version in "/usr/src/linux/.config"...
[+] Found version line: "# Linux/x86 5.4.48-gentoo Kernel Configuration"
[+] Detected kernel version: 5.4
[+] Checking "/usr/src/linux/.config" against X86_64 hardening preferences...
=========================================================================================================================
                 option name                 | desired val | decision |       reason       |   check result
=========================================================================================================================
CONFIG_SYN_COOKIES                           |      y      |defconfig |  self_protection   |   FAIL: "is not set"
-> has lots of drawbacks, also my router handles SYN-flooding; more suited for servers to prevent DoS
CONFIG_DEBUG_VIRTUAL                         |      y      |  clipos  |  self_protection   |   FAIL: "is not set"
-> presumably high performance impact (judging from help text)
CONFIG_SECURITY_LOCKDOWN_LSM                 |      y      |  clipos  |  security_policy   |   FAIL: "is not set"
-> not working for me, prevents module loading; maybe just needs some userspace changes, not sure yet
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY           |      y      |  clipos  |  security_policy   |   FAIL: not found
-> same as above
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY|      y      |  clipos  |  security_policy   |   FAIL: not found
-> same as above
CONFIG_SECURITY_LOADPIN                      |      y      |    my    |  security_policy   |   FAIL: "is not set"
-> not working for me due to initramfs, should be working fine for systems that don't use initramfs/initrd
CONFIG_SECURITY_LOADPIN_ENFORCE              |      y      |    my    |  security_policy   |   FAIL: CONFIG_SECURITY_LOADPIN is needed
-> same as above
CONFIG_HIBERNATION                           | is not set  |   kspp   | cut_attack_surface |   FAIL: "y"
-> I want to use hibernation, also not a security issue for me due to encrypted swap
CONFIG_IA32_EMULATION                        | is not set  |   kspp   | cut_attack_surface |   FAIL: "y"
-> I want to be able to run 32 bit apps
CONFIG_MODULES                               | is not set  |   kspp   | cut_attack_surface |   FAIL: "y"
-> I need module support for out-of-tree modules like nvidia, vbox, etc.
CONFIG_FB                                    | is not set  |maintainer| cut_attack_surface |   FAIL: "y"
-> I like my beautiful framebuffer console :)
CONFIG_VT                                    | is not set  |maintainer| cut_attack_surface |   FAIL: "y"
-> I'd say you would never want to disable this on desktops, only on headless servers
CONFIG_ACPI_TABLE_UPGRADE                    | is not set  | lockdown | cut_attack_surface |   FAIL: "y"
-> not sure yet if I need this or not
CONFIG_X86_MSR                               | is not set  |  clipos  | cut_attack_surface |   FAIL: "y"
-> presumably required for userspace apps that need to query CPU features, not sure yet
CONFIG_X86_CPUID                             | is not set  |  clipos  | cut_attack_surface |   FAIL: "y"
-> same as above
CONFIG_AIO                                   | is not set  |grapheneos| cut_attack_surface |   FAIL: "y"
-> not sure yet if I need this or not

Also, if one wants to use CONFIG_MODULE_SIG* in combination with out-of-tree modules, you'll need something to perform the signing, e.g. https://gist.github.com/fonic/a8842f562 ... 80554d95ee

[halcon]

Thank you, maxxim, for sharing your expirience!

I am going to compile a new kernel when 5.8 is stabilized (where some bugs actual for my AMD machines are fixed). Meanwhile, I note everything down

[Hu]

CONFIG_MODULES - should be disabled on servers, but can't be disabled on desktops (AFAIK)

Module support can be disabled on desktops. If module support is disabled, then everything required to operate the system must be built into the kernel, including any firmware required at driver initialization time. I think proprietary drivers are also blocked if module support is disabled, since those are built as modules.

CONFIG_HIBERNATION - hardly makes sense to disable it on laptops

It can also be useful on desktops, if you have an Uninterruptible Power Supply, but sometimes experience power outages longer than the UPS battery can cover. In those cases, putting the system into hibernation can be used as an alternative to shutting down when the battery gets low.

CONFIG_IA32_EMULATION/CONFIG_X86_X32 - possible to disable it on non-multilib only? not sure

IA32 is required to build some multilib targets, and in practice should be enabled for any multilib system. It is of limited value on non-multilib, but might still be used if an x86 chroot was present. X86_X32 is an experimental alternate system that most people will not use.

[maxxim]

I got a question regarding userspace hardening. I created a custom profile with these parents:

Code: Select all

gentoo:default/linux/amd64/17.1/desktop/plasma
gentoo:default/linux/amd64/17.1/hardened

But I'm puzzled by the USE flag choices. /var/db/repos/gentoo/profiles/features/hardened/make.defaults contains this:

Code: Select all

# Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> (2011-11-16)
# Rename STAGE1_USE to BOOTSTRAP_USE and stack it to the parent value
BOOTSTRAP_USE="${BOOTSTRAP_USE} hardened pic xtpax -jit -orc"

USE="hardened pic xtpax -jit -orc"

# Ian Stakenvicius, 2014-09-03
# Set a variable just to indicate that the current profile is a hardened one
# This variable can be leveraged in ebuilds for pkg_postinst messages that
# indicate said package is, say, configured in a way that defeats the purpose
# of running hardened.
PROFILE_IS_HARDENED=1

# We set the default markings to none
PAX_MARKINGS="none"
USE="${USE} -ptpax"

# Default starting set of USE flags for all default/linux profiles.
# We unset them so we get a clean use flag profile.
USE="${USE} -berkdb -gdbm -tcpd"
USE="${USE} -fortran"
USE="${USE} -cli"
USE="${USE} -dri"

Does this mean that features jit and orc won't work at all or that they are not advised for hardening?
Does this mean that features berkdb, gdbm, tcpd, fortran, cli, dri won't work at all or that they are not advised for hardening?

[halcon]

Module support can be disabled on desktops. If module support is disabled, then everything required to operate the system must be built into the kernel, including any firmware required at driver initialization time. I think proprietary drivers are also blocked if module support is disabled, since those are built as modules.

I vaguely remember that some non-proprietary drivers refused to work when built-in either, and I had to make them modules... Do you think it was due to some my misconfiguration and all non-proprietary drivers can work correctly and without conflicts when built-in (on a multimedia-rich desktop)?

X86_X32 is an experimental alternate system that most people will not use.

Thanks! Noted down...

[Hu]

I am not aware of any free drivers that cannot work as builtin, but I know some of them require firmware to load onto the device and, if the driver is builtin, the firmware must also be builtin because it will be needed before the root filesystem is available. If you configured your kernel without knowing this rule, you could easily have created a non-working configuration. There is no build-time enforcement that you do the right thing.

I think jit is default-disabled because, historically, the hardened profile was commonly used by people who used hardened kernels, and hardened kernels tended to enforce restrictions that jit-using programs wanted to violate. In some cases, building a program with the ability to do jit would disable its ability to use non-jit, which would make it completely unusable on systems where kernel security rules prohibited use of jit. Now that grsecurity kernels are inconvenient to obtain, and thus not in widespread use in the community, the jit USE flag might be easier to reactivate.

I am not familiar with USE=orc, but looking at its description, it has effectively the same explanation as jit.

Usually, if a flag is broken, it should be disabled via a use.mask entry, rather than merely defaulted off.

[maxxim]

I am not aware of any free drivers that cannot work as builtin, but I know some of them require firmware to load onto the device and, if the driver is builtin, the firmware must also be builtin because it will be needed before the root filesystem is available. If you configured your kernel without knowing this rule, you could easily have created a non-working configuration. There is no build-time enforcement that you do the right thing.

Me neither, I've never encountered a driver that wouldn't work as built-in. My kernels for example have ALL drivers built in, the only modules I'm using belong to out-of-tree drivers (nvidia, virtualbox). I think it's worth mentioning that if you're using an initramfs/initrd, firmware files can also be put there instead of being built into the kernel image (that's the way I'm doing it).

I think jit is default-disabled because, historically, the hardened profile was commonly used by people who used hardened kernels, and hardened kernels tended to enforce restrictions that jit-using programs wanted to violate. In some cases, building a program with the ability to do jit would disable its ability to use non-jit, which would make it completely unusable on systems where kernel security rules prohibited use of jit. Now that grsecurity kernels are inconvenient to obtain, and thus not in widespread use in the community, the jit USE flag might be easier to reactivate.

I am not familiar with USE=orc, but looking at its description, it has effectively the same explanation as jit.

Usually, if a flag is broken, it should be disabled via a use.mask entry, rather than merely defaulted off.

Thanks for that information. I did some research into the topic and I think the answer to userspace hardening is actually quite simple: don't use the hardened profiles at all. Everything in those profiles is specifically tailored to fit the sys-kernel/hardened-sources package, which no longer exists. Most of the settings applied by the profiles don't make sense when using sys-kernel/gentoo-sources. Also, the whole hardening project seems to have been been abandoned since 2017 when grsecurity patches became unavailable (which I was not aware of).

I analyzed the changes applied by profile default/linux/amd64/17.1/hardened compared to just default/linux/amd64/17.1/desktop/plasma (which I was using before):
- disables jit and orc due to PaX (1) -> does not apply to sys-kernel/gentoo-sources
- disables berkdb, gdbm, tcpd, fortran, cli, dri -> no real reason for that afaikt
- enables hardened, pie, ssp, xtpax -> of those, xtpax does not apply to sys-kernel/gentoo-sources

So it actually boils down to hardened, pie, ssp. Well, I can set those in make.conf and stay on my desktop profile and that's it.

Or did I get something wrong?

(1) https://wiki.gentoo.org/wiki/Hardened/F ... profile.3F

[halcon]

I am not aware of any free drivers that cannot work as builtin, but I know some of them require firmware to load onto the device and, if the driver is builtin, the firmware must also be builtin because it will be needed before the root filesystem is available. If you configured your kernel without knowing this rule, you could easily have created a non-working configuration. There is no build-time enforcement that you do the right thing.

May be, that was the point...

Me neither, I've never encountered a driver that wouldn't work as built-in. My kernels for example have ALL drivers built in, the only modules I'm using belong to out-of-tree drivers (nvidia, virtualbox). I think it's worth mentioning that if you're using an initramfs/initrd, firmware files can also be put there instead of being built into the kernel image (that's the way I'm doing it).

Yes, I use initrd. I used to make it automatically with

Code: Select all

cp /usr/src/linux/.config /usr/share/genkernel/arch/x86_64/kernel-config
genkernel ramdisk

Anyway, those cases of built-in drivers failing were long ago and I can't remember exact details... Thanks, good to know about the hints you both mentioned!

[maxxim]

There's a very nice utility to help with that:
https://github.com/a13xp0p0v/kconfig-hardened-check

FYI: I asked the developer to add options to reduce output to OK / FAIL items only. The request was fulfilled, which makes the tool even better (https://github.com/a13xp0p0v/kconfig-ha ... /issues/45)

Code: Select all

[+] Special report mode: show_fail
[+] Config file to check: /usr/src/linux/.config
[+] Detected architecture: X86_64
[+] Detected kernel version: 5.4
=========================================================================================================================
                 option name                 | desired val | decision |       reason       |   check result
=========================================================================================================================
CONFIG_SYN_COOKIES                           |      y      |defconfig |  self_protection   |   FAIL: "is not set"
CONFIG_DEBUG_VIRTUAL                         |      y      |  clipos  |  self_protection   |   FAIL: "is not set"
CONFIG_SECURITY_LOCKDOWN_LSM                 |      y      |  clipos  |  security_policy   |   FAIL: "is not set"
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY           |      y      |  clipos  |  security_policy   |   FAIL: not found
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY|      y      |  clipos  |  security_policy   |   FAIL: not found
CONFIG_SECURITY_LOADPIN                      |      y      |    my    |  security_policy   |   FAIL: "is not set"
CONFIG_SECURITY_LOADPIN_ENFORCE              |      y      |    my    |  security_policy   |   FAIL: CONFIG_SECURITY_LOADPIN is needed
CONFIG_HIBERNATION                           | is not set  |   kspp   | cut_attack_surface |   FAIL: "y"
CONFIG_IA32_EMULATION                        | is not set  |   kspp   | cut_attack_surface |   FAIL: "y"
CONFIG_MODULES                               | is not set  |   kspp   | cut_attack_surface |   FAIL: "y"
CONFIG_FB                                    | is not set  |maintainer| cut_attack_surface |   FAIL: "y"
CONFIG_VT                                    | is not set  |maintainer| cut_attack_surface |   FAIL: "y"
CONFIG_ACPI_TABLE_UPGRADE                    | is not set  | lockdown | cut_attack_surface |   FAIL: "y"
CONFIG_X86_MSR                               | is not set  |  clipos  | cut_attack_surface |   FAIL: "y"
CONFIG_X86_CPUID                             | is not set  |  clipos  | cut_attack_surface |   FAIL: "y"
CONFIG_AIO                                   | is not set  |grapheneos| cut_attack_surface |   FAIL: "y"

[+] Config check is finished: 'OK' - 120 (suppressed in output) / 'FAIL' - 16

[mv]

Has anybody written an ebuild for the tool? I am not going to execute pip on my system.

[fedeliallalinea]

Has anybody written an ebuild for the tool? I am not going to execute pip on my system.

In pentoo overlay

[mv]

Has anybody written an ebuild for the tool? I am not going to execute pip on my system.

In pentoo overlay

Thanks. Somehow I was not able to access the pentoo overlay (is it not git?). Instead of experimenting longer with it, I downloaded the ebuild from gpo.zugaina and added a slight modificatoin of it to the mv overaly.

I must say that some (in particular, the later) options are really paranoic and not for use in a desktop system, but most recommendations are useful (and indeed some I did not know yet).

I am wondering why it should be more secure to have IOMMU enabled than without. Can sombody explain this?

[CaptainBlood]

Has anybody written an ebuild for the tool? I am not going to execute pip on my system.

In pentoo overlay

Thks 4 ur attention, interest & support.

[Hu]

In theory, if your IOMMU is enabled and works, then devices can only use DMA to access areas the kernel pre-approved. Without an IOMMU, a device can use DMA to access any address it can express on the bus. This protects against several problems:

• Defective device firmware might read or write an address other than the one the kernel instructed it to use.
• A kernel driver might submit an incorrect address to the device (despite programming the IOMMU correctly). This seems very unlikely as an ordinary bug, but perhaps could happen as an unusual consequence of an exploit against the kernel.
• The device might deliberately read or write memory other than the kernel told it to use. This is unlikely for built-in devices, but could be a problem if someone with temporary physical access to the system can hotplug a malicious device and use it to dump RAM. In this case, the attacker's access is too brief to attack the device in more direct and invasive ways, such as rebooting to a LiveCD or stealing the device for later disassembly.

I think the last point is the one that caused this to be flagged as security relevant. While we often accept that an attacker with physical access can do anything to the device, an attacker who only enjoys a few minutes of physical access and who needs to leave minimal evidence of the attack cannot employ the most effective attacks.

[mv]

IOMMU

Thanks for the explanation.