From: Shaz on
On Wed, Jun 2, 2010 at 12:03 PM, Dmitry Kasatkin
<dmitry.kasatkin(a)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.

>> 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.

> 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 :)

> EVM looks very interesting and I would like also to review the code and
> understand the architecture.
> 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.

--
Shaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Kasatkin on

On 02/06/10 10:50, ext Shaz wrote:
> On Wed, Jun 2, 2010 at 12:03 PM, Dmitry Kasatkin
> <dmitry.kasatkin(a)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.

We go approval from company layers to open source the work.
We will see what to do next.

>>> 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.
>> 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.
>> 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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Shaz on
On Wed, Jun 2, 2010 at 2:12 PM, Dmitry Kasatkin
<dmitry.kasatkin(a)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(a)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!

> 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.
>>
>>
>



--
Shaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Kasatkin on


On 02/06/10 13:15, ext Shaz wrote:
> On Wed, Jun 2, 2010 at 2:12 PM, Dmitry Kasatkin
> <dmitry.kasatkin(a)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(a)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.
>>>
>>>
>>>
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mimi Zohar on
On Wed, 2010-06-02 at 12:12 +0300, Dmitry Kasatkin wrote:
> On 02/06/10 10:50, ext Shaz wrote:
> > On Wed, Jun 2, 2010 at 12:03 PM, Dmitry Kasatkin
> > <dmitry.kasatkin(a)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.
>
> We go approval from company layers to open source the work.
> We will see what to do next.
>
> >>> 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.

Yes, verifying one file containing the hashes would be faster than
verifying individual hashes stored as extended attributes (xattrs), but
this does not take into account that files on a running system are being
modified or added. On a small form factor, the number of files is
limited, but would this scale well? In addition, what protects that one
file containing all the hashes from being modified? So, if you limit
the types of files to those that don't change, and the number of file
hashes, then using a single file would be faster.

> >> 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.

Yes, exactly. The original EVM required that all files be labeled.
Anything unlabeled was untrusted. The current implementation is based
upon policy with the default policy being to only appraise all files
owned by root.

> >> 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.
> >> We consider possibility to use EVM if it is going to be in the kernel.

Am looking forward to your questions/comments.

> > 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.

Glad to hear it.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/