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 :-)
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
