[agl-discussions] RFC - Security Framework for AGL

[Jeremiah Foster]

On Tuesday, September 22, 2015, Fulup Ar Foll <fulup.arfoll at iot.bzh> wrote:

> I'm not sure I want to debate to much about security culture  :-) . While
> I agree with Jeremiah that security is a unique domain that impacts almost
> everything; I nevertheless support Walt in the idea that we need clear
> milestones to move forward; and the first structural decision we need to
> start moving is: "SMACK versus SELINUX ?"
>

This is arbitrary. Why no discussion of AppArmour or TOMOYO?

>
>
> During last AMM I committed to produce a document about the lessons my
> team learned from implementing Tizen security model. Hopefully we should be
> able to push this document on the list before the end of the week. Then for
> people to make there own opinion, I would suppose that most of us will
> agree that a dedicate developer call on the subject should be more than a
> good idea.
>
> This being said, final decision for a security model cannot remains 100%
> technical. Political and marketing arguments might be at least as strong as
> technical ones.
>

I would argue political decisions are counter-productive with regards to
security, but it seems you've already made up your mind.

Cheers,

Jeremiah


>
> Fulup
>
> On 22/09/2015 09:37, Jeremiah Foster wrote:
>


>
>
> On Tue, Sep 22, 2015 at 2:41 AM, Walt Miner <wminer at linuxfoundation.org
> <javascript:_e(%7B%7D,'cvml','wminer at linuxfoundation.org');>> wrote:
>
>> I am officially opening a thread to comment on potential security
>> frameworks. During the All Member Meeting there was a discussion on how
>> proceed with security for AGL. Those discussions were documented in [0].
>> The frameworks mentioned during the meeting were SELinux and SMACK. This
>> discussion is open to any other frameworks that are relevant as well.
>>
>
> Great that this discussion is taking place. Gunnar has done some extensive
> work delving into SMACK, hopefully he'll participate here.
>
>
>> How to proceed. I would like to wrap this topic up by Nov 17. I suggest
>> the following schedule
>> a) Nomination of frameworks and open discussion on this email thread.
>> Close discussion on October 5.
>> b) Determine selection criteria and weighting for decision matrix. We can
>> start a new thread for that. Oct 1 - 15
>> c) Score frameworks Oct 17 - 31.
>> d) Final decision Nov 1
>>
>
>
>> Obviously I built in a couple of weeks of slack time. Please comment if
>> you think I am missing some steps or the timing is off.
>>
>
> I have some (hopefully) constructive criticism here; I don't think that
> squeezing security topics into a deadline is productive. Security is a
> culture, not merely a set of patches.
>
>
>> More than likely this will be a topic of discussion on one or more
>> Tuesday developer call and/or SAT meeting.
>>
>
> Please forgive me if this sounds like a rant, I really do not want to
> rant, but I hold some fairly strong opinions regarding security. It really
> won't fit into a couple of SAT discussions. If, as the cliche goes,
> security is a culture, then security needs to be thought of during the
> design phase of a given system. It is an anti-pattern to rely on patches
> later. You want the system architects to be able to understand their
> domains well enough so they can spot security holes in the design phase.
> Look at the design and implementation of kdbus for example, that is the
> kind of security posture you need to have to ensure security is designed
> into the system.
>
> Also, there needs to be discussion on many more topics than just a MAC
> tool. Security will require experts, in both automotive and GNU/Linux, who
> can elucidate best practices and proper, testable configuration. You'll
> want to have an interface to the HSM that is as hardware independent as
> possible, up to date information on ciphers and HMAC algorithms, PKI,
> vulnerability reporting, bug embargo policy, responsible disclosure policy,
> intrusion detection, a threat model, and path to mitigation when exploits
> and/or privilege escalation is found. There is no alternative to a holistic
> security discussion since missing one piece may lead to catastrophic
> failure.
>
> Regards,
>
> Jeremiah
>
> --
> Jeremiah C. Foster
> GENIVI COMMUNITY MANAGER
>
> Pelagicore AB
> Ekelundsgatan 4, 6tr, SE-411 18
> Gothenburg, Sweden
> M: +46 (0)73 093 0506
> jeremiah.foster at pelagicore.com
> <javascript:_e(%7B%7D,'cvml','jeremiah.foster at pelagicore.com');>
>
>
>
>
> _______________________________________________
> automotive-discussions mailing listautomotive-discussions at lists.linuxfoundation.org <javascript:_e(%7B%7D,'cvml','automotive-discussions at lists.linuxfoundation.org');>https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
>
>
>

-- 
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +46 (0)73 093 0506
jeremiah.foster at pelagicore.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20150922/06e9be56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PELAGICORE_RGB_Black_horizontal.png
Type: image/png
Size: 11841 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20150922/06e9be56/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11841 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20150922/06e9be56/attachment-0003.png>