cip-dev.lists.cip-project.org archive mirror
 help / color / mirror / Atom feed
From: "Pavel Machek" <pavel@denx.de>
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Security from kernel's point of view
Date: Sun, 21 Feb 2021 09:40:04 +0100	[thread overview]
Message-ID: <20210221084004.GA27760@amd> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2438 bytes --]

Hi!

I put this together... it may be useful for someone to understand what
the issues are. I guess I'd like to know from security team if they
find it useful, and from kernel people if I'm missing something or if
there are errors...

Best regards,
								Pavel

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

Kernel tries to provid 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.

Filesystems are complex, robustness against malformed filesystems is hard.

    Some filesystems try to be robust against filesystems corruption,
    and some don't even do that. 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.

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 420 bytes --]


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#6187): https://lists.cip-project.org/g/cip-dev/message/6187
Mute This Topic: https://lists.cip-project.org/mt/80797148/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-


                 reply	other threads:[~2021-02-21  8:40 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210221084004.GA27760@amd \
    --to=pavel@denx.de \
    --cc=cip-dev@lists.cip-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).