Hi guys
Currently, Docker-snap requires some manual setup before using since we need to create an extra group on UC16 and add the login user in it. That allows user runs docker without sudo and overcomes the confinement issue as well. Adding an extra group requires account-control interface and the documentation indicates that it’s not auto-connected. Meanwhile people also need to reload the snap to take effect after the interface is connected.
As requested, people wanting to use the docker snap right away isn’t required to perform this manual configuration. Could you please add a snap declaration to docker-snap with the following interfaces auto-connected?
* account-control
* home
Thanks.
1 Like
Sorry for bothering again, but I’d like to understand a bit better the requirement to have account-control. I’ve seen snaps using it as a mechanism to obtain privileged access into manipulating the system out of its confinement, and that’s of course not okay.
For the requirement of having custom users and groups, please see the topic @jdstrand opened recently. I still need to go through it myself, but we should look into those use cases and make sure that they are supported sooner rather than later so we’re not opening unnecessary holes in the confinement system.
In the past, login user failed to run docker build and compose command under $HOME folder on UC16, even with sudo. We’ve discussed it in mail thread “Permissions issues in the docker snap” and you’re in the CC list. Could you take a look, please?
Due to the strict confinement, people have to switch to root user and navigate to $HOME(/root) folder to make these two command work. That’s really painful.
So the strategy here is to create an extra group, add the login user in that group. Meanwhile, docker creates unix socket by leveraging the group for the communication with docker client. With that, the login user can manage to run build and compose command under $HOME folder without switching to root.
As of now, home and account-control interfaces are not auto-connected. The requirement here is to allow people running docker without manual configuration.
Per the user/group management that @jdstrand mentioned in another thread, yes, it’s long-standing feature request, and to keep the project moving forward, we currently have to apply a workaround here for the time being and fix it in the proper way once the feature is done.
Yes, I’ve seen the thread, and the feedback above applies to it. The account-control interface should be reserved for snaps that perform real account-control on the system, instead of being a mechanism to jump out of confinement in arbitrary ways. Just in the past week I’ve seen multiple cases of this happening, and we shouldn’t be complacent otherwise the point of confinement is gone (cc @jdstrand).
To workaround the problem right away, we can start by simply opening up the device to be read/written by anyone in the system by changing its mode when running under an Ubuntu Core device specifically. Other strict snaps won’t have access to the device anyway because of the confinement, so this buys us some extra time to handle the story in a convenient way without breaking the confinement model in other ways.
I would love to see Snappy and users and groups (obsolete) fully designed and someone assigned to implement the various use cases, of which ‘1’ is specifically to address docker, lxd, etc. I don’t think it would take terribly long for someone to implement assuming we go with something along the lines of what I recommended.
I’d rather not open up the socket to be read/write by anyone on Ubuntu Core because the docker socket is a straight path to root for any users on the system or unconfined processes. It also requires code changes to docker to disable part of its security model which is undesirable.
IMHO, either docker should continue to say ‘run the docker command with sudo for now’ until the system users/groups feature is ready or we let it temporarily have account-control. It was mentioned that we don’t want to allow it because it would allow for confinement escape, but I don’t consider granting account-control as giving docker any more privilege to break out of confinement in practical terms. docker-support is only advisory policy and we’ve always known that it allows multiple ways to break out of confinement (the most obvious is it has the ability to load apparmor policy into the kernel and therefore change its own confinement, so it could just give itself access to the user databases; this is one reason why the docker-support interface is so tightly controlled). Obviously, if the docker snap abused its advisory policy, that would be a problem that would need to be addressed through store processes and conversation with the publisher, but the point remains, the docker snap isn’t strongly confined and I don’t see that keeping it from using account-control as appreciably improving security.
I completely agree that using account-control in this way is abusing the interface (we need Snappy and users and groups (obsolete)). It is a gross hack to work around the missing feature and that might be grounds enough to not allow the access. That said, I envisioned the workaround of using account-control as temporary, only for docker and only until snapd properly supports system users and groups (and we would treat abuse of the account-control interface by the docker snap the same as abuse of the docker-support interface).
8 days from the initial request have passed. Performing tally:
1 vote in favor
1 vote against
0 votes abstained
Not granting the snap declaration at this time. Please feel free to discuss/revisit so we can possibly revote.
It sounds like we aren’t going to pursue this. I am going to mark this as closed for now.
