Hi,
It's sometimes documented as a best practice [1] [2] to restrict the permissions on an app executable content in order to limit the cases where a vulnerable app would allow a remote attacker to upload code on the file system and use the container resources to run arbitrary code and perform harm.
In particular, I'm asked whether in the php buildpack (or my custom fork), I could setup os-level permissions in the buildpack to prevent write permissions at runtime on potentially executable filesystem locations, e.g. droplet files to be owned by another user than vcap (say "vcap-stager" that would be in the vcap group) with read,execute permissions given to vcap group but no write permissions.
On CloudFoundry, I understand that both the buildpack and the droplet run with the vcap user (commands run with container-info-buildpack [5]), with no other user available, nor sudo access to file ownership
$ id vcap
uid=20156(vcap) gid=20156(vcap) groups=20156(vcap)
$ groups vcap
vcap : vcap
$ ls -al /home/vcap
drwxr-xr-x 5 vcap vcap 4096 Dec 8 13:04 .
drwxr-xr-x 3 root root 4096 Dec 8 12:57 ..
$ umask
0077
What would then be best practices on cloudfoundry to prevent remote code injection from vulnerable apps?
Any plans to support root user during staging, so that custom users can added at staging time, and secure that with user namespaces similar to what docker is planning [6] ?
Thanks,
Guillaume.
[1]
http://httpd.apache.org/docs/current/en/misc/security_tips.html#serverroot[2]
http://www.w3.org/Security/faq/wwwsf3.html[3]
http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#USER[4]
https://github.com/cloudfoundry/bosh/blob/master/stemcell_builder/stages/bosh_users/assets/sudoers[5]
https://github.com/cloudfoundry-community/container-info-buildpack[6]
https://docs.docker.com/articles/security/#docker-daemon-attack-surface