Re: [Linux-ima-user] [systemd-devel] [PATCH 2/2] main: added support for loading IMA custom policies

[Roberto Sassu <roberto.sassu@polito.it>]

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
>