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

Gustavo Sverzut Barbieri barbieri at profusion.mobi
Thu Feb 16 13:50:53 PST 2012


On Thu, Feb 16, 2012 at 12:35 PM, Roberto Sassu <roberto.sassu at polito.it> wrote:
> On 02/16/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>
>> On Thu, Feb 16, 2012 at 11:38 AM, Roberto Sassu<roberto.sassu at polito.it>
>>  wrote:
>>>
>>> On 02/16/2012 05:56 AM, Michael Cassaniti wrote:
>>>>
>>>>
>>>> On 16/02/2012 04:12, Roberto Sassu wrote:
>>>>>
>>>>>
>>>>> On 02/15/2012 05:55 PM, Gustavo Sverzut Barbieri wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 15, 2012 at 2:26 PM, Roberto
>>>>>> Sassu<roberto.sassu at polito.it>  wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 02/15/2012 03:30 PM, Gustavo Sverzut Barbieri wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 15, 2012 at 11:23 AM, Roberto
>>>>>>>> Sassu<roberto.sassu at polito.it>  wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The new function ima_setup() loads an IMA custom policy from a
>>>>>>>>> file in the
>>>>>>>>> default location '/etc/sysconfig/ima-policy', if present, and
>>>>>>>>> writes it to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> isn't /etc/sysconfig too specific to Fedora?
>>>>>>>>
>>>>>>> Hi Gustavo
>>>>>>>
>>>>>>> probably yes. I see the code in 'src/locale-setup.c' where the
>>>>>>> the configuration directory depends on the target distribution.
>>>>>>> I can implement something like that in my patch.
>>>>>>
>>>>>>
>>>>>> Can't IMA be changed? Lennart seems to be pushing for distribution
>>>>>> independent location files. If you can get IMA people to agree on
>>>>>> something, just use this one instead.
>>>>>>
>>>>>> People that use IMA with systemd must use this location. Eventually
>>>>>> this will happen with every configuration file we support.
>>>>>>
>>>>> The location of the policy file is not IMA dependent. I chose that
>>>>> because it seemed to me the right place where to put this file.
>>>>> So, i can easily modify the location to be distribution independent
>>>>> but i don't known which directory would be appropriate.
>>>>> Any proposal?
>>>>>
>>>>> Regards
>>>>>
>>>>> Roberto Sassu
>>>>>
>>>>>
>>>>>>>> Also, I certainly have no such things in my system and see no point
>>>>>>>> in
>>>>>>>> calling ima_setup() on it. Or even compiling the source file in such
>>>>>>>> case.
>>>>>>>>
>>>>>>> Ok. I can enclose the code in ima-setup.c within an 'ifdef HAVE_IMA'
>>>>>>> statement, as it happens for SELinux. However an issue is that there
>>>>>>> is no a specific package for IMA that can be checked to set the
>>>>>>> HAVE_IMA
>>>>>>> definition to yes. Instead, the code can be enabled for example by
>>>>>>> adding the parameter '--enable_ima' in the configure script.
>>>>>>
>>>>>>
>>>>>> okay.
>>>>>>
>>>>>> --
>>>>>> Gustavo Sverzut Barbieri
>>>>>> http://profusion.mobi embedded systems
>>>>>> --------------------------------------
>>>>>> MSN: barbieri at gmail.com
>>>>>> Skype: gsbarbieri
>>>>>> Mobile: +55 (19) 9225-2202
>>>>
>>>>
>>>> I'm under the impression this function belongs to a userspace tool. If
>>>> not then I just don't see a good reason that this patch is required. I
>>>> do understand that the IMA policy should be loaded as early as possible,
>>>> but I believe that early userspace scripts should be doing that work. If
>>>> it is a userspace function, then whatever makes you happy, other
>>>> distro's will roll their own.
>>>
>>>
>>>
>>> Thanks Mimi for your contribution. I just want to add some
>>> considerations.
>>>
>>>
>>>
>>> Hi Michael
>>>
>>> the reason for which the loading of IMA policies has been placed in
>>> the main Systemd executable is that the measurement process performed
>>> by IMA should start as early as possible. Otherwise, in order to build
>>> the 'chain of trust' during the boot process from the BIOS to software
>>> applications, it is required to measure those components loaded before
>>> IMA is initialized with other means (for example from the boot loader).
>>>
>>> The more the IMA initialization is postponed, greater is the number of
>>> components that must be measured using the second way. For instance,
>>> if the policy loading is done in a userspace script you have to measure
>>> the interpreter and the configuration files read by the latter.
>>>
>>> Since the policy loading can be implemented in different ways depending
>>> on the init system (systemd, upstart, ...), an user must identify the
>>> components to be measured for each case. Instead, if the IMA policy is
>>> loaded in the main Systemd executable, only this file must be measured
>>> by the boot loader.
>>
>>
>> Then I wonder: why not make an ima-init binary that:
>>   - does ima_setup()
>>   - exec systemd || upstart || ...
>>
>> this way you only have to audit this very small file and not systemd
>> itself, it's very early and so on.
>>
>
> This does not work because SELinux is initialized inside Systemd and IMA
> requires it for parsing LSM rules in the policy.

initramfs may do it as well, no? then systemd will inherit it.

I'm not using or reviewing the SELinux patches myself, so I may be
wrong. Let's see if someone will check the code or Lennart will say
what he did.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202


More information about the systemd-devel mailing list