warpfork
commented
8 years ago Updating things to work with this is a little friction, but starting to evaluate formulas with lower privileged policies is already forcing quality improvements in pretty much every formula that's been affected by the change :+1: It's also quite nice to be able to flip between uidzero and governor policies just to see what happens with zero special effort -- now I can at-a-glance find out of something requires "root" because of mere filesystem ownership legacies, or because it's actually doing something interesting. Whee!
Working with containers should not represent a major regression towards high-privileged operations. There, I said it.
And as we all know by now -- this is a siren song that requires active resistance.
So, here's the first major steps in making Repeatr's default modes of operation switch immediately and conveniently to lower privilege -- non-root UIDs at bare minimum, and more advanced mechanisms like dropping capabilities as much as possible if an executor engine supports it.
Key concerns driving the design are as follows:
Policychoices. Policies should be as uncomplicated as possible: they are not multiple choice, they are not swiss cheese, and they are roughly ranked in asafety <-> powercontinuum, so that it's always easy to say "you should move to the left if you can".Policydescribes some amount of Minimum Viable Preparations to match the privilege level. If you are operating within a safe, minimally-privileged Policy, then Repeatr will default to making sure your process has some valid space to work (a writable dir, a$HOME, etc).Emphasis remains on "minimal" preparations -- their existence at all is a concession. The point here is to address needs that are pretty much a stretch mark leftover from ancient history when there was a grizzled sysadmin granting you the hallowed keys to the monstrously babied university mainframe, when simply don't have such a role in the modern world (certainly not in this context, anyway). These preparations could be shrugged off to users of repeatr by using a prior stage in a pipeline to set them up, but doing so would raise two other problems: it would create an implicit contract between formulas for something very very basic (explicit is better than implicit, and no requirement at all is better than explicit), and also that setup stage would tend to require
PolicyGoverneritself, which seems rather like losing ground again. Thus, the concessions. But on principle, Repeatr should never be presumptive about your flow, and every little piece of magic we do lets people get away with making crappier software, so making the fewest exceptions here is remains important, and also, they are to be easily disabled.This is quite likely a breaking change for many formulas. Anything that assumed it has uid=0... doesn't, anymore. Standard alpha disclaimer applies here! :smiling_imp:
Policies are not a do-all end-all solution for arbitrarily complex security needs, and they're not intended to be. If you have really specific capability desires, that's... cool, but Policies are not going to help, and a more correct behavior is to reach down into the per-executor configuration to really tweak. More knobs is not a happier thing in security.
In the future, the hope is to produce an increasingly large body of software which works normally at the safest Policy levels. In order to encourage this, one could imagine a build farm which accepts jobs... but only runs them if the Policy is the lowest level, "Routine", for example. The high-level approach of policies instead of exposing all conceivable fine-grained details makes rules like that possible, simple to express, and immediately comprehensible.
All that's the hope, anyway. But one thing's for sure: after this merges, we can run things as uid=$somebody instead of uid=root. And that can't possibly be bad.