From: John Wood <john.wood@gmx.com>
To: Alexander Lobakin <alobakin@pm.me>
Cc: John Wood <john.wood@gmx.com>, Kees Cook <keescook@chromium.org>,
Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Arnd Bergmann <arnd@arndb.de>, Andi Kleen <ak@linux.intel.com>,
valdis.kletnieks@vt.edu,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-arch@vger.kernel.org,
linux-hardening@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
Date: Fri, 2 Jul 2021 16:59:54 +0200 [thread overview]
Message-ID: <20210702145954.GA4513@ubuntu> (raw)
In-Reply-To: <20210701234807.50453-1-alobakin@pm.me>
Hi,
On Thu, Jul 01, 2021 at 11:55:14PM +0000, Alexander Lobakin wrote:
> Hi,
>
> From: John Wood <john.wood@gmx.com>
> Date: Sat, 5 Jun 2021 17:04:00 +0200
>
> > +static int brute_task_execve(struct linux_binprm *bprm, struct file *file)
> > +{
> > + struct dentry *dentry = file_dentry(bprm->file);
> > + struct inode *inode = file_inode(bprm->file);
> > + struct brute_stats stats;
> > + int rc;
> > +
> > + inode_lock(inode);
> > + rc = brute_get_xattr_stats(dentry, inode, &stats);
> > + if (WARN_ON_ONCE(rc && rc != -ENODATA))
> > + goto unlock;
>
> I think I caught a problem here. Have you tested this with
> initramfs?
No, it has not been tested with initramfs :(
> According to init/do_mount.c's
> init_rootfs()/rootfs_init_fs_context(), when `root=` cmdline
> parameter is not empty, kernel creates rootfs of type ramfs
> (tmpfs otherwise).
> The thing about ramfs is that it doesn't support xattrs.
It is a known issue that systems without xattr support are not
suitable for Brute (there are a note in the documentation).
However, the purpose is not to panic the system :(
> I'm running this v8 on a regular PC with initramfs and having
> `root=` in cmdline, and Brute doesn't allow the kernel to run
> any init processes (/init, /sbin/init, ...) with err == -95
> (-EOPNOTSUPP) -- I'm getting a
>
> WARNING: CPU: 0 PID: 173 at brute_task_execve+0x15d/0x200
> <snip>
> Failed to execute /init (error -95)
>
> and so on (and a panic at the end).
>
> If I omit `root=` from cmdline, then the kernel runs init process
> just fine -- I guess because initramfs is then placed inside tmpfs
> with xattr support.
>
> As for me, this ramfs/tmpfs selection based on `root=` presence
> is ridiculous and I don't see or know any reasons behind that.
> But that's another story, and ramfs might be not the only one
> system without xattr support.
> I think Brute should have a fallback here, e.g. it could simply
> ignore files from xattr-incapable filesystems instead of such
> WARNING splats and stuff.
Ok, it seems reasonable to me: if the file system doesn't support
xattr, but Brute is enabled, Brute will do nothing and the system
will work normally.
I will work on it for the next version.
Thanks for the feedback.
John Wood
next prev parent reply other threads:[~2021-07-02 15:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 23:55 [PATCH v8 3/8] security/brute: Detect a brute force attack Alexander Lobakin
2021-07-02 14:59 ` John Wood [this message]
2021-07-02 17:08 ` Alexander Lobakin
2021-07-03 10:59 ` John Wood
2021-07-04 14:01 ` John Wood
2021-07-05 12:52 ` Alexander Lobakin
-- strict thread matches above, loose matches on Subject: below --
2021-06-05 15:03 [PATCH v8 0/8] Fork brute force attack mitigation John Wood
2021-06-05 15:04 ` [PATCH v8 3/8] security/brute: Detect a brute force attack John Wood
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=20210702145954.GA4513@ubuntu \
--to=john.wood@gmx.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alobakin@pm.me \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=valdis.kletnieks@vt.edu \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.