combining trusted/security layers


Trevor Woerner
 

Hi everyone, and thanks for all the feedback that's been given already.

I think it would be a great idea if we could get the various trusted/security
layers working together on one layer instead of having separate efforts. As
far as I'm aware, there are currently 3 such layers:

meta-measured (http://layers.openembedded.org/layerindex/branch/master/layer/meta-measured/)
meta-security (http://layers.openembedded.org/layerindex/branch/master/layer/meta-security/)
meta-secure-core (http://layers.openembedded.org/layerindex/branch/master/layer/meta-secure-core/)

I personally am most familiar with meta-measured, and I'm mostly only
interested in tpm2 on an RPi3B+.

In an effort to try to help gather the data required to jumpstart this
conversation, I've created a simple google doc that lists these three layers,
their recipes, and provides the results of building against 2 MACHINEs:

intel-corei7-64 (from meta-intel)
raspberrypi3 (from meta-raspberrypi)

https://docs.google.com/spreadsheets/d/1AlH0Q0lGC3idwyFLSt7df09sIXkBuv191fVESUA-oQY/edit?usp=sharing

Please have a look. This spreadsheet is very simple, and only looks at
recipes, it does not include any information about various bbappends, nor
kernel configurations, packagegroups, classes, sample images, etc...

meta-measured is a plain, straight-forward layer that contains recipes.

meta-security contains recipes, but also contains 2 sub-layers:
- meta-tpm
- meta-security-compliance

meta-secure-core is a meta-layer, containing no recipes itself, but collecting
together a set of sub-layers:
- meta
- meta-encrypted-storage
- meta-integrity
- meta-efi-secure-boot
- meta-ids
- meta-signing-key
- meta-tpm
- meta-tpm2

From what is presented in the spreadsheet, in my opinion, I don't think it'll
be too hard to get everything in one layer. Surprisingly, there isn't a lot of
overlap. Therefore, all the unique bits from each layer can simply be added to
the one chosen layer. The only real overlap is in the tpm stuff, and that
should be easy to update once in the chosen layer.

The easiest way to combine the layers would be to make meta-security another
sub-layer of meta-secure-core. But I think that might be too simplistic.
meta-security includes a hodgepodge of user-space tools and daemons for
doing miscellaneous security things (recipes-security). meta-secure-core tries
to break logical activities into their own layers (i.e. meta-ids for intrusion
detection systems, meta-integrity for integrity measurement architecture
(ima), etc). If it would be possible to categorize all of the recipes in
meta-security's recipes-security directory, then maybe we could start
distributing them into meta-secure-core and/or creating spaces for them?

Thoughts?

Best regards,
Trevor


Randy MacLeod
 

On 05/24/2018 05:26 PM, Trevor Woerner wrote:
Hi everyone, and thanks for all the feedback that's been given already.
I think it would be a great idea if we could get the various trusted/security
layers working together on one layer instead of having separate efforts. As
far as I'm aware, there are currently 3 such layers:
...
From what is presented in the spreadsheet, in my opinion, I don't think it'll
be too hard to get everything in one layer. Surprisingly, there isn't a lot of
overlap. Therefore, all the unique bits from each layer can simply be added to
the one chosen layer. The only real overlap is in the tpm stuff, and that
should be easy to update once in the chosen layer.
The easiest way to combine the layers would be to make meta-security another
sub-layer of meta-secure-core. But I think that might be too simplistic.
meta-security includes a hodgepodge of user-space tools and daemons for
doing miscellaneous security things (recipes-security). meta-secure-core tries
to break logical activities into their own layers (i.e. meta-ids for intrusion
detection systems, meta-integrity for integrity measurement architecture
(ima), etc). If it would be possible to categorize all of the recipes in
meta-security's recipes-security directory, then maybe we could start
distributing them into meta-secure-core and/or creating spaces for them?
Thoughts?
Add Jia, who I've been talking with about our discussion on the
YP tech call yesterday. Hopefully he'll get his email situation
fixed and can carry on without me being a relay node.


Email from Jia:

My email client has a filter problem on receiving emails from gmail for
unknown reason (not a proxy issue) so I cannot directly reply him. Could
you do me a favor to copy my reply to thereļ¼Ÿ

-- reply --

I'm pleasure to see this move. And it sounds great to combine all in one
with a unified design model. Meanwhile, it is effective to avoid the
duplication works on maintainability. Additionally, it also gives a
fine-grained degree on the selection of a subset of feature from the big
one.

Categorizing the recipes in meta-security may be the hardest work in the
whole move. I take a quick glance at the list (thanks for Trevor!) and a
big catalog would be penetration test (meta-penetration-test?). We need
more catalogs to cover the remaining tools. Definitely, the naming
scheme for me is a challenge.

Regarding meta-tpm1/2, we could consider to cherry pick one among the 3
layers as the baseline and move the trivial parts in recipe from other 2
layers into the baseline. Other conflicting recipes would follow the
same methodology.

Thanks,
Jia

--
# Randy MacLeod
# Wind River Linux


Trevor Woerner
 

Hi Randy,

Thanks for relaying, and continuing the conversation.

On Wed 2018-06-06 @ 05:44:41 PM, Randy MacLeod wrote:
Email from Jia:

Categorizing the recipes in meta-security may be the hardest work in the
whole move. I take a quick glance at the list (thanks for Trevor!) and a
big catalog would be penetration test (meta-penetration-test?). We need
more catalogs to cover the remaining tools. Definitely, the naming
scheme for me is a challenge.
Okay. I can create a meta-penetration-test or meta-pentesting layer in my fork
of Jia's meta-secure-core and start putting the relevant recipes of that
category there to see what others think.

meta-secure-core already has a meta-ids (intrusion detection system) layer, so
I can look through meta-security's list to see which ones apply to that
category also.

When done, if the remaining recipes don't fit into any obvious category, I'll
poke this list again (or bring it up in the calls) to get others' feedback.

Regarding meta-tpm1/2, we could consider to cherry pick one among the 3
layers as the baseline and move the trivial parts in recipe from other 2
layers into the baseline. Other conflicting recipes would follow the
same methodology.
I have a WIP branch here with my work updating and bringing the latest TPM2
stuff into meta-secure-core. It's hung up now because, for the git recipes,
the Intel people are dlopen()'ing raw .so files, and I'm trying to get them to
rectify this before their next API-changing release of their latest TSS
libraries:

https://github.com/twoerner/meta-secure-core/tree/contrib/twoerner/tpm2-recipe-updates

Thanks!


Trevor Woerner
 

On Thu, Jun 7, 2018 at 9:06 AM, Jia Zhang <zhang.jia@...> wrote:
You remind me that I also need to modify cryptfs-tpm2 to interface the
new ldr API.

That would be awesome!! I am very interested in your cryptfs-tpm2 project and would like to see it working again.