From: Roberto Sassu
Sent: Monday, August 2, 2021 5:13 PM

quoted

From: Mimi Zohar [mailto:zohar@linux.ibm.com]
Sent: Monday, August 2, 2021 4:42 PM
Hi Roberto,

On Fri, 2021-07-30 at 13:16 +0000, Roberto Sassu wrote:

quoted

The reason of storing the actions performed by IMA on the
digest lists helps to determine for which purpose they can be
used. If digest lists are used only for measurement purpose,
it should be sufficient that digest lists are measured. The
same applies for appraisal.

Is that assumption correct?   How would you know if the digests lists
are only being used one way and not the other.  For example, assuming
that the digest lists are stored on protected media, the digest lists
could be measured, but would not necessarily be appraised.

Hi Mimi

the actions performed by IMA on the digest lists are recorded
in the digest_list_item structure. These can be retrieved when
IMA calls diglim_digest_get_info() (actually it is the OR of the
actions for the digest lists that contain the digest passed as a
query).

At the moment, DIGLIM can only know whether a digest list
has been measured or not (with the return value of
ima_measure_critical_data()). In the next patch set, I add the
changes to get the actions from the integrity_iint_cache().

quoted

quoted

quoted

Adding the kernel_read_file() "READING_DIGEST_LIST" support in IMA

does

quoted

quoted

not seem to be optional.  IMA would then be calculating the digest list
file hash twice, once in kernel_read_file() and then, again, in
ima_measure_critical_data().

I didn't include also this part: I retrieve the integrity_iint_cache for
the opened file descriptor and I get the flags from there. If the
IMA_MEASURED flag is set, it is not necessary to call also
ima_measure_critical_data().

Right, assuming the file is in policy, the digest would already be
stored in the iint cache.

quoted

quoted

quoted

quoted

I understand that with your changes to ima_measure_critical_data(),
which are now in next-integrity-testing branch, allow IMA to calculate
the file data hash.

Yes, correct. But actually there is another useful use case.
If digest lists are not in the format supported by the kernel,
the user space parser has to convert them before uploading
them to the kernel.

ima_measure_critical_data() would in this case measure
the converted digest list (it is written directly, without
sending the file path). It is easier to attest the result,
instead of determining whether the user space parser
produced the expected result (by checking the files it
read).

The application to properly convert the digest list file data into the
appropriate format would need to be trusted.  I'm concerned that not
requiring the converted data to be signed and the signature verified is
introducing a new integrity gap.  Perhaps between an LSM policy,
limiting which files may be read by the application, and an IMA policy,
requiring all files read by this application to be measured and the
signature verified, this integrity gap could be averted.

It is the weakest point in the chain, yes. Relying on existing LSMs
didn't seem to me a good idea, as:
- a new policy must be installed
- we must be sure that the policy is really enforced
- we need to support different LSMs (SELinux for Fedora,
  Apparmor for SUSE)
- there might be no LSM we can rely on

For these reasons, I developed a new LSM. Its purpose is to
identify the user space parser and for each file it opens, ensure
that the file has been measured or appraised by IMA. If one of
these actions are missing, it will not be set in the digest list the
user space parser uploads to the kernel (which means that IMA
will ignore the digest list for that specific action).

Properly identifying (all) user space parser(s) would be critical.  It
would be simpler and  safer to require the converted data be signed.

When a process directly uploads a buffer to the kernel, the actions are
added to a digest list depending on the result of ima_measure_critical_data()
and from the actions attached to the process credentials and set by the
new LSM.

If a process fails the identification, the actions in the process credentials
remain zero and the digest lists the process uploads will be ignored by IMA.

The actions in the process credentials are set with the actions performed
on the executable by IMA, only if the digest of the executable is found in
a digest list and the digest list type is COMPACT_PARSER. The parser is
statically linked.

The digest list for the parser can be generated at the end of the
building process and signed similarly to kernel modules (for SUSE,
with pesign-obs-integration). This is the only exception to handle,
other packages are not affected.

After the parser has been identified, each file operation is monitored.
The LSM has to explicitly perform a second open to ensure that
the file is measured/appraised before the integrity_iint_cache structure
is retrieved (because IMA is called after all LSMs).

If an action is missing from the integrity_iint_cache structure, it
will be cleared by the LSM in the actions attached to the process
credentials, and will not be added to the digest list being uploaded.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

I agree, it would be much easier. However, it would require changes
to the building infrastructure of Linux distribution vendors, which
might limit the applicability of DIGLIM.

With the user space parser taking care of the conversion, distributions
can do appraisal of executables and shared libraries with an update of:
- the kernel: to add DIGLIM
- dracut: to add required digest lists in the initial ram disk
- rpm (plugin): to extract the RPM header and its signature and write
  them to a file that is uploaded to the kernel by the user space parser

I'm planning to append the signature at the end of the RPM header
(and use appraise_type=modsig) to avoid the dependency on the
'initramfs: add support for xattrs in the initial ram disk' patch set
(which I might try to resume in the future).

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

quoted

thanks,

Mimi