I wrote: >> a pub-sub (server-client) model of communication is adequate.
(Justin Park) [email protected] writes: > Agreed. And in my opinion, Signal-Slot mechanism of Qt is good for it. >> they need from a database or XML log, they need not communicate with the producer at all. > I'm not sure that how it can be fit to publish-subscribe pattern. The point is that there are many methods for IPC and those that look like pub-sub are likely to be more readily made secure than message-passing APIs. If messages that are stored in databases are checked against a schema or logfiles can only be written by processes that properly take a lock, then spoofing and intercepting messages become just a bit more cumbersome, especially if these entities are in files with Smack labels. Consider the analogy of a system that requires a user to reenter login name as well as password on every access attempt. The added security mechanism is trivial, but the effort to break in is something like exponential with the number of fields that must be filled, not linear. Of course saving an "unlock door" message to a database would be stupid. That's when we want Signal-Slot. Saving and restoring a commonly used navigation route between two points would make sense, though, and presents an opportunity for extra checks. >> User abstraction - multiple inputs and displays > Car System APIs must be protected in fine-grained policy, thus traditional > multi-user based security policy is insufficient. UID-based access control is insufficient but still useful. The authoritative document http://wiki.meego.com/Security/Architecture says that "currently most MeeGo devices are considered to be single-user devices." This statement is false for the IVI use case, which *is* multi-user. Certain coarse-grained policies are applicable to IVI: the driver and the other passengers are fundamentally different. Why not therefore employ the mechanisms that come along with the Linux kernel? Note that the authoritative source continues: "Kernel Enforcement - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels." Of course, rather than have users login, we would just consider that persons interacting with different displays and input devices are distinct users. Thus the backseat passengers can read email while the car is in motion, but the driver can't. The driver can change the destination of the routing software of the navigation system, but the passengers cannot, etc. > Even though an application is executed by the same user, it should have > different privilege based on its origin. What do you mean by "origin" here? Assuredly applications controlled by the driver's phone are different than those based on the driver touching a screen on the dash. The whole question of voice versus touch versus gesture is interesting here. A child can potentially reach over and touch the driver's screen. Are we to implement voice recognition to prevent children from controlling some IVI functions? Gesture here may be the least subject to interference if the camera(s) are near the driver or in the backseat. -- Alison Chaiken (650) 279-5600 (cell) http://www.exerciseforthereader.org/ Spend much time at the cutting edge and you're liable to get cut. _______________________________________________ MeeGo-ivi mailing list [email protected] http://lists.meego.com/listinfo/meego-ivi
