On Thu, Jun 10, 2010 at 8:07 PM, Janne Karhunen <[email protected]>wrote:
> On Thu, Jun 10, 2010 at 4:55 PM, Shaz <[email protected]> wrote: > > >> Task can hold tokens named 'Calendar' and 'Phonebook' for > >> accessing these interfaces. Or, we can drop this even > >> lower by saying Calendar::function and everything else is > >> not granted for. > > > > This is where dbus comes in ... right? > > Well we do DBUS and plain sockets for starters. > > > > And now I am loosing what LSM and rbac does here :) > > Credential assignment and such mostly. > > > >> > Do you maintain the rights on the client platform? > >> > >> Policy enforcement is done by the server being accessed. > >> Credential assignment happens per-task basis and during > >> exec. > > > > Got it. You mean session of active resource is given the credential > > accordingly. How can you handle client side and server side service > mashups > > with this theme? > > What's the issue with it? We have quite flexible token > setup that allows pretty much anything to be labeled. > Moreover, our needs are quite simple in this sense, > we're not really trying to compete with selinux kitchen > sink. > > How can we fit this in TCG MPWG and OMTP TR0/1 specs? I think we need a kitchen sink with a light weight policy then what SELinux offers but the infrastructure that SELinux provides is very mature and accepted even if you do not agree. I can also see here that DAC (Linux and Dbus) and MAC (LSM based) standard definitions get faded here because the device called as a single user by MAEMO security is indeed a multi owner device where user is one of the stakeholder while the manufacturer, operator and third party service providders are all the owners in some way. We have simply a hybrid model. Conceptually it sounds very wierd but technically nothing changes apart from the way you configure the permission. And indeed this is the business model that is needed at the moment. Consider a use-case where an organization/enterprise would want to deploy the mobiles in such a way where services can be openly provisioned and at the same time the policies can be managed in a way that that will take care of the rights of all the stakeholders! Does Maemo 6 security have the features to handle this sort of thing? SELinux can do it as I have personally used it for experiments of the sort but I do agree that the policy structures are heavy for a mobile device. Credentials and tokens cannot provide manageable/appropriate semantics either! Secondly, I do agree that EVM is not very suitable for trustzone but what is more suitable? In my opinion a single file protected by secure/trusted boot and sealing can handle this considering using something like the MTM/TPM emulator. Putting the attributes on EA is very heavy while one file scales good enough for a mobile device with known or limited sensitive resources. Again I have no idea where the Maemo 6 security feature RBAC fits in? As far as I can understand replacing the kitchen sink policy model with rbac might be a good idea. Let me think about it. Hope this is clear enough. -- Shaz
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
