[agl-discussions] RFC - Security Framework for AGL

Avila Risto risto.avila at theqtcompany.com
Wed Sep 23 04:28:01 UTC 2015


Hi,


Maybe we could have the same approach as other distributions e.g. let the end user to decide.


Over all our packing should provide recipes for all the proposed security frameworks. If we want to support one we also provide basic policy definitions for that with a separate recipe so that's it is easy to end user to configure if they want to change it.


Personally I'm not quite seeing why we need such framework at all. In general secure code is done by tier1 and they would need to anyway give exception to any framework and if there are "free" 3rd party applications those would be sand boxed as per users are in general Linux.


Threats that I currently see for automotive is

1. Coming from  wire & wireless connections

2. Hacking the hardware it self e.g. replacing the whole emmc --> preventing this would work from chip manufacturers. They would need to enable arm secure boot and implement security verification starting from on-chip ROM code.

3. Kernel exploits from user space. These are currently a problem with e.g. phones that you can circumvent the security by a kernel exploit e.g. have a custom firmware installed with this style approach none of the security frameworks would help since it's a local attack with root access meaning that they can just disable the framework altogether.

4. The software done by the manufacturer & tier1. After couple of demos and architectures that are done by car manufacturers and tier1 I would say that this is the biggest risk of all. Security aspects of the designs were bare minimum meaning that there were no threat analysis of any kind and you could simple spot from the diagrams where you could attack easily.


Point 4 comes to same conclusion that Jeremiah already said security is not about framework it's more about design principle. Now if we already ship with fully working security framework and state that we have security enabled it would give false messages to developers from manufacturers and tier1's that they would not need to think about security. This is the reason why I propose that we provide recipes to all different frameworks that we see fit and enable none of these by default.


Best regards,


Risto Avila

Consultant | The Qt Company

qt.io | blog.qt.io

________________________________
From: automotive-discussions-bounces at lists.linuxfoundation.org <automotive-discussions-bounces at lists.linuxfoundation.org> on behalf of Jeremiah Foster <jeremiah.foster at pelagicore.com>
Sent: Wednesday, September 23, 2015 12:56 AM
To: Fulup Ar Foll
Cc: automotive-discussions at lists.linuxfoundation.org
Subject: Re: [agl-discussions] RFC - Security Framework for AGL



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

[X]



_______________________________________________
automotive-discussions mailing list
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<mailto:jeremiah.foster at pelagicore.com>

[X]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20150923/c2bbf652/attachment.html>


More information about the automotive-discussions mailing list