linux-kernel - Trusted kernel patchset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1426282708-21485-1-git-send-email-matthew.garrett@nebula.com>
Date:	Fri, 13 Mar 2015 11:38:16 -1000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	linux-security-module@...r.kernel.org
Cc:	james.l.morris@...cle.com, serge@...lyn.com,
	linux-kernel@...r.kernel.org, keescook@...omium.org, hpa@...or.com,
	gnomes@...rguk.ukuu.org.uk
Subject: Trusted kernel patchset 

This is a slightly cleaned up version of the patchset posted last year
(https://lkml.org/lkml/2014/2/26/554). I've made a couple of minor changes
based on feedback, but otherwise this is pretty much the same. Some things
I *haven't* done:

1) Disabled CAP_SYS_RAWIO

Disabling CAP_SYS_RAWIO has the fun side effect of disabling things like
CPU microcode loading. Given that the microcode is already signed and the
CPU validates that, this isn't helpful. There's just too many cases where
CAP_SYS_RAWIO is required for features that are outside the scope of ensuring
that the kernel can't be tampered with. In addition, there are features that
don't require CAP_SYS_RAWIO which should be blocked.

2) Disabled CAP_SYS_RAWIO but whitelisted specific CAP_SYS_RAWIO features

This was Alan's suggestion - change capable() to check whether the capability
requested was blacklisted, and then add a capable_always() that ignored the
blacklist. In this scenario, /dev/mem would still use capable(CAP_SYS_RAWIO)
and would be denied, but the microcode loader would use
capable_always(CAP_SYS_RAWIO) and would be permitted. This changes certain
behavioural expectations (eg, having CAP_SYS_RAWIO would no longer be
sufficient to pass capable(CAP_SYS_RAWIO)) and would still hit the problem
of features that should be blocked but don't currently require CAP_SYS_RAWIO.
I think this is fundamentally more confusing than the approach I've
implemented.

3) Done one of the above and added new CAP_SYS_RAWIO checks

This would handle the case of features that should be blocked but which don't
currently require CAP_SYS_RAWIO, but would break any userspace that has
dropped privileges and expects to be able to use these features even in the
case that this feature isn't enabled. I don't think it's beneficial.

4) Used the word "measured"

Nothing is being measured.

A patchset basically equivalent to this is already used by most major Linux
distributions, so it would be nice to either get this merged or have feedback
from a relevant maintainer as to how they'd like it to be implemented instead.

-- 
Matthew Garrett | <matthew.garrett@...ula.com> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/