linux-kernel - Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230201004852.GB30104@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date:   Tue, 31 Jan 2023 16:48:52 -0800
From:   Fan Wu <wufan@...ux.microsoft.com>
To:     Roberto Sassu <roberto.sassu@...weicloud.com>
Cc:     corbet@....net, zohar@...ux.ibm.com, jmorris@...ei.org,
        serge@...lyn.com, tytso@....edu, ebiggers@...nel.org,
        axboe@...nel.dk, agk@...hat.com, snitzer@...nel.org,
        eparis@...hat.com, paul@...l-moore.com, linux-doc@...r.kernel.org,
        linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-fscrypt@...r.kernel.org, linux-block@...r.kernel.org,
        dm-devel@...hat.com, linux-audit@...hat.com,
        roberto.sassu@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)

On Tue, Jan 31, 2023 at 03:22:05PM +0100, Roberto Sassu wrote:
> On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > IPE has two known gaps:
> > 
> > 1. IPE cannot verify the integrity of anonymous executable memory, such as
> >   the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd code.
> >   Unfortunately, as this is dynamically generated code, there is no way
> >   for IPE to ensure the integrity of this code to form a trust basis. In all
> >   cases, the return result for these operations will be whatever the admin
> >   configures the DEFAULT action for "EXECUTE".
> 
> I think it would be useful to handle special cases, for example you
> could allow a process that created a file with memfd to use it, at the
> condition that nobody else writes it.
> 
> This would be required during the boot, otherwise services could fail
> to start (depending on the policy).
> 
Thanks for the suggestion. I agree with your opinion and I think supporting
memfd is possible but restricting read/write needs more hooks. We would like
to avoid adding more complexity to this initial posting as necessary. 
We will consider this as a future work and will post follow-on patches
in the future.

-Fan

> > 2. IPE cannot verify the integrity of interpreted languages' programs when
> >   these scripts invoked via ``<interpreter> <file>``. This is because the
> >   way interpreters execute these files, the scripts themselves are not
> >   evaluated as executable code through one of IPE's hooks. Interpreters
> >   can be enlightened to the usage of IPE by trying to mmap a file into
> >   executable memory (+X), after opening the file and responding to the
> >   error code appropriately. This also applies to included files, or high
> >   value files, such as configuration files of critical system components.
> 
> Ok, it is a well known issue. Hopefully, it will be fixed soon.
> 
> Roberto
>