Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 7 Mar 2021 19:05:41 +0100
From:   John Wood <john.wood@gmx.com>
To:     Andi Kleen <ak@linux.intel.com>
Cc:     John Wood <john.wood@gmx.com>, Kees Cook <keescook@chromium.org>,
        Jann Horn <jannh@google.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Jonathan Corbet <corbet@lwn.net>,
        James Morris <jmorris@namei.org>,
        Shuah Khan <shuah@kernel.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-kselftest@vger.kernel.org,
        kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v5 7/8] Documentation: Add documentation for the Brute LSM
Message-ID: <20210307180541.GA17108@ubuntu>
References: <20210227153013.6747-1-john.wood@gmx.com>
 <20210227153013.6747-8-john.wood@gmx.com>
 <878s78dnrm.fsf@linux.intel.com>
 <20210302183032.GA3049@ubuntu>
 <20210307151920.GR472138@tassilo.jf.intel.com>
 <20210307164520.GA16296@ubuntu>
 <20210307172540.GS472138@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210307172540.GS472138@tassilo.jf.intel.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Mar 07, 2021 at 09:25:40AM -0800, Andi Kleen wrote:
> > processes created from it will be killed. If the systemd restart the n=
etwork
> > daemon and it will crash again, then the systemd will be killed. I thi=
nk this
> > way the attack is fully mitigated.
>
> Wouldn't that panic the system? Killing init is usually a panic.

The mitigation acts only over the process that crashes (network daemon) an=
d the
process that exec() it (systemd). This mitigation don't go up in the proce=
sses
tree until reach the init process.

Note: I am a kernel newbie and I don't know if the systemd is init. Sorry =
if it
is a stupid question. AFAIK systemd is not the init process (the first pro=
cess
that is executed) but I am not sure.

>
> > > Or if it's a interactive login you log in again.
> >
> > First the login will be killed (if it fails with a fatal signal) and i=
f it is
> > restarted, the process that exec() it again will be killed. In this ca=
se I think
> > that the threat is also completely mitigated.
>
> Okay so sshd will be killed. And if it gets restarted eventually init,
> so panic again.

In this scenario the process that exec() the login will be killed (sshd
process). But I think that sshd is not the init process. So no panic.

> That's a fairly drastic consequence because even without panic
> it means nobody can fix the system anymore without a console.

So, you suggest that the mitigation method for the brute force attack thro=
ugh
the execve system call should be different (not kill the process that exec=
).
Any suggestions would be welcome to improve this feature.

> So probably the mitigation means that most such attacks eventually lead
> to a panic because they will reach init sooner or later.

I think it is not correct. As explain earlier the current mitigation metho=
d only
works over the process that crashes and their parent. It not go up in the
processes tree until reach the init process.

> Another somewhat worrying case is some bug that kills KVM guests.
> So if the bug can be triggered frequently you can kill all the
> virtualization management infrastructure.

Well, we need to work to avoid false positives.

> I don't remember seeing a discussion of such drastic consequences in
> your description. It might be ok depending on the use case,
> but people certainly need to be aware of it.
>
> It's probably not something you want to have enabled by default ever.
>
> -Andi
>
Thanks,
John Wood