You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to make docker work with the moby daemon confined by AppArmor.
Currently, when installing Docker on say Ubuntu with the deb package, the docker daemon is not confined by AppArmor and only the container processes are confined using the docker-default profile. I am interested in confining the daemon using AppArmor as well, for purposes of building docker using snaps.
The problem I have is that when you use AppArmor to confine the daemon and give the daemon all the access it needs, we have to patch the docker-default profile to allow signalling/ptracing by the daemon to the child containers because both processes are now confined by AppArmor and as such AppArmor will mediate if both ends of the ptrace/signal match the corresponding profile rules. So we can setup the profile for the daemon independently of the Moby project, but we need to modify the profile that containers run under, which is part of the Moby project.
To accommodate this, I propose generating unique AppArmor profile code for each new container, that includes the following additional rules:
# AppArmor confined daemon rules
# Allow the daemon to trace/signal containers
ptrace (readby, tracedby) peer="{{.DaemonProfileName}}",
signal (receive) peer="{{.DaemonProfileName}}",
# Allow container processes to signal other container processes
signal (send, receive) peer="{{.ProfileName}}",
}
This way, we have a unique profile name for all containers, and every container has it's own peer group that it can send/receive signals to. If we keep the current default name of docker-default for all containers, then there's an opportunity for separate containers to signal each other, because they will be in the same peer group. I'm not sure if this is still a vulnerability because the containers should still be in their own process namespace, but better to be on the safe side. This would also enable future work if other aspects of the default AppArmor profile for containers needs to be configured individually by default.
The ptrace/signal rule allowing a peer group of DaemonProfileName would be configurable probably only at build time, i.e. for the snap we would use a daemon profile name of snap.docker.dockerd, but other distributions may choose to use a different one.
Alternatively, we could make this snippet of AppArmor profile code not be used/generated if the build time flag specifies that the distribution isn't confining the daemon with AppArmor and then everything stays the same.
This discussion was converted from issue #37895 on September 16, 2023 23:33.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I would like to make docker work with the moby daemon confined by AppArmor.
Currently, when installing Docker on say Ubuntu with the deb package, the docker daemon is not confined by AppArmor and only the container processes are confined using the
docker-default
profile. I am interested in confining the daemon using AppArmor as well, for purposes of building docker using snaps.The problem I have is that when you use AppArmor to confine the daemon and give the daemon all the access it needs, we have to patch the docker-default profile to allow signalling/ptracing by the daemon to the child containers because both processes are now confined by AppArmor and as such AppArmor will mediate if both ends of the ptrace/signal match the corresponding profile rules. So we can setup the profile for the daemon independently of the Moby project, but we need to modify the profile that containers run under, which is part of the Moby project.
To accommodate this, I propose generating unique AppArmor profile code for each new container, that includes the following additional rules:
This way, we have a unique profile name for all containers, and every container has it's own peer group that it can send/receive signals to. If we keep the current default name of
docker-default
for all containers, then there's an opportunity for separate containers to signal each other, because they will be in the same peer group. I'm not sure if this is still a vulnerability because the containers should still be in their own process namespace, but better to be on the safe side. This would also enable future work if other aspects of the default AppArmor profile for containers needs to be configured individually by default.The ptrace/signal rule allowing a peer group of
DaemonProfileName
would be configurable probably only at build time, i.e. for the snap we would use a daemon profile name ofsnap.docker.dockerd
, but other distributions may choose to use a different one.Alternatively, we could make this snippet of AppArmor profile code not be used/generated if the build time flag specifies that the distribution isn't confining the daemon with AppArmor and then everything stays the same.
Beta Was this translation helpful? Give feedback.
All reactions