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

Prevent Source builders from running as root #4025

Merged
merged 1 commit into from
Aug 18, 2015

Conversation

csrwng
Copy link
Contributor

@csrwng csrwng commented Aug 5, 2015

Adds SCC checking to Source build controller strategy to prevent builds from running as root.

@csrwng
Copy link
Contributor Author

csrwng commented Aug 5, 2015

@smarterclayton ptal - this is WIP. I've been trying a few things with this one, and without requiring upstream changes to the SCC code, this is the best I have so far. Would like your input/ideas.

@csrwng
Copy link
Contributor Author

csrwng commented Aug 6, 2015

@pweil- ptal

// AllowedUIDs is a list of user ranges of users allowed to run the builder image.
// If a range is specified and the builder image uses a non-numeric user or a user
// that is outside the specified range, then the build fails.
AllowedUIDs user.RangeList
Copy link
Contributor

Choose a reason for hiding this comment

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

can this express "anything other than 0"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it can have a list of ranges like 10-20,30,50,1024-. Ideally we'd be able to ask SCC what UID ranges are allowed for that user/sa and pass that on to the STI builder. But the way it is right now, I can only ask whether a particular user is allowed. @pweil - any thoguths?

Copy link
Contributor

Choose a reason for hiding this comment

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

We could probably separate out some of the logic in the admission controller to an SCC api to help with calls like this. The relevant components are the total set of SCCs and the getMatchingSecurityContextConstraints method in admission which would provide the applicable sets. That could then be passed to something that would return the blocks of allowable uids supported.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pweil- Until we can get the range of users from SCCs, is this an acceptable approach to at least preventing the STI builder from running images that could potentially run as root?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I believe this will be sufficient. If I'm understanding the sequence from the code below it is basically

  1. See if the service account has access to run build pods as root by trying to admit a pod with runAsUser forced to 0
  2. If the above fails set a range of anything except 0 with 1-
  3. The STI builder checks the build image to prevent it from running if the uid is not in the range set by the env var.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically yes

On Fri, Aug 7, 2015 at 5:03 PM, Paul Weil notifications@github.com wrote:

In
Godeps/_workspace/src/github.com/openshift/source-to-image/pkg/api/types.go
#4025 (comment):

@@ -91,6 +96,11 @@ type Config struct {
// Specify a relative directory inside the application repository that should
// be used as a root directory for the application.
ContextDir string
+

  • // AllowedUIDs is a list of user ranges of users allowed to run the builder image.
  • // If a range is specified and the builder image uses a non-numeric user or a user
  • // that is outside the specified range, then the build fails.
  • AllowedUIDs user.RangeList

Yes, I believe this will be sufficient. If I'm understanding the sequence
from the code below it is basically

  1. See if the service account has access to run build pods as root by
    trying to admit a pod with runAsUser forced to 0
  2. If the above fails set a range of anything except 0 with 1-
  3. The STI builder checks the build image to prevent it from running
    if the uid is not in the range set by the env var.


Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/pull/4025/files#r36561052.

@csrwng csrwng force-pushed the prevent_s2i_root branch 2 times, most recently from 19e3af5 to e5bf05d Compare August 12, 2015 15:39
@csrwng
Copy link
Contributor Author

csrwng commented Aug 12, 2015

Depends on #4124

@csrwng csrwng changed the title [WIP] Prevent Source builders from running as root Prevent Source builders from running as root Aug 12, 2015
@csrwng
Copy link
Contributor Author

csrwng commented Aug 12, 2015

[test]

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/4201/)

@csrwng
Copy link
Contributor Author

csrwng commented Aug 12, 2015

@pweil- the s2i part is now in a separate PR (that this one depends on). Please let me know if you have any additional comments/questions on the origin commit.

@pweil-
Copy link
Contributor

pweil- commented Aug 12, 2015

Cool. Other changes look fine to me. Thanks @csrwng

@csrwng
Copy link
Contributor Author

csrwng commented Aug 13, 2015

@smarterclayton any comments?

@@ -74,6 +74,13 @@ func (s *STIBuilder) Build() error {
} else if s.build.Spec.Source.Git.Ref != "" {
config.Ref = s.build.Spec.Source.Git.Ref
}
glog.Infof("The value of ALLOWED_UIDS is [%s]", os.Getenv("ALLOWED_UIDS"))
Copy link
Contributor

Choose a reason for hiding this comment

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

lower(higher) log level? i don't think we need to print this on every run

Copy link
Contributor

Choose a reason for hiding this comment

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

also i'd just get it once and use it for the log and the if.

@csrwng
Copy link
Contributor Author

csrwng commented Aug 17, 2015

thx @bparees - updates made

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 9b6a18d

@bparees
Copy link
Contributor

bparees commented Aug 17, 2015

lgtm.

@bparees
Copy link
Contributor

bparees commented Aug 17, 2015

[merge]

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/3008/) (Image: devenv-fedora_2173)

@csrwng
Copy link
Contributor Author

csrwng commented Aug 17, 2015

trying again... seems an issue with ui e2e
[merge]

@csrwng
Copy link
Contributor Author

csrwng commented Aug 18, 2015

[merge]

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 9b6a18d

openshift-bot pushed a commit that referenced this pull request Aug 18, 2015
@openshift-bot openshift-bot merged commit 8cdff63 into openshift:master Aug 18, 2015
@csrwng csrwng deleted the prevent_s2i_root branch August 18, 2015 18:40
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.

5 participants