> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Dominig ar Foll > (Intel OTC) > Sent: Wednesday, November 19, 2014 7:47 AM > To: [email protected] > Subject: Re: [Dev] transferring files from and to a service > > Le 19/11/2014 16:34, Schaufler, Casey a écrit : > >> >Some global service are offering API with > >> >filenames (as string) arguments that will > >> >be used by the service for reading or > >> >writing the given file. > > I think you may have identified the problem right there. > > APIs that deal with files by path name need to be aware > > of the possible restrictions on accessing those files. > > > > > Let takes the example of Bluetooth which is runing under the user bluetooth. > > When the user Bob request a file transfer, the user bluetooth will need > to access Bob file. > In a similar way; when a file is received by bluetooth, it will need to > be transferred to the home of the user who has paired the device sending > the file.
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. 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. 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. 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. 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. > Dominig ar Foll > Senior Software Architect > Open Source Technology Centre > Intel SSG > > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
