by Mimi Zohar

[permalink] [raw]

Subject: Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl

Hi Florian,

On Sun, 2021-10-10 at 16:10 +0200, Florian Weimer wrote:
> * Micka?l Sala?n:
>
> > Being able to restrict execution also enables to protect the kernel by
> > restricting arbitrary syscalls that an attacker could perform with a
> > crafted binary or certain script languages. It also improves multilevel
> > isolation by reducing the ability of an attacker to use side channels
> > with specific code. These restrictions can natively be enforced for ELF
> > binaries (with the noexec mount option) but require this kernel
> > extension to properly handle scripts (e.g. Python, Perl). To get a
> > consistent execution policy, additional memory restrictions should also
> > be enforced (e.g. thanks to SELinux).
>
> One example I have come across recently is that code which can be
> safely loaded as a Perl module is definitely not a no-op as a shell
> script: it downloads code and executes it, apparently over an
> untrusted network connection and without signature checking.
>
> Maybe in the IMA world, the expectation is that such ambiguous code
> would not be signed in the first place, but general-purpose
> distributions are heading in a different direction with
> across-the-board signing:

Automatically signing code is at least the first step in the right
direction of only executing code with known provenance. Perhaps future
work would address the code signing granularity.

>
> Signed RPM Contents
> <https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents>
>
> So I wonder if we need additional context information for a potential
> LSM to identify the intended use case.

My first thoughts were an enumeration UNSIGNED_DOWNLOADED_CODE or maybe
even UNTRUSTED_DOWNLOADED_CODE, but that doesn't seem very
helpful. What type of context information were you thinking about?

Mimi

2021-10-11 21:10:30

by Andrew Morton

[permalink] [raw]

Subject: Re: [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)

On Mon, 11 Oct 2021 10:47:04 +0200 Mickaël Salaün <[email protected]> wrote:

>
> On 10/10/2021 23:48, Andrew Morton wrote:
> > On Fri, 8 Oct 2021 12:48:37 +0200 Mickaël Salaün <[email protected]> wrote:
> >
> >> The final goal of this patch series is to enable the kernel to be a
> >> global policy manager by entrusting processes with access control at
> >> their level. To reach this goal, two complementary parts are required:
> >> * user space needs to be able to know if it can trust some file
> >> descriptor content for a specific usage;
> >> * and the kernel needs to make available some part of the policy
> >> configured by the system administrator.
> >
> > Apologies if I missed this...
> >
> > It would be nice to see a description of the proposed syscall interface
> > in these changelogs! Then a few questions I have will be answered...
>
> I described this syscall and it's semantic in the first patch in
> Documentation/admin-guide/sysctl/fs.rst

Well, kinda. It didn't explain why the `usage' and `flags' arguments
exist and what are the plans for them.

> Do you want me to copy-paste this content in the cover letter?

That would be best please. It's basically the most important thing
when reviewing the implementation.

> >
> > long trusted_for(const int fd,
> > const enum trusted_for_usage usage,
> > const u32 flags)
> >
> > - `usage' must be equal to TRUSTED_FOR_EXECUTION, so why does it
> > exist? Some future modes are planned? Please expand on this.
>
> Indeed, the current use case is to check if the kernel would allow
> execution of a file. But as Florian pointed out, we may want to add more
> context in the future, e.g. to enforce signature verification, to check
> if this is a legitimate (system) library, to check if the file is
> allowed to be used as (trusted) configuration…
>
> >
> > - `flags' is unused (must be zero). So why does it exist? What are
> > the plans here?
>
> This is mostly to follow syscall good practices for extensibility. It
> could be used in combination with the usage argument (which defines the
> user space semantic), e.g. to check for extra properties such as
> cryptographic or integrity requirements, origin of the file…
>
> >
> > - what values does the syscall return and what do they mean?
> >
>
> It returns 0 on success, or -EACCES if the kernel policy denies the
> specified usage.

And please document all of this in the changelog also.