Hi Marcel, To the issue, It is trouble for distro bluez to the Smack-enabled system. (Many issues are related with the issue in Smack-enable system, such as HID can't work and so on) Patrick and Casey(the Smack architect) had a talk about how the program touch /proc and /sys when it run on a Smack-enabled system. Casey has some ideas about the topic for Smack-enabled system: "Turning off privilege is a great thing to do *so long as you don't really need the privilege*.In this case you really need it. The application package isn't written to account for Smack's use of CAP_MAC_OVERRIDE as the mechanism for controlling this dangerous operation. Yes, it would be possible to change /proc to change the Smack label on that particular file, but that might open other paths for exploit. I say give the program the required capability. The program maintainer may well say change the kernel handling of /proc. You're stuck in the middle, as both work the way they're intended and hence the system doesn't work. :( There isn't a way to make this work without "loosening" something." When we run the program with CAP_MAC_OVERRIDE, the whole reason for having capabilities is so the we can give a process the ability to bypass one kind of check without giving it the ability to bypass other, unrelated checks. A process with CAP_MAC_OVERRIDE is still constrained by the file mode bits. We was overly worried about granting that capability. When it has no other effect than excluding a process from Smack MAC enforcement, then adding to the process seems like the right solution for now. The conclusion from Patrick and Casey is that this is the solution preferred by the Smack architect. Best Regards Zheng Wu -----Original Message----- From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx] Sent: Friday, July 8, 2016 5:08 PM To: Zheng, Wu <wu.zheng@xxxxxxxxx> Cc: open list:BLUETOOTH DRIVERS <linux-bluetooth@xxxxxxxxxxxxxxx> Subject: Re: [PATCH] Fix bluez5 capabilities for Smack setup Hi Wu, > Recent bluez5 releases started limiting the capabilities of > bluetoothd. When running on a Smack-enabled system, that change has > the effect that bluetoothd can no longer create the input device under > /sys because bluez5 running with label "System" has no write access to > that. > > It works when running as normal root with unrestricted capabilities > because then CAP_MAC_OVERRIDE (a Smack-specific capability) allows the > process to ignore Smack rules. > > We need to ensure that bluetoothd still has that capability. > --- > src/bluetooth.service.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/bluetooth.service.in b/src/bluetooth.service.in index > f799f65..1b0fead 100644 > --- a/src/bluetooth.service.in > +++ b/src/bluetooth.service.in > @@ -10,7 +10,7 @@ ExecStart=@libexecdir@/bluetoothd NotifyAccess=main > #WatchdogSec=10 > #Restart=on-failure > -CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE > +CapabilityBoundingSet=CAP_MAC_OVERRIDE CAP_NET_ADMIN > +CAP_NET_BIND_SERVICE this looks like the big hammer approach. I think if this is needed, then the Smack policies are just wrong. Why not fix them instead of punching such a big hole into it. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
