[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP22eLE6DA5P+Cx6aVP=eq3tKRGz=+P+w8omk3CcEXVo0f1Nfg@mail.gmail.com>
Date: Thu, 30 Apr 2020 14:01:21 +0300
From: "Lev R. Oshvang ." <levonshe@...il.com>
To: Aleksa Sarai <cyphar@...har.com>, viro@...iv.linux.org.uk
Cc: Mickaël Salaün <mic@...ikod.net>,
Eric Chiang <ericchiang@...gle.com>, Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>, Michael Kerrisk <mtk.manpages@...il.com>,
Mickaël Salaün <mickael.salaun@....gouv.fr>,
Mimi Zohar <zohar@...ux.ibm.com>, kernel-hardening@...ts.openwall.com,
LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC
On Thu, Apr 30, 2020 at 4:55 AM Aleksa Sarai <cyphar@...har.com> wrote:
>
> On 2020-04-28, Mickaël Salaün <mic@...ikod.net> wrote:
> > The goal of this patch series is to enable to control script execution
> > with interpreters help. A new RESOLVE_MAYEXEC flag, usable through
> > openat2(2), is added to enable userspace script interpreter to delegate
> > to the kernel (and thus the system security policy) the permission to
> > interpret/execute scripts or other files containing what can be seen as
> > commands.
> >
> > This third patch series mainly differ from the previous one by relying
> > on the new openat2(2) system call to get rid of the undefined behavior
> > of the open(2) flags. Thus, the previous O_MAYEXEC flag is now replaced
> > with the new RESOLVE_MAYEXEC flag and benefits from the openat2(2)
> > strict check of this kind of flags.
>
> My only strong upfront objection is with this being a RESOLVE_ flag.
>
> RESOLVE_ flags have a specific meaning (they generally apply to all
> components, and affect the rules of path resolution). RESOLVE_MAYEXEC
> does neither of these things and so seems out of place among the other
> RESOLVE_ flags.
>
> I would argue this should be an O_ flag, but not supported for the
> old-style open(2). This is what the O_SPECIFIC_FD patchset does[1] and I
> think it's a reasonable way of solving such problems.
>
> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> <https://www.cyphar.com/>
I see that we discuss here the problem which was originated due to the
lack of flags checks at open()
As a newbie in kernel I want to propose maybe naive approach - add
missing flag cheeks to open().
In order to not break badly coded application at once (applications
hat pass full u32 number I propose to introduce
2 new sysctls:
fs.verify_open_flags = BITMASK of flags open() uses in this kernel,
i.r O_CREAT||O_RDOBLY|O_RDWR,,
fs.verify_open_flags_action = NONE|WARN
1) fs.verify_open_flags and flags_action knobs will allow
distributions and package maintainers to detect and fix bad code. On
the other hand, it will allow to finally verify flags. passed to open
2) It will show kernel ABI to libc
3) The semantics of O_MAYEXEC is clear and is long waited for.
I think that O_MAYEXEC pretty well describes the intention of
application to treat the file as the source of actions, whether it is
ELF or script or another format. (not necessary Posix permissions
case)
This intention is passed to the kernel and then to LSM, IMA.
4) since we need to rewrite interpretersin order to use this flag, we
can also query fs.verify_open_flags to see whether it is available.
I hope I added my 2 cents.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
