The README states docker must be run with --privileged

[tonyespy]

The README file states that a docker container of device-bluetooth-c must be run via the following command:

docker run
-v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket
--privileged -p 49971:49971 device-bluetooth

In general, we should avoid use of the "--privileged" option as it basically disables confinement. Ideally docker should be run with the minimum extra options that allow the device service to function.

Why is use of --privileged required?

[LukeKerr]

The D-Bus system_bus_socket is by default owned by root. Having privileged allows access to the socket inside the Docker container. The Docker Linux Capabilities might work better to limit the root access to just this one socket.

[SteveOss]

The dbus socket is "srw-rw-rw-" so everyone has read/write access, so why does the container need to run privileged ?

[LukeKerr]

Running the Docker container without --privileged gives the following error message.

[D-Bus] org.freedesktop.DBus.Error.AccessDenied An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)

[SteveOss]

@Dylsic Is it possible to modify the apparmor rules to allow access ?

[LukeKerr]

@SteveOss Unsure at the current moment. I will have to investigate it further as it isn't clear to me whether D-Bus or BlueZ that creates the policy.

[anonymouse64]

The AppArmor restriction doesn't come from D-Bus or BlueZ, it comes from docker, when you run with --privileged you are removing all AppArmor confinement. @SteveOss is correct in that you can modify the AppArmor rules with a docker option, see https://docs.docker.com/engine/security/apparmor/ for more details.

@Dylsic do you see any denials in the system journal with journalctl -e --no-pager | grep DENIED when you run without --privileged? That should give a bit more context about what accesses are needed. If you need help writing AppArmor policy for this, let me know, but we need to know what AppArmor denied in order to write the policy.

[LukeKerr]

@anonymouse64 I would appreciate your help with writing an AppArmor policy. I've run the Docker container without --privileged, followed by the journalctl -e --no-pager | grep command.

Sep 13 10:38:42 dell audit[985]: USER_AVC pid=985 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=12768 label="docker-default" peer_label="unconfined" Sep 13 10:38:42 dell kernel: audit: type=1107 audit(1568367522.859:50): pid=985 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=12768 label="docker-default" peer_label="unconfined"

[anonymouse64]

So that snippet you posted is actually the same denial being logged twice (from apparmor and from the kernel), the relevant bits are:

operation="dbus_method_call"
bus="system"
path="/org/freedesktop/DBus"
interface="org.freedesktop.DBus"
member="Hello"
mask="send"
name="org.freedesktop.DBus" 
label="docker-default"
peer_label="unconfined" 

which effectively means that a process running under the label docker-default (i.e. your container) tried to send a message to the system bus via DBus with path /org/freedesktop/DBus on member Hello with interface org.freedesktop.DBus. If you applied the apparmor rules I have at the bottom that would probably allow this Hello to continue, however you will run into further denials after this Hello is allowed, since the Hello is really just to see if DBus is allowed or not (in this case it was not so it didn't try the real accesses it needed).

I'll post again in a bit with an example command line option to docker to apply this

[FraserG01]

An AppArmor Security policy has been included for users to apply to their systems to run the DS without the --privileged flag. This will only work on Linux distributions that use AppArmor as their Linux kernel security module though

I have been trying to figure out something similar for Linux distributions that use SELinux but have had no luck as of yet. Even with the --privileged flag the DS fails to contact Dbus when SELinux is enabled.

[tonyespy]

I think you should just add a disclaimer to the top-level README that says it's only possible to run this device service fully confined on distros with AppArmor enabled (maybe listing a few), and that at this time, this device service is not supported on any distro with SE Linux enabled by default (I actually wonder if anyone has done a full test of EdgeX on SE Linux?). I'd also file a bug specifically for the issue that the service can't be run on an SE Linux enabled distro (even with --priviledged specified), and close this issue.

[tonyespy]

Closing this as it's been addressed in the latest update to the README.

[er1z]

Just want to say thanks for this issue; I successfully managed to expose a printer to CUPS container with your profile with little adjustment.