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 > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
