On 02/21/2012 05:15 PM, Mimi Zohar wrote:
On Tue, 2012-02-21 at 14:58 +0100, Roberto Sassu wrote:
Hi Mimi
do you intend a patch to reintroduce the 'ima=' kernel parameter for
enabling/disabling IMA? If so, i have not actually thought about this
but it should be not difficult to implement. Probably we can support
these modes:
I'm not sure. There was a lot of complaint way back when. Before
re-introducing it, I'd prefer to hear from others how they feel.
Ok, it is better to wait until this point becomes clear.
- disabled: IMA returns immediately to the system call;
Today this is done by booting with a null policy.
I think 'disabled' would mean that the hooks implementation should
consist only in a immediate return without the execution of any
specific code (in the IMA case, the function ima_must_measure()).
Probably it is a good idea to allow to completely disable IMA at
runtime.
- measure_only: IMA performs only measurements and does not return any
error to the system call;
Booting with a policy, will achieve this result.
The purpose of the 'ima=' kernel parameter can be also to select
the IMA features to be enabled at runtime. So, to avoid confusion,
we can use it to disable all features, to enable the measure or
appraise capabilities or both. Then, we can keep the existing
'ima_appraise=' parameter while defining the values 'permissive'
and 'enforcing'.
- appraise_permissive: IMA stores measurements in the files extended
attribute and in the measurements list but does not return any error
to the system call even if the integrity check fails;
IMA and IMA-appraisal are different features and should not be combined.
Currently, one can be enabled without the other. For example, some may
only want the measurement list, while others may only want integrity
enforcement.
Maybe both can be useful. For example, the appraise feature allows
to detect if a file has been tampered with while the measurement
feature allows verifiers to determine if the value stored can be
considered good or not.
- appraise_enforce: IMA does the same as the previous mode but returns
an error to the system call if the integrity check fails.
"ima_appraise= enabled | fix | off" are currently supported.
Further, we can have a simple user-space package which will contain the
documentation about how to write a policy (so that it will be more
easy to find in respect to the whole kernel documentation) and a tool
that will fix/verify the measurements stored in the files extended
attribute.
Having a separate user-space package will simplify the interaction for
users with the IMA kernel-space portion and will allow to determine
whether the IMA support should be enabled in Systemd.
Having a Systemd config file wouldn't change the need for the existing
boot command line options. None of them can or should go away, since
IMA must start measuring before any files are accessed, including the
config and policy files, otherwise the chain of trust would be lost.
I meant we can create a new package called for example 'ima-utils'
that can be used by Systemd to determine, at compile time, whether
the IMA support for loading custom policies should be enabled or not.
At runtime, Systemd could inspect the kernel command line looking for
IMA-related parameters (this solution is actually not available) or,
as implemented in my patch, it will only check for the presence of the
policy file in the default location. This file will be measured by
the boot loader, together with the Systemd main executable, to preserve
the chain of trust.
Thanks
Roberto Sassu
thanks,
Mimi
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
