Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Working directory enforcement #1305

Merged
merged 7 commits into from
Mar 7, 2022

Conversation

anmaxvl
Copy link
Contributor

@anmaxvl anmaxvl commented Feb 23, 2022

The working directory can be set as part of container image
by WORKINGDIR Dockerfile directive or could be explicitly
set inside CRI container config. Changing the CWD of container
can change the expected behavior of a container.

If the working_dir config is not present or empty inside the
policy config, this information will be gathered from container
image spec.

Add logic to enforce CWD enforcement inside GCS and extend
policy dev tool and policy structure to support this scenario.
The enforcement is an exact string match between what's in the
policy and what's in the generated container spec. If the paths
don't match, the container will fail to start.

Add a utility funcion that picks a random container from an array
and generates a valid/invalid overlay for that container. Refactor
tests to use the new utility function

@anmaxvl anmaxvl requested a review from a team as a code owner February 23, 2022 18:49
@anmaxvl anmaxvl force-pushed the working-directory-enforcement branch from fb7695b to 5608c26 Compare February 28, 2022 22:12
@anmaxvl
Copy link
Contributor Author

anmaxvl commented Mar 1, 2022

@microsoft/containerplat anyone else can take a look? Thanks.

Copy link
Contributor

@dcantah dcantah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, couple things

anmaxvl added 7 commits March 4, 2022 12:03
The working directory can be set as part of container image
by WORKINGDIR Dockerfile directive or could be explicitly
set inside CRI container config. Changing the CWD of container
can change the expected behavior of a container.

If the working_dir config is not present or empty inside the
policy config, this information will be gathered from container
image spec.

Add logic to enforce CWD enforcement inside GCS and extend
policy dev tool and policy structure to support this scenario.
The enforcement is an exact string match between what's in the
policy and what's in the generated container spec. If the paths
don't match, the container will fail to start.

Signed-off-by: Maksim An <maksiman@microsoft.com>
Add a utility funcion that picks a random container from an array
and generates a valid/invalid overlay for that container. Refactor
tests to use the new utility function.

Signed-off-by: Maksim An <maksiman@microsoft.com>
Signed-off-by: Maksim An <maksiman@microsoft.com>
Signed-off-by: Maksim An <maksiman@microsoft.com>
Signed-off-by: Maksim An <maksiman@microsoft.com>
Signed-off-by: Maksim An <maksiman@microsoft.com>
Signed-off-by: Maksim An <maksiman@microsoft.com>
@anmaxvl anmaxvl force-pushed the working-directory-enforcement branch from e4ca154 to d9dfbee Compare March 4, 2022 20:05
@msscotb
Copy link
Contributor

msscotb commented Mar 6, 2022

lgtm

@anmaxvl anmaxvl merged commit f50f975 into microsoft:master Mar 7, 2022
@anmaxvl anmaxvl deleted the working-directory-enforcement branch March 7, 2022 17:42
princepereira pushed a commit to princepereira/hcsshim that referenced this pull request Aug 29, 2024
* Add current working directory enforcement.

The working directory can be set as part of container image
by WORKINGDIR Dockerfile directive or could be explicitly
set inside CRI container config. Changing the CWD of container
can change the expected behavior of a container.

If the working_dir config is not present or empty inside the
policy config, this information will be gathered from container
image spec.

Add logic to enforce CWD enforcement inside GCS and extend
policy dev tool and policy structure to support this scenario.
The enforcement is an exact string match between what's in the
policy and what's in the generated container spec. If the paths
don't match, the container will fail to start.

* Minor refactor of securitypolicy_test

Add a utility funcion that picks a random container from an array
and generates a valid/invalid overlay for that container. Refactor
tests to use the new utility function.

* Add unit tests for enforcing working directory

Signed-off-by: Maksim An <maksiman@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants