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


Guillaume Berche
 

Hi,

Following up onto this thread initiated last year on vcap-dev:

https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org?utm_medium=email&utm_source=footer

Now that user namespaces are supported by garden, and that diego integrated
them as unprivileged containers, I'm wondering if a buildpack compile
script running in unprivileged mode (i.e. within user namespace) would be
able to create namespaced users and groups (say user=apache-owner part of
group=vcap) and to assign file ownership to user apache-owner, only
granting user vcap read+execution permissions to the files ? I yet have to
try this into diego. Anyone tried it ?

If not, can this use-case be considered ?

Searching on the garden docs [0] and tracker, I could only find the
following apparently related stories [1] and [2]

I see diego is currently parsing the user mentionned into the image, but
does not seem making use of it [3]. Maybe something that could be
mentionned into [4] ?

Thanks in advance,

Guillaume.

[0] https://godoc.org/github.com/cloudfoundry-incubator/garden
[1] https://www.pivotaltracker.com/story/show/101501294 I can create an
unprivileged container in a user namespace
[2] https://www.pivotaltracker.com/story/show/101501296 File permissions
are correct in unprivileged containers
[3]
https://github.com/cloudfoundry-incubator/docker_app_lifecycle/blob/8205117b94734a52d1f31bda6fd66168d8fbdc66/builder/builder_runner.go#L93
[4]
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/docker-support.md#docker-deltas

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.

On Wed, Dec 10, 2014 at 5:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

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

On Wed, Dec 10, 2014 at 2:58 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

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.

On Mon, Dec 8, 2014 at 6:25 AM, Guillaume Berche wrote:

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
--
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
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.
To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.


--
Thank you,

James Bayer
--
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
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sVYk4DWx9N8ELCSB1Grr3nyyia4j3hNpo4tcaC7Kvoomw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
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/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.

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


--
Thank you,

James Bayer
--
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-sWfSZ-iGDO53ae0%3D-BQV6g4T3v%2B7HDDTMqbvTRgc8DRXg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sWfSZ-iGDO53ae0%3D-BQV6g4T3v%2B7HDDTMqbvTRgc8DRXg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.