Date:	Wed, 02 Jun 2010 13:23:00 +0300
From:	Dmitry Kasatkin <dmitry.kasatkin@...ia.com>
To:	ext Shaz <shazalive@...il.com>
CC:	ext Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	David Safford <safford@...son.ibm.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	securityengineeringresearchgroup 
	<securityengineeringresearchgroup@...glegroups.com>
Subject: Re: [PATCH 00/14] EVM



On 02/06/10 13:15, ext Shaz wrote:
> On Wed, Jun 2, 2010 at 2:12 PM, Dmitry Kasatkin
> <dmitry.kasatkin@...ia.com> wrote:
>   
>> On 02/06/10 10:50, ext Shaz wrote:
>>     
>>> On Wed, Jun 2, 2010 at 12:03 PM, Dmitry Kasatkin
>>> <dmitry.kasatkin@...ia.com> wrote:
>>>
>>>       
>>>> On 01/06/10 22:28, ext Mimi Zohar wrote:
>>>>
>>>>         
>>>>> On Mon, 2010-05-31 at 15:08 +0500, Shaz wrote:
>>>>>
>>>>>
>>>>>           
>>>>>>> EVM is based on EA while Aegis does not use EA as far as I can
>>>>>>> understand from the documentation available. Can we make EVM
>>>>>>> independent of EA? Even the MAC mechanism is very different then
>>>>>>> existing LSM based mechanisms.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Have a look at the following:
>>>>>>
>>>>>> http://research.nokia.com/files/NRCTR2008010.pdf
>>>>>> http://research.nokia.com/files/NRCTR2008007.pdf
>>>>>> http://lwn.net/Articles/372937/
>>>>>>
>>>>>>
>>>>>>             
>>>>> SELinux, Smack, Capabilities, and IMA all use extended attributes. The
>>>>> purpose of EVM is to detect offline tampering of these security extended
>>>>> attributes.
>>>>>
>>>>>           
>>> MeeGo/Maemo security framework does not use LSM because Maemo/MeeGo
>>> security framework only focuses at process level MAC and for that they
>>> use Dazuko as Nokia research report mentions.
>>>
>>> By the way MeeGo 1.0 has no security at the moment so one cannot be
>>> sure if they are going according to their research or what. They are
>>> also not opening the internals of their security framework. Not sure
>>> why if the whole thing is open and Linux Foundation is backing it up.
>>>
>>>
>>>       
>> Maemo/MeeGo does not do exactly what is written in that research report.
>> It has been done in parallel to our work.
>> And we do use LSM.
>>     
> Elina was the first author of the report and she is the person who has
> presented whatever is available from Maemo project regarding security.
> Therefore it is very odd that your work is in parallel to the report!
>
>   
Elena was not working for Maemo at that time.
They had own objectives in their research.
Then after moving to Maemo she was assigned to present maemo stuff.
But I guess we never said that we follow that research work.
Yeah.. might look confusing but that is how it went.

- Dmitry

>> We go approval from company layers to open source the work.
>> We will see what to do next.
>>     
> I cannot understand what the Linux Foundation will have to say about this?
>
>   
>>>>> The IMA integrity appraisal extension extends IMA with local measurement
>>>>> appraisal. The extension stores and maintains the file integrity
>>>>> measurement as an extended attribute 'security.ima', which EVM can be
>>>>> configured to protect.  Instead of storing the hash measurement as an
>>>>> extended attribute, the file hashes could be loaded in kernel memory, as
>>>>> long as the appraise policy is appropriately constrained.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> Hi,
>>>>
>>>> Maemo integrity protection solution was based on old DigSig project
>>>> which was used to verify
>>>> integrity of executables. Signed integrity measurement was embedded to
>>>> the ELF header.
>>>> When we started to develop it EVM was not available.
>>>>
>>>> And we decided to use a file to keep hashes and other info.
>>>>
>>>> Our goals were
>>>> 1. Protect also certain data files.
>>>> digsig worked only with ELF files.
>>>>
>>>> 2. Be mobile friendly
>>>> It seems faster to verify signature of one file with hashes instead of
>>>> checking signature of every EA.
>>>>
>>>>         
>>> Here Mimi can explain better because I am of the same opinion as yours
>>> if you mean that all signatures lie in one file and you check it from
>>> there. Anyways some sort of policy can reduce checking every EA ... I
>>> guess.
>>>
>>>
>>>       
>>>> 3. Persistant to offline attacks
>>>> EA can be delete. If not all files has EA then it is not possible to
>>>> detect removal
>>>>
>>>>         
>>> Availability of EA on all file systems needs some effort but it's not
>>> a big deal. I have even seen patches for yaffs2.
>>>
>>>
>>>       
>> The issue was removal.
>>     
> EA is a filesystem functionality and if the attributes get deleted or
> tampered than EVM will report is as un-trusted. I haven't done
> practical work on EVM yet but this is how it should be. Mimi can
> clarify this.
>
>   
>>>> 4. Do not use EA.
>>>> IIRC it was some problems with EA on our system and we could not use them..
>>>>
>>>>         
>>> This is a bad excuse :)
>>>
>>>
>>>       
>> Yes. not so convincing...
>>     
>>>> EVM looks very interesting and I would like also to review the code and
>>>> understand the architecture.
>>>>         
> It is very odd that you guys are unaware of what is opensource since a decade!
>
>   
>>>> We consider possibility to use EVM if it is going to be in the kernel.
>>>>
>>>>         
>>> Please do have a look because we need these features too but in a
>>> light weight manner. We are trying to make available similar
>>> functionality for OpenMoko based software stacks.
>>>
>>>
>>>       
>>     
>
>
>   
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists