There are other authentication methods than password. In-Vehicles these days it is mostly by remote radio key fob (remote door unlock, remote engine start). That takes care of the driver authentication. For passengers it may need to be by NFC or pairing with mobile handset. In this case the authentication should help identify which seat (display) is associated with which user. We have one use where the user's personal mobile device uses QTAG to associate with the IVI display unit, which could also be an authentication path.
Regards Joel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ANUJ MISHRA Sent: Tuesday, March 18, 2014 8:39 PM To: Bumjin Im; [email protected] Subject: Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment Just a thought: Until now all devices used to boot with default user, so default user need not to enter password to access device profile. But, in case of multiuser environment default user should protect its account by password. Incase he forgets his password How easy for default user to recover/reset his own password? In same way, how difficult for another user not to break-in into device? Also, what will be the method to recover password for default user? In case of Linux environment, there is some method to recover root password, but it is very difficult. --Anuj Mishra ------- Original Message ------- Sender : Clark, Joel<[email protected]> Date : Mar 19, 2014 11:43 (GMT+09:00) Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment You can add to the list (for IVI devices at least) multiple 3G modems, Multiple BT modems, multiple SIM cards, multiple displays and connected to multiple handsets (smartphones) with simultaneous streaming of media by different users to the different displays, etc Regards Joel On Mar 18, 2014, at 7:25 PM, "Bumjin Im" wrote: > Never thought of such scenario that a device has multiple SD card slots for > different user. This will be another issue to track to. I don't have good > idea yet but I think we can make use of some daemons which take care of mount > and usb insertion with "some" policy. > > Bumjin > > -- May the Force be with you > ---------------------------------------------------- > * BumJin Im > * Senior Engineer, Mobile S/W Platform lab, S/W Platform Team > Samsung Electronics > ---------------------------------------------------------------------- > ----------- > > > > > ------- Original Message ------- > Sender : Jos? Bollo > Date : 2014-03-18 23:41 (GMT+09:00) > Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User > Environment > > On mar, 2014-03-18 at 00:22 +0000, ??? wrote: > >> For external memory cards, we are thinking that the use of links in >> the home directories is needed for applying quotas (see below page >> 7). Mounting memory cards would imply the creation/synchronisation of >> the links and of the data on the card. For example: >> on the card, should exists the directories: >> - /home/user1...usern >> - /opt/... >> and the main FS would have the links: >> - /home/user1/sdcard -> /mount/sdcard/home/user1 >> - /opt/sdcard -> /mount/sdcard/opt >> That is our draft idea. >> [Bumjin] My point was that the SDcard cannot be access controlled >> when it's plugged off and plugged in to window machine. If we cannot >> fully enforce, then we should untrust. >> That was the simple reason. > > You are right, I agree. Maybe was I confused between "external memory > card" and "device media storage". But part of the proposal may still > be accurate. > > I still think that if a user plug a memory SDcard or USBkey, its data > should not be shared by default. That use case is complicated. For > multi-seat configuration as what for IVI, the scenario is that the > device will be by default associated to the seat's user. > > Best regards > José > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
