Answers: <p>I don't see a point.</p>
  
  <p>An external attacker (who has access to the host) can easily find where the files are - he only has to look at the last file system layer and will have them presented right there for him.</p>
  
  <p>An internal attacker (who gains access to the container through a misconfigured part of the app or whatever) will also rather easily find them by looking through the process table at <code>/proc</code> and noting the CWDs. </p>
  
  <p>Attacking the image might be easier with a fixed location, as the attacker only has to add another FS layer, overwriting that directory with his own application. But then, if you did not secure your image store, it does not matter anyways what else you do.</p>
  
  <p>So... I'd say the convenience of a common location is good, and little to no security would be gained; and if, then only security by obscurity, which does not count.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-12T08:58:07.730Z
Answers: To complement a small point: Where you put files in a unix architecture has more to do with convention such that everyone can find them easily for maintenance purposes, in case of a container there's few interest as it shouldn't be mutated/maintained.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2018-02-12T10:15:52.117Z
Answers: @Tensibai, the OP says he has "a lot of" apps - putting the files in the same place all the time is a valid maintenance concern (to not always guess where they are in app x, y or z).
Answers: AnoE
Answers: CC BY-SA 3.0
Answers: 2018-02-12T10:20:37.783Z
Answers: I meant using the conventional places has fewer interest :)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2018-02-12T23:37:54.043Z
Answers: Security tools like selinux and apparmor will assume locations that map to the filesystem standard, if you leverage those tools placing the files outside of the conventional locations requires you to maintain those mappings, labels and controls.
Answers: gdahlm
Answers: CC BY-SA 3.0
Answers: 2018-02-11T20:29:39.883Z
Answers: 2018-02-12T07:56:05.043Z
Answers: 2018-02-12T07:56:05.043Z
Answers: AnoE
Body: <p>I use docker to deploy a lot of apps since a couple of years. Today I ask myself, should I copy my app to a different location in the docker image? I used to copy the file to the root, e.g. <code>COPY . /AppName</code>, but I wonder whether this is secure.</p>
  
  <p>In order to find an answer to this question, <a href="https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#minimize-the-number-of-layers" rel="nofollow noreferrer">this tutorial</a> was read, but it does not clarify where to copy a app inside a docker image and why.</p>
  
Tags: <docker><security>
Title: From a security perspective, to which location should one copy an app inside a docker image?
UserDisplayName: 030
ThreadText: # From a security perspective, to which location should one copy an app inside a docker image?
  
  (Asked by: username_0 on 2018-02-11)
  
  I use docker to deploy a lot of apps since a couple of years. Today I ask myself, should I copy my app to a different location in the docker image? I used to copy the file to the root, e.g. `COPY . /AppName`, but I wonder whether this is secure.
  
  In order to find an answer to this question, [this tutorial](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#minimize-the-number-of-layers) was read, but it does not clarify where to copy a app inside a docker image and why.
  
  **Tags:** docker, security
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-02-11. Score: 6 | Accepted answer
  
  I don't see a point.
  
  An external attacker (who has access to the host) can easily find where the files are - he only has to look at the last file system layer and will have them presented right there for him.
  
  An internal attacker (who gains access to the container through a misconfigured part of the app or whatever) will also rather easily find them by looking through the process table at `/proc` and noting the CWDs.
  
  Attacking the image might be easier with a fixed location, as the attacker only has to add another FS layer, overwriting that directory with his own application. But then, if you did not secure your image store, it does not matter anyways what else you do.
  
  So... I'd say the convenience of a common location is good, and little to no security would be gained; and if, then only security by obscurity, which does not count.
  
  > **Comments:**
  > **username_2**: To complement a small point: Where you put files in a unix architecture has more to do with convention such that everyone can find them easily for maintenance purposes, in case of a container there's few interest as it shouldn't be mutated/maintained.  
  > **username_1**: @username_2, the OP says he has "a lot of" apps - putting the files in the same place all the time is a valid maintenance concern (to not always guess where they are in app x, y or z).  
  > **username_2**: I meant using the conventional places has fewer interest :)  
  > **username_3**: Security tools like selinux and apparmor will assume locations that map to the filesystem standard, if you leverage those tools placing the files outside of the conventional locations requires you to maintain those mappings, labels and controls.  
  
  ---
  
  