Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
hardened desktop
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
orionbelt
Apprentice
Apprentice


Joined: 05 Apr 2006
Posts: 171
Location: Brussels, Belgium

PostPosted: Thu Apr 18, 2019 5:27 pm    Post subject: hardened desktop Reply with quote

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.
Back to top
View user's profile Send private message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Tue May 21, 2019 11:43 am    Post subject: Re: hardened desktop Reply with quote

I would be very interested in this as well, especially concerning the following part:
orionbelt wrote:
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.
Back to top
View user's profile Send private message
Phoenix591
Guru
Guru


Joined: 17 Sep 2007
Posts: 373

PostPosted: Tue May 21, 2019 12:03 pm    Post subject: Reply with quote

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:

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:

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.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3456

PostPosted: Wed May 22, 2019 12:26 am    Post subject: Reply with quote

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/Kernel_Self_Protection_Project
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Sun Jul 12, 2020 2:07 pm    Post subject: Reply with quote

depontius wrote:
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/Kernel_Self_Protection_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:
[+] 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
[...]
Back to top
View user's profile Send private message
pietinger
l33t
l33t


Joined: 17 Oct 2006
Posts: 828
Location: Bavaria

PostPosted: Sun Jul 12, 2020 2:56 pm    Post subject: Reply with quote

maxxim wrote:
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) :-)
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 304
Location: Ásgarðr

PostPosted: Sun Jul 12, 2020 4:09 pm    Post subject: Reply with quote

pietinger wrote:
maxxim wrote:
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. 8)
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Sun Jul 12, 2020 8:03 pm    Post subject: Reply with quote

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/9af8deaae7b7297361fb137bde7b530a
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Mon Jul 13, 2020 8:50 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
halcon
Guru
Guru


Joined: 15 Dec 2019
Posts: 547

PostPosted: Mon Jul 13, 2020 1:51 pm    Post subject: Reply with quote

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.

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

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

maxxim wrote:
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.
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Mon Jul 13, 2020 3:19 pm    Post subject: Reply with quote

halcon wrote:

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.

halcon wrote:
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:
[+] 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/a8842f56289da24970979a80554d95ee


Last edited by maxxim on Tue Jul 14, 2020 9:47 am; edited 1 time in total
Back to top
View user's profile Send private message
halcon
Guru
Guru


Joined: 15 Dec 2019
Posts: 547

PostPosted: Mon Jul 13, 2020 7:04 pm    Post subject: Reply with quote

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 :)
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 17451

PostPosted: Tue Jul 14, 2020 4:03 am    Post subject: Reply with quote

halcon wrote:
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.
halcon wrote:
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.
halcon wrote:
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.
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Tue Jul 14, 2020 9:54 am    Post subject: Reply with quote

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

Code:
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:
# 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?
Back to top
View user's profile Send private message
halcon
Guru
Guru


Joined: 15 Dec 2019
Posts: 547

PostPosted: Tue Jul 14, 2020 12:23 pm    Post subject: Reply with quote

Hu wrote:
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)?

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

Thanks! Noted down...
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 17451

PostPosted: Wed Jul 15, 2020 12:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Wed Jul 15, 2020 8:49 am    Post subject: Reply with quote

Hu wrote:
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).

Quote:
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/FAQ#Why_is_the_jit_and_orc_flag_disabled_in_the_hardened_profile.3F
Back to top
View user's profile Send private message
halcon
Guru
Guru


Joined: 15 Dec 2019
Posts: 547

PostPosted: Wed Jul 15, 2020 10:42 am    Post subject: Reply with quote

Hu wrote:
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...

maxxim wrote:
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:
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!


Last edited by halcon on Wed Jul 15, 2020 4:42 pm; edited 2 times in total
Back to top
View user's profile Send private message
maxxim
n00b
n00b


Joined: 03 Feb 2015
Posts: 20

PostPosted: Wed Jul 15, 2020 3:22 pm    Post subject: Reply with quote

maxxim wrote:
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-hardened-check/issues/45)

Code:
[+] 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
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6485

PostPosted: Thu Jul 16, 2020 7:00 pm    Post subject: Reply with quote

Has anybody written an ebuild for the tool? I am not going to execute pip on my system.
Back to top
View user's profile Send private message
fedeliallalinea
Administrator
Administrator


Joined: 08 Mar 2003
Posts: 26715
Location: here

PostPosted: Thu Jul 16, 2020 7:02 pm    Post subject: Reply with quote

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

In pentoo overlay
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6485

PostPosted: Sat Jul 18, 2020 5:58 am    Post subject: Reply with quote

fedeliallalinea wrote:
Quote:
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?
Back to top
View user's profile Send private message
CaptainBlood
Advocate
Advocate


Joined: 24 Jan 2010
Posts: 2132

PostPosted: Sat Jul 18, 2020 8:21 am    Post subject: Reply with quote

fedeliallalinea wrote:
Quote:
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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 17451

PostPosted: Sat Jul 18, 2020 5:28 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6485

PostPosted: Sun Jul 19, 2020 4:58 am    Post subject: Reply with quote

Hu wrote:
IOMMU

Thanks for the explanation.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum