Messages in this thread | | | Date | Wed, 02 Jun 2010 13:23:00 +0300 | From | Dmitry Kasatkin <> | 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@nokia.com> wrote: > >> On 02/06/10 10:50, ext Shaz wrote: >> >>> On Wed, Jun 2, 2010 at 12:03 PM, Dmitry Kasatkin >>> <dmitry.kasatkin@nokia.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. >>> >>> >>> >> > > >
| |