Reshetova, Elena
2011-08-18 05:54:00 UTC
Hi,
Let me try to reply from a security side on the discussion below. I am sorry
for a late reply: I wasnt subscribed to this mailing list and this mail
came to me via redirection.
The link with the security architecture below is outdated:
<http://wiki.meego.com/Security/Architecture>
http://wiki.meego.com/Security/Architecture
This was indeed a solution that we planned to have for MeeGo, but it was
before Nokia stopped work from their side on security. So, MSSF isnt going
to be part of MeeGo. It was announced on meego-security mailing lists, but I
think we need to update the page as well. However, we are going to have
another security framework that would be able to provide a similar set of
features than mssf and in some cases we hope can be better than mssf, since
we are using our experience and lessons learned from its design. Some parts
in new framework will be quite similar: for example it will be also based on
Smack LSM for access control, we will also have a manifest in rpm package
where application needs are declared and etc. The new framework design is
in the progress now and this is really the best time to give us your
specific requirements and use cases to make sure that we can support them. I
am more than happy to help you defining them and any answer questions from
security side. That would also help me to get understanding of IVI security
needs more.
Best Regards,
Elena.
-----Original Message-----
From: meego-ivi-bounces-***@public.gmane.org
[mailto:meego-ivi-bounces-***@public.gmane.org] On Behalf Of ???(Justin Park)
Sent: Tuesday, August 09, 2011 3:29 AM
To: 'Jussi Vänskä'
Cc: meego-ivi-***@public.gmane.org
Subject: Re: [MeeGo-ivi] IVI Car-Systems APIs
Hello, IVI members,
I believe all members are well aware of the link below.
<http://wiki.meego.com/Security/Architecture>
http://wiki.meego.com/Security/Architecture
Although its pretty sure that IVI requires stronger security framework than
any other consumer devices, the purpose of security looks exactly same.
The thing we have to do is to clarify the requirement of IVI security system
and to find any possible lack from MSSF.
I have no idea that theres any car-only security requirement.
Even though my review was only at high level, MSSF looks enough for my
initial idea.
If we find any lack from MSSF, it would be better to ask it to MSSF team.
In my opinion, we need to provide consistent security mechanism to overall
MeeGo branches.
Its pretty bad thing to bring additional burden to developers for
IVI-specific (separated) security mechanism.
Thus, to add it, there must be a adequate reason.
I agree that all APIs need to be categorized for its consumer S/W. But it
can vary in OEMs.
So, it looks better to leave it to OEMs and to provide the way to configure
their own security level policy. MSSF supports it.
D-Bus discussion looks popular theme. Most people know the pros and cons of
it.
Of cause, its not the best solution for all purposes and especially to high
performance requirement.
Even though that, many Linux packages were built on it. Even MSSF uses it.
So, we need to investigate and prove whether D-Bus cant meet IVI
requirement or not in the real world.
When I proposed it, I supposed the APIs for downloadable applications rather
than embedded component applications.
In my opinion, we can use D-Bus as it is and adopt additional way for some
specific purposes such as DR.
For example, D-Bus is used for establishing connection between CAN adapter
and DR application.
After that they communicates with each other via some specific ways.
Regards,
Justin
p.s. Im sorry to cut in the discussion too late. I was on vacation.
Let me try to reply from a security side on the discussion below. I am sorry
for a late reply: I wasnt subscribed to this mailing list and this mail
came to me via redirection.
The link with the security architecture below is outdated:
<http://wiki.meego.com/Security/Architecture>
http://wiki.meego.com/Security/Architecture
This was indeed a solution that we planned to have for MeeGo, but it was
before Nokia stopped work from their side on security. So, MSSF isnt going
to be part of MeeGo. It was announced on meego-security mailing lists, but I
think we need to update the page as well. However, we are going to have
another security framework that would be able to provide a similar set of
features than mssf and in some cases we hope can be better than mssf, since
we are using our experience and lessons learned from its design. Some parts
in new framework will be quite similar: for example it will be also based on
Smack LSM for access control, we will also have a manifest in rpm package
where application needs are declared and etc. The new framework design is
in the progress now and this is really the best time to give us your
specific requirements and use cases to make sure that we can support them. I
am more than happy to help you defining them and any answer questions from
security side. That would also help me to get understanding of IVI security
needs more.
Best Regards,
Elena.
-----Original Message-----
From: meego-ivi-bounces-***@public.gmane.org
[mailto:meego-ivi-bounces-***@public.gmane.org] On Behalf Of ???(Justin Park)
Sent: Tuesday, August 09, 2011 3:29 AM
To: 'Jussi Vänskä'
Cc: meego-ivi-***@public.gmane.org
Subject: Re: [MeeGo-ivi] IVI Car-Systems APIs
Hello, IVI members,
I believe all members are well aware of the link below.
<http://wiki.meego.com/Security/Architecture>
http://wiki.meego.com/Security/Architecture
Although its pretty sure that IVI requires stronger security framework than
any other consumer devices, the purpose of security looks exactly same.
The thing we have to do is to clarify the requirement of IVI security system
and to find any possible lack from MSSF.
I have no idea that theres any car-only security requirement.
Even though my review was only at high level, MSSF looks enough for my
initial idea.
If we find any lack from MSSF, it would be better to ask it to MSSF team.
In my opinion, we need to provide consistent security mechanism to overall
MeeGo branches.
Its pretty bad thing to bring additional burden to developers for
IVI-specific (separated) security mechanism.
Thus, to add it, there must be a adequate reason.
I agree that all APIs need to be categorized for its consumer S/W. But it
can vary in OEMs.
So, it looks better to leave it to OEMs and to provide the way to configure
their own security level policy. MSSF supports it.
D-Bus discussion looks popular theme. Most people know the pros and cons of
it.
Of cause, its not the best solution for all purposes and especially to high
performance requirement.
Even though that, many Linux packages were built on it. Even MSSF uses it.
So, we need to investigate and prove whether D-Bus cant meet IVI
requirement or not in the real world.
When I proposed it, I supposed the APIs for downloadable applications rather
than embedded component applications.
In my opinion, we can use D-Bus as it is and adopt additional way for some
specific purposes such as DR.
For example, D-Bus is used for establishing connection between CAN adapter
and DR application.
After that they communicates with each other via some specific ways.
Regards,
Justin
p.s. Im sorry to cut in the discussion too late. I was on vacation.