Hi Jeremiah, I am not up to speed with the latest regarding Security FW in MeeGo, but what you say sounds like MeeGo IVI could not utilize the existing security FW in MeeGo (note, if there's even such a thing anymore?). Of course, MeeGo IVI has probably even stronger security requirements than, say, netbook or TV so if there isn't something already available in MeeGo or some security feature is missing, then IVI needs to do add that to existing solutions on in the worst case come up with our own solution.
Or I can also read your text in a such way that every API user should take care of the security themselves and MeeGo IVI shall not contain ready-made security features. A bit more clarification around security and MeeGo IVI could maybe be in place before we start crafting Qt APIs. Cheers, Johan On Wed, Aug 3, 2011 at 12:45 PM, Jeremiah Foster <[email protected]> wrote: > Hi, > > There are a number of rather sophisticated tools in Linux to do this > type of privilege separation. One of them is called SE Linux which is > "Security Enhanced Linux", that might be more than you need in an > embedded environment. The technology I'd recommend looking at is > something called Linux Containers (LXC). Containers take advantage of > cgroups which are extremely powerful ways to control access to the > CPU, memory, network interface, etc. "LXC builds up from chroot to > implement complete virtual systems, adding resource management and > isolation mechanisms to Linux’s existing process management > infrastructure." More here: http://lxc.sourceforge.net/ > > If you're looking to cordon off different parts of your APIs and > functionality, without dropping into paravirtualization or a hyper > visor, you should look closely at cgroups and containers. > > Regards, > > Jeremiah > > 2011/8/3 <[email protected]>: >> Hello, >> >>>That being said, access control would be an important part of the system. >>>I'm not sure yet how that could be achieved but it must be kept in mind >> when designing the overall architecture. >> >> At this moment, access control to APIs is described as follows: >> http://wiki.meego.com/In-vehicle/Roadmap/API#Security >> >> But I'm also not sure what's going on in the latest status of MeeGo >> security. Does anybody know of it? >> I also think we should have access control to critical information. >> If it's not covered by MeeGo security mechanisms, then we may need to >> consider some extension for MeeGo IVI. >> >> >> Best regards, >> Tatsushi Yamamoto >> >> ======================== >> DENSO COPORATION >> Tatsushi Yamamoto >> mailto:[email protected] >> >> >> >> >> Romain KUNTZ <[email protected]> >> 送信者: [email protected] >> 2011/08/03 09:31 >> >> 送信者: >> [email protected] >> 宛先 >> Josef Raschen <[email protected]> >> cc >> [email protected] >> 件名 >> Re: [MeeGo-ivi] IVI Car-Systems APIs >> >> >> >> >> >> >> Hello Josef, >> >> I'm also interested in the definition of an in-vehicle API. Before >> defining the details of such an API, I'd be interested in discussing a >> more high-level classification. >> >> First, we should define who would be the API users? I believe the >> definition of the API will fall into multiple categories depending on who >> would use it. For example : >> - car manufacturer & Tier-1 suppliers who would be able to access/write >> critical information (e.g. for diagnostic / information collection >> purposes), >> - affiliated developers (e.g. the ones providing applications shipped with >> the head-unit, which would need raw information such as the ones for GPS >> dead reckoning), >> - "any" developper (which may need already processed information). >> >> Some of the API might not be available to all of the actors, or read/write >> access may be different for each of them. >> >> That being said, access control would be an important part of the system. >> I'm not sure yet how that could be achieved but it must be kept in mind >> when designing the overall architecture. >> >> Any comments? >> >> Thank you, >> -- >> Romain KUNTZ >> Toyota InfoTechnology Center >> [email protected] >> >> On Jul 26, 2011, at 15:02, Josef Raschen wrote: >> >>> Hi, >>> >>> I tried to work on the car-systems function-list: >>> >> https://spreadsheets.google.com/spreadsheet/ccc?key=0AumR8Pg5Sy05dEpBRTlvZ0VuWTh4V05NNTRHWXBIWXc&hl=en_US >> >>> >>> This is based on the version from the wiki with some new functions and >> some regrouping. I also changed the personalization settings. I think we >> should differentiate between a saved state of a system (connected with the >> id of the key) and the set/get functions of the systems. >>> >>> Josef >>> _______________________________________________ >>> MeeGo-ivi mailing list >>> [email protected] >>> http://lists.meego.com/listinfo/meego-ivi >> >> >> >> _______________________________________________ >> MeeGo-ivi mailing list >> [email protected] >> http://lists.meego.com/listinfo/meego-ivi >> >> >> >> >> _______________________________________________ >> MeeGo-ivi mailing list >> [email protected] >> http://lists.meego.com/listinfo/meego-ivi >> > > > > -- > ============================================= > Jeremiah C. Foster > Open Source Technologist > Pelagicore AB > Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden > Mobile: +46 (0)730 93 0506 > E-Mail: [email protected] > ============================================= > > === NOTE === > The information contained in this E-mail message is > intended only for use of the individual or entity > named above. If the reader of this message is not > the intended recipient, or the employee or agent > responsible to deliver it to the intended recipient, > you are hereby notified that any dissemination, > distribution or copying of this communication is > strictly prohibited. > ============= > _______________________________________________ > MeeGo-ivi mailing list > [email protected] > http://lists.meego.com/listinfo/meego-ivi > _______________________________________________ MeeGo-ivi mailing list [email protected] http://lists.meego.com/listinfo/meego-ivi
