linux-kernel - Re: [RFC] Turn lockdown into an LSM

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVow8U=xhQdJt8kSMX16Lf0Mstf3+QxY4iz4DHVp=PYWA@mail.gmail.com>
Date:   Wed, 22 May 2019 10:08:32 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     James Morris <jmorris@...ei.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [RFC] Turn lockdown into an LSM

On Wed, May 22, 2019 at 9:49 AM Matthew Garrett <mjg59@...gle.com> wrote:
>
> On Tue, May 21, 2019 at 7:40 PM James Morris <jmorris@...ei.org> wrote:
> > An LSM could also potentially implement its own policy for the hook.
>
> That was my plan. Right now the hook just gets an ASCII description of
> the reason for the lockdown - that seems suboptimal for cases like
> SELinux. What information would you want? My initial thinking was to
> just have a stable enum of lockdown reasons that's in the UAPI headers
> and then let other LSM tooling consume that, but I haven't spent
> enough time with the internals of SELinux to know if there'd be a more
> attractive solution.

I may be in the minority here, but I see this issue as a significant
downside of making lockdown more flexible.  If we stick with just
"this may violate integrity" and "this may violate confidentiality",
then the ABI surface is nice and narrow.  If we start having a big
uapi list of things that might qualify for lockdown, we need to worry
about compatibility issues.

This isn't purely theoretical.  Lockdown has some interesting
interactions with eBPF.  I don't want to be in a situation where v1 of
lockdown has a few eBPF hooks, but a later update improves the eBPF vs
lockdown interaction so that you can do more with eBPF on a locked
down kernel.  But now any such change has to worry about breaking the
lockdown LSM ABI.

And I still think it would be nice to have some credible use case for
a more fine grained policy than just the tri-state.  Having a lockdown
policy of "may not violate kernel confidentiality except using
kprobes" may be convenient, but it's also basically worthless, since
kernel confidentiality is gone.

All this being said, I do see one big benefit for LSM integration:
SELinux or another LSM could allow certain privileged tasks to bypass
lockdown.  This seems fine, except that there's potential nastiness
where current->cred isn't actually a valid thing to look at in the
current context.

So I guess my proposal is: use LSM, but make the hook very coarse
grained: int security_violate_confidentiality(const struct cred *) and
int security_violate_integrity(const struct cred *).

--Andy