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