How to restrict permissions on apps filesystem to protect against remote code upload ?

[Guillaume Berche]

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

[James Bayer]

user namespaces were recently added to garden, so it's likely when diego is incorporated we'll have those features.

there are no short-term plans to use different types of users in the staging process afaik, but your suggestions seem reasonable. dieu, mark kropf and onsi should consider them.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Thank you,

James Bayer

[Guillaume Berche]

Thanks James, I'm looking forward to reading related story content if this gets specified.

Guillaume.

--
You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sVYk4DWx9N8ELCSB1Grr3nyyia4j3hNpo4tcaC7Kvoomw%40mail.gmail.com.

[Guillaume Berche]

Actually, rather than " use different types of users in the staging process", this would rather be granting sudo access to the vcap user to be able to create other users, and chown files to these new users. Alternatively, have the staging process run as a container "root" user with permissions to do the previous actions and set default user to run (similar to USER in docker file [7] ).

By the way, I'm curious how the cf push <docker_image> upcoming feature will run the docker top process: will that be with run with root (id=0) as it defaults in docker [7] (or specified USER  in docker file) or will it remains vcap (which would require file permissions on the docker image to allow world read/execute permissions) ?

[7] https://docs.docker.com/reference/builder/#user
[8] https://docs.docker.com/reference/run/#user

Thanks,

Guillaume.

On Mon, Dec 8, 2014 at 4:18 PM, James Bayer  wrote:

user namespaces were recently added to garden, so it's likely when diego is incorporated we'll have those features.

there are no short-term plans to use different types of users in the staging process afaik, but your suggestions seem reasonable. dieu, mark kropf and onsi should consider them.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

--

Thank you,

James Bayer

[James Bayer]

we haven't decided which user to use to run the docker images quite yet.

some docker images will assume a particular user, so just using "vcap" may exclude some of those from working.

in order to be root, we'd have to be confident that user namespaces provide adequate security and isolation. user namespaces were recently added to garden and diego has a story to investigate being able to use root [1], but i appreciate the importance of your comments on running processes with least privilege. we'll sort this out as we get closer to running apps with diego in production.

[1] https://www.pivotaltracker.com/story/show/78606184

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.