> -----Original Message----- > From: Dominig ar Foll (Intel OTC) [mailto:[email protected]] > Sent: Wednesday, November 19, 2014 10:01 AM > To: Schaufler, Casey; [email protected] > Cc: 'Tomasz Swierczek'; Rafal Krypa; Whiteman, John L > Subject: Re: [Dev] transferring files from and to a service > > > Le 19/11/2014 17:24, Schaufler, Casey a écrit : > > I assume that the same Bluetooth process that serves Bob also serves > > Carol, Ted and Alice. If there was a separate Bluetooth process for each > > user it would run with the user's UID, not the Bluetooth UID.
> No there is only one bluetooth process run as a service for all user. > > > > What you have here is the privilege conundrum. You want to limit > > the amount of privilege you give out, which is good. At the same > > time, you want to allow the Bluetooth daemon to manage user files. > > Managing other user's files requires privilege. If you give Bluetooth > > privilege to do that, you have to trust that it will do so correctly. > > Given the size and complexity of Bluetooth, that's a lot of trust. > That why we do not want to give the provilege to bluetooth but rather > have the security manager to take in charge the transfer. > > > > The temptation is to create a piece of software that "takes care of" > > the user file management so that Bluetooth doesn't have to run > > with privilege. Unfortunately, this adds to the size and complexity > > of Bluetooth in addition to introducing yet another mechanism that > > might be exploited. > We have the security manager already serving that need in similar domains. > > There, I'm done ranting. > > > > Yes, we could have a user-file-manager daemon that does user > > file management on behalf of other services. It would use Cynara > > to identify the services (using Smack label and UID) requesting > > operations. It would have just enough privilege to perform its > > duties, CAP_DAC_OVERRIDE but not root for example. It could > > provide rename, chown, chmod and other similar services. Hmm, > > thinking about it, it seems pretty consistent with the application > > privilege model. APIs could be provided by security-manager. > That was but the idea. > > > > I'm still concerned about the changes required to Bluetooth > > to utilize the facility, but that's probably easier than a full blown > > security analysis of Bluetooth running as root. > We are in Sync but we need a solution :-) The first step is to define what facilities need to be provided. You might even propose the APIs Bluetooth would like to have. Tomasz's team can't anticipate what you want to do. You have to tell the security manager developers what you'd like provided. > Dominig ar Foll > Senior Software Architect > Open Source Technology Centre > Intel SSG > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
