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

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

On Tue, 2023-01-31 at 16:48 -0800, Fan Wu wrote:
> 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.

Ok, maybe it is necessary to specify better the scope of IPE, why the
current implementation can be considered as complete.

If we say, IPE can only allow/deny operations on system components with
immutable security properties, clearly memfd as a component cannot
fullfill this goal due to the non-immutability. This would apply to any
component allowing modifications.

How to address this? What is the immutable property then?

In the case of memfd, intuitively, a useful property for integrity
could be for example that the content can be accessed/modified by only
one process. No other (possibly malicious) processes can tamper with
that file.

So, it is true, to make this property immutable more hooks are needed.
But should it be something that IPE does? Or it should be done by an
external component (another LSM) that does the enforcement and reports
to IPE that the property is true? Theoretically (with a proper policy),
existing LSMs could be used for that purpose too.

I would say more the second, it should not be IPE job, so that IPE can
exclusively focus on evaluating properties, not making sure that the
properties are immutable.

Roberto

> -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
> > 

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit