From: Dominique Martinet <asmadeus@codewreck.org>
To: Jeff Xu <jeffxu@chromium.org>
Cc: skhan@linuxfoundation.org, keescook@chromium.org,
akpm@linux-foundation.org, dmitry.torokhov@gmail.com,
dverkamp@chromium.org, hughd@google.com, jeffxu@google.com,
jorgelo@chromium.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
jannh@google.com, linux-hardening@vger.kernel.org,
linux-security-module@vger.kernel.org,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v8 3/5] mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC
Date: Thu, 29 Jun 2023 19:29:46 +0900 [thread overview]
Message-ID: <ZJ1dGvWkJVAbBPn7@codewreck.org> (raw)
In-Reply-To: <CABi2SkWnAgHK1i6iqSqPMYuNEhtHBkO8jUuCvmG3RmUB5TKHJw@mail.gmail.com>
Jeff Xu wrote on Wed, Jun 28, 2023 at 09:33:27PM -0700:
> > > BTW I find the current behaviour rather hard to use: setting this to 2
> > > should still set NOEXEC by default in my opinion, just refuse anything
> > > that explicitly requested EXEC.
> >
> > And I just noticed it's not possible to lower the value despite having
> > CAP_SYS_ADMIN: what the heck?! I have never seen such a sysctl and it
> > just forced me to reboot because I willy-nilly tested in the init pid
> > namespace, and quite a few applications that don't require exec broke
> > exactly as I described below.
> >
> > If the user has CAP_SYS_ADMIN there are more container escape methods
> > than I can count, this is basically free pass to root on main namespace
> > anyway, you're not protecting anything. Please let people set the sysctl
> > to what they want.
>
> Yama has a similar setting, for example, 3 (YAMA_SCOPE_NO_ATTACH)
> will not allow downgrading at runtime.
>
> Since this is a security feature, not allowing downgrading at run time
> is part of the security consideration. I hope you understand.
I didn't remember yama had this stuck bit; that still strikes me as
unusual, and if you require a custom LSM rule for memfd anyway I don't
see why it couldn't enforce that the sysctl is unchanged, but sure.
Please, though:
- I have a hard time thinking of 1 as a security flag in general (even
if I do agree a sloppy LSM rule could require it); I would only lock 2
- please make it clear, I don't see any entry in the sysctl
documentation[1] about memfd_noexec, there should be one and you can
copy the wording from yama's doc[2]: "Once set, this sysctl value cannot
be changed"
[1] Documentation/admin-guide/sysctl/vm.rst
[2] Documentation/admin-guide/LSM/Yama.rst
Either way as it stands I still don't think one can expect most
userspace applications to be converted until some libc wrapper takes
care of the retry logic and a couple of years, so I'll go look for
another way of filtering this (and eventually setting this to 1) as you
suggested.
I'll leave the follow-up up to you and won't bother you more.
Thanks,
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2023-06-29 10:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-15 0:12 [PATCH v8 0/5] mm/memfd: introduce MFD_NOEXEC_SEAL and MFD_EXEC jeffxu
2022-12-15 0:12 ` [PATCH v8 1/5] mm/memfd: add F_SEAL_EXEC jeffxu
2022-12-15 0:12 ` [PATCH v8 2/5] selftests/memfd: add tests for F_SEAL_EXEC jeffxu
2022-12-15 0:12 ` [PATCH v8 3/5] mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC jeffxu
2023-06-28 11:42 ` Dominique Martinet
2023-06-28 19:31 ` Dominique Martinet
2023-06-29 4:33 ` Jeff Xu
2023-06-29 10:29 ` Dominique Martinet [this message]
2023-06-29 21:04 ` Jeff Xu
2023-06-29 4:13 ` Jeff Xu
2022-12-15 0:12 ` [PATCH v8 4/5] mm/memfd: Add write seals when apply SEAL_EXEC to executable memfd jeffxu
2022-12-15 0:12 ` [PATCH v8 5/5] selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC jeffxu
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=ZJ1dGvWkJVAbBPn7@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=akpm@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dverkamp@chromium.org \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lkp@intel.com \
--cc=skhan@linuxfoundation.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.