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.

Sign up for GitHub

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

Jump to bottom

Masked paths setting in the container #186

Closed
wants to merge 2 commits into from
Closed

Masked paths setting in the container #186

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f59e654
Add Masked Paths setting to allow hiding paths in the container
mrunalp Sep 14, 2015
8d705eb
security: Add Masked Paths to the linux config
mrunalp Sep 14, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions runtime-config-linux.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -250,6 +250,16 @@ The actions and operators are strings that match the definitions in seccomp.h fr
}
```

## Masked Paths

Masked paths allow hiding paths in the container by bind mounting `/dev/null` over them to prevent access by the container process.
Copy link
Member

Choose a reason for hiding this comment

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

perhaps that mount approach is an implementation approach, but not the requirement?
If some runtime, cow fs, or future kernel feature allowed the filepath to just not exist, then those could be allowable as well. Not just an exclusive bitbucket.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Fri, Sep 25, 2015 at 11:17:19AM -0700, Vincent Batts wrote:

+Masked paths allow hiding paths in the container by bind mounting
/dev/null over them to prevent access by the container process.

perhaps that mount approach is an implementation approach, but not
the requirement? If some … cow fs … feature allowed the filepath to
just not exist…

What would this look like? Looking for similar tech besides “bind
over it”, there's the device cgroups 1. But there the access is
bound to major/minor, and not by path. That's not a big deal though,
I could see something like that bound by path. But the cgroup
approach gives errors like:

cgcreate -g devices:/device-group

cgset -r devices.deny='c 1:3 mrw' device-group

cgexec -g devices:/device-group cat /dev/null

cat: /dev/null: Operation not permitted

cgdelete -g devices:/device-group

and not just an empty read. So I'd be cautious about saying “don't
worry about how it's implemented, just use this to block access”.


```json
"maskedPaths": [
"/proc/kcore"
]
```

## Rootfs Mount Propagation

rootfsPropagation sets the rootfs's mount propagation.
Expand Down
2 changes: 2 additions & 0 deletions runtime_config_linux.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,8 @@ type LinuxRuntime struct {
Seccomp Seccomp `json:"seccomp"`
// RootfsPropagation is the rootfs mount propagation mode for the container
RootfsPropagation string `json:"rootfsPropagation"`
// MaskedPaths is a list of paths that are hidden in the container.
MaskedPaths []string `json:"maskedPaths"`
}

// Namespace is the configuration for a linux namespace
Expand Down