From: Wu Zheng <[email protected]>
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
LimitNPROC=1
ProtectHome=true
ProtectSystem=full
--
2.1.4
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 tou=
ch /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. :(=20
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=20
process the ability to bypass one kind of check without giving it the abili=
ty to bypass other, unrelated checks. A process with=20
CAP_MAC_OVERRIDE is still constrained by the file mode bits.
We was overly worried about granting that capability.=20
When it has no other effect than excluding a process from Smack MAC enforce=
ment, then adding to the process seems like the right solution for now.
The conclusion from Patrick and Casey is that this is the solution preferre=
d by the Smack architect.
Best Regards
Zheng Wu
-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]=20
Sent: Friday, July 8, 2016 5:08 PM
To: Zheng, Wu <[email protected]>
Cc: open list:BLUETOOTH DRIVERS <[email protected]>
Subject: Re: [PATCH] Fix bluez5 capabilities for Smack setup
Hi Wu,
> Recent bluez5 releases started limiting the capabilities of=20
> bluetoothd. When running on a Smack-enabled system, that change has=20
> the effect that bluetoothd can no longer create the input device under=20
> /sys because bluez5 running with label "System" has no write access to=20
> that.
>=20
> It works when running as normal root with unrestricted capabilities=20
> because then CAP_MAC_OVERRIDE (a Smack-specific capability) allows the=20
> process to ignore Smack rules.
>=20
> We need to ensure that bluetoothd still has that capability.
> ---
> src/bluetooth.service.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/src/bluetooth.service.in b/src/bluetooth.service.in index=20
> f799f65..1b0fead 100644
> --- a/src/bluetooth.service.in
> +++ b/src/bluetooth.service.in
> @@ -10,7 +10,7 @@ ExecStart=3D@libexecdir@/bluetoothd NotifyAccess=3Dmain
> #WatchdogSec=3D10
> #Restart=3Don-failure
> -CapabilityBoundingSet=3DCAP_NET_ADMIN CAP_NET_BIND_SERVICE
> +CapabilityBoundingSet=3DCAP_MAC_OVERRIDE CAP_NET_ADMIN=20
> +CAP_NET_BIND_SERVICE
this looks like the big hammer approach. I think if this is needed, then th=
e Smack policies are just wrong. Why not fix them instead of punching such =
a big hole into it.
Regards
Marcel
Hi,
On Fri, Jul 8, 2016 at 12:07 PM, Marcel Holtmann <[email protected]> wrote:
> 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.
+1, CAP_NET_ADMIN would have that capability since it is stated:
CAP_NET_ADMIN
Perform various network-related operations:
* interface configuration;
--
Luiz Augusto von Dentz
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