[OpenAFS] containers / AFS / Ubuntu - stopped working

[Neil Davies]

Jeffrey

I'm not certain I agree with the security logic. It rather reduces some =
of the deployment use-cases (and hence
the potential economic value).

There are several scenarios where you want the security information =
_inside_ the =91container', this makes the=20
container (say a VM of some kind) more mobile.

It also depends on the trust structure - it is not always going to be =
the case that the outer system is deemed
more privileged that the inner one - telco=92s are looking to =93sell=94 =
containers in their networks (part of NFV) in that
case you would want your container to hold the secret information.

Neil=20

On 28 Nov 2015, at 21:58, Jeffrey Altman <jaltman@auristor.com> wrote:

> On 11/28/2015 4:19 PM, Neil Davies wrote:
>> I can confirm that this sis the problem
>>=20
>> There was a change in docker 1.2.1 (a CVE related fix) that now =
forces /proc/fs to be mounted read-only
>>=20
>> use of the --privileged  argument to docker run does allow openafs to =
run ok, but only at the cost of loosing
>> all of the container isolation!
>>=20
>> I spent some time trying to work out how to _just_ permit read-write =
access to the appropriate portion of=20
>> the /proc/fs filestore, but not cracked it.=20
>>=20
>> It is potentially possible to mount the host's /proc/fs/openafs under =
a different name (with read-write access)
>> within the container - but that would imply a change to the openafs =
building process....
>>=20
>> Obviously I could modify the docker sources, submit a patch etc..=20
>>=20
>> Any suggestions? I'm just wondering if there is any other bits of =
functionality that the docker folks might have=20
>> broken this way - looking to see if there we, as a community, are not =
alone here.
>>=20
>> Neil
>=20
> Containers were not designed with the expectation that they would be
> accessing resources from a network file system.
>=20
> The solution that I am pursuing with Microsoft is to permit the
> container to be created with a network identity associated to it.
> For Linux what we would want is the ability to start a container and =
all
> of its processes as part of a PAG where a process running in the host
> context (not the container's) would obtain the tokens for the =
container.
>=20
> I believe it is inappropriate for the container processes to have =
access
> to a keytab or a username/password combination.
>=20
> I agree with Microsoft that a container should not be able to modify
> kernel driver state such as by storing a network credential for a =
remote
> user.  There is no requirement that kernel drivers provide security
> boundaries between container name spaces.
>=20
> There are some use cases such as running an sshd that provides shells
> with access to network resources as the remote user identity which are
> not appropriate for Containers.  Virtual machines should be used in =
such
> instances to obtain the proper process isolation.
>=20
> Jeffrey Altman
>=20
>=20
> <jaltman.vcf>