Good and bad ideas w.r.t. kernel and security

Good and bad ideas w.r.t. kernel and security

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

Good and bad ideas w.r.t. kernel and security

Kernel tries to provide many security guarantees at different
levels. Still, some things are easier to guarantee than others, and
some security barriers are really important, while others... not so
much.

Kernel should be secure against remote attackers.

    And it reasonably is, when not, we get it fixed with high priority.

Kernel should protect itself and other users against local, non-priviledged users.

    Tries, but attack surface is big.
    People don't care about DoS attacks much.
    => Running untrusted code is a bad idea. Forkbomb is few characters in sh.

Fast, out-of-order CPUs leak user data via timing side-channels. Those
CPUs should not process sensitive data. JITs can be used to extract the data.

    We can try to work around the problems and apply vendor-provided
    workarounds, but there are likely more problems in future. Similar
    bugs are hidden in CPU microarchitectures, and in particular
    Spectre workarounds are whack-a-mole and thus incomplete.
    
    Hyperthreading makes those attacks easier.
    => Use suitable CPUs to process sensitive data.

    BPF is in-kernel JIT
    => Don't use BPF, make sure it is disabled on your configurations.

Filesystems are complex, robustness against malformed filesystems is hard.

    Some filesystems try to be robust against filesystems corruption,
    and some don't even try. Some perform checks during mount, but
    that means that malicious device can work around them.

    => Don't mount untrusted filesystems. If you have to, use simple and
    common filesystem. VFAT might be good choice.
    
Kernel should protect itself against local users with CAP_XX.

    Yes, there's capability system, and in theory capabilities should be separated.
    => Don't rely on that. Noone else does.

Some systems try to protect themselves against people with physical access.

    Laws of physics says it is impossible, but people can still try to
    make it more costly for the "attacker".
    => Please don't rely on that.

Coredumps are useful for debugging, but random processes leaving files in cwd
may not be welcome

    Consider disabling coredumps, perhaps with RLIMIT_CORE=0.

    Consider putting all coredumps into single directory with /proc/sys/kernel/core_pattern.

Kernel config options for hardened kernel

Investigate:

CONFIG_X86_IOPL_IOPERM=y

https://timesys.com/security/securing-your-linux-configuration-kernel-hardening/

RETPOLINE=Y
DEVMEM=is not set
PAGE_POISONING=Y , enable withpage_poison=1
GCC_PLUGIN_STACKLEAK=Y
DEBUG_BUGVERBOSE=is not set , kind of security by obscurity, but may make attackers work harder; will also make your own debugging harder, so..
ARCH_HAS_ELF_RANDOMIZE=Y
INIT_ON_FREE_DEFAULT_ON=Y
INIT_ON_ALLOC_DEFAULT_ON=Y
DEBUG_VIRTUAL=Y


-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [cip-dev] Good and bad ideas w.r.t. kernel and security

[Masami Ichikawa]

HI.

On Tue, Jan 17, 2023 at 10:17 PM Pavel Machek <pavel@denx.de> wrote:
>
> Good and bad ideas w.r.t. kernel and security
>
> Kernel tries to provide many security guarantees at different
> levels. Still, some things are easier to guarantee than others, and
> some security barriers are really important, while others... not so
> much.
>
> Kernel should be secure against remote attackers.
>
>     And it reasonably is, when not, we get it fixed with high priority.
>
> Kernel should protect itself and other users against local, non-priviledged users.
>
>     Tries, but attack surface is big.
>     People don't care about DoS attacks much.
>     => Running untrusted code is a bad idea. Forkbomb is few characters in sh.
>
> Fast, out-of-order CPUs leak user data via timing side-channels. Those
> CPUs should not process sensitive data. JITs can be used to extract the data.
>
>     We can try to work around the problems and apply vendor-provided
>     workarounds, but there are likely more problems in future. Similar
>     bugs are hidden in CPU microarchitectures, and in particular
>     Spectre workarounds are whack-a-mole and thus incomplete.
>
>     Hyperthreading makes those attacks easier.
>     => Use suitable CPUs to process sensitive data.
>
>     BPF is in-kernel JIT
>     => Don't use BPF, make sure it is disabled on your configurations.
>
> Filesystems are complex, robustness against malformed filesystems is hard.
>
>     Some filesystems try to be robust against filesystems corruption,
>     and some don't even try. Some perform checks during mount, but
>     that means that malicious device can work around them.
>
>     => Don't mount untrusted filesystems. If you have to, use simple and
>     common filesystem. VFAT might be good choice.
>
> Kernel should protect itself against local users with CAP_XX.
>
>     Yes, there's capability system, and in theory capabilities should be separated.
>     => Don't rely on that. Noone else does.
>
> Some systems try to protect themselves against people with physical access.
>
>     Laws of physics says it is impossible, but people can still try to
>     make it more costly for the "attacker".
>     => Please don't rely on that.
>
> Coredumps are useful for debugging, but random processes leaving files in cwd
> may not be welcome
>
>     Consider disabling coredumps, perhaps with RLIMIT_CORE=0.
>
>     Consider putting all coredumps into single directory with /proc/sys/kernel/core_pattern.
>
> Kernel config options for hardened kernel
>
> Investigate:
>
> CONFIG_X86_IOPL_IOPERM=y
>
> https://timesys.com/security/securing-your-linux-configuration-kernel-hardening/
>
> RETPOLINE=Y
> DEVMEM=is not set
> PAGE_POISONING=Y , enable withpage_poison=1
> GCC_PLUGIN_STACKLEAK=Y
> DEBUG_BUGVERBOSE=is not set , kind of security by obscurity, but may make attackers work harder; will also make your own debugging harder, so..
> ARCH_HAS_ELF_RANDOMIZE=Y
> INIT_ON_FREE_DEFAULT_ON=Y
> INIT_ON_ALLOC_DEFAULT_ON=Y
> DEBUG_VIRTUAL=Y
>
>

Yes. Disabling  features to reduce attack surface, and/or enabling
features to prevent/mitigate future attack in configuration file is
important.
Security hardened makes less debugalability but production systems
should prioritize security first.

kconfig-hardened-check tool is helpful to check kernel configuration.

https://github.com/a13xp0p0v/kconfig-hardened-check

> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#10374): https://lists.cip-project.org/g/cip-dev/message/10374
> Mute This Topic: https://lists.cip-project.org/mt/96329245/4520416
> Group Owner: cip-dev+owner@lists.cip-project.org
> Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129101/4520416/1465703922/xyzzy [masami.ichikawa@miraclelinux.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Regards,
-- 
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@cybertrust.co.jp
          :masami.ichikawa@miraclelinux.com