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:

quoted

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

quoted

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