Heroku-24: Implications of the switch to separate Linux users for build vs run images about base-images HOT 10 CLOSED

I really like the security posture of not being able to write to /app or /layers at runtime. It basically means the build result is untouched by things happening at runtime, which seems correct and more secure for production images.

Not being able to write to /app is a big blocker, though. Folks will certainly be doing that (especially folks transitioning from the current Heroku platform where /app is one of the few writeable locations). It'd be really annoying for (probably a fair number of) developers to move writes to /tmp or $HOME.

If there is anyway we could make /app (and /workspace) group writeable, so runtime users could write to /app, but not /layers, that would be a decent compromise. But I'm not sure we can instruct the CNB platform to do that?

If not, I think I favor one user. I don't see the value in causing a bunch of pain (which may slow the adoption rate of Heroku CNBs) for what I view as an ivory tower security restriction.

from base-images.

I would like to preserve existing behavior of heroku-22 (same user for build and runtime) as I don't think it's tennable to support Rails apps out of the box unless I chmod the whole app dir. Even then, I would be surprised if there wasn't some edge case that wasn't uncovered.

Ideally: If we want to transition to a more restrictive set of runtime permissions, I would like some exit metrics to see what folders people interact with (though we don't have that capability today).

I'm in favor of adding some smoke tests to our various CNBs so they won't block a compliant app from running on more restrictive infrastructure.

Essentially I support Ed's position here.

from base-images.

If there is anyway we could make /app (and /workspace) group writeable, so runtime users could write to /app, but not /layers, that would be a decent compromise. But I'm not sure we can instruct the CNB platform to do that?

I don't believe there is a way to do this properly currently. It would require discussion/RFCs/spec work upstream (which is perhaps something worth doing, but IMO not something we can achieve before Heroku-24 GA).

The only workaround we could do in the meantime would be to say have Kodon adjust permissions itself, but then we lose Kodon vs Pack parity, which doesn't seem worth it.

from base-images.

What about an inline buildpack that adjusts permissions for /workspace that's placed at the end of all our buildpack groups? We do something similar with the builder EOL deprecation message. It could also be toggled on/off with an environment variable for those who want that increased security.

from base-images.

Yeah that's mentioned here:

3. A buildpack (or inline buildpack) must chmod specific directories/files as group-writeable during the build (which allows writes, since both the heroku and heroku-build users are in the same group).

However, until we have system buildpacks it would be kinda clunky (eg when someone adds an unrelated buildpack so switches from the buildpack default to their own list in project.toml, the feature will stop working, unless they know to add this special buildpack to their buildpacks list too).

from base-images.

Oops, I picked up the thread in the middle and missed that (but had remembered you mentioning something along these lines) 😅

Despite the potential clunkiness, I think it would be an acceptable transitional step. Since option 1 (app must write to /tmp or $HOME) forces developers to adopt the increased security posture and option 2 (build and run user are the same) forces developers to adopt the decreased security posture.

Plus, we could reduce that clunkiness with documentation and by helping upstream get system buildpacks implemented.

from base-images.

I agree using a buildpack would be a good way for people to opt-into read-only layers/workspace, as a transitional step.

However, I'm not sure about adding to the builder (and then having it toggled via env var) - IMO it would make more sense (and avoid the footgun mentioned above) if people opted in by adding the buildpack to their buildpacks list in project.toml.

The main question we need to answer now is "what should the default behaviour be for Heroku-24?". If the answer is "same user; keep app source + layers writable for now", then we can figure out how we might offer this as opt-in later :-)

from base-images.

If there is anyway we could make /app (and /workspace) group writeable, so runtime users could write to /app, but not /layers, that would be a decent compromise. But I'm not sure we can instruct the CNB platform to do that?

I looked into this a bit. pack and lifecycle isn't doing anything to /workspace / /app permissions right now. pack just mounts the local app directory into /workspace as is. So a very simple solution for a user is to run chmod g+w . once in their repo, if they want to enable writes in /workspace at runtime. This seems nice from a security standpoint, the app doesn't modify it's workspace at runtime without the developer explicitly allowing it. And users wouldn't need to run a buildpack to do this for every build.

from base-images.

So a very simple solution for a user is to run chmod g+w . once in their repo, if they want to enable writes in /workspace at runtime.

That won't work, since Git doesn't support full file modes (it would likely get messy), but only the executable bit. Therefore, whilst users could chmod locally when using Pack CLI, it wouldn't help when they git push to Heroku/other platforms.

See:
https://git-scm.com/docs/user-manual#tree-object

Note that the files all have mode 644 or 755: Git actually only pays attention to the executable bit.

from base-images.

That won't work, since Git doesn't support full file modes (it would likely get messy), but only the executable bit.

Fair enough. I'll stick with my earlier statement:

I favor one user. I don't see the value in causing a bunch of pain (which may slow the adoption rate of Heroku CNBs) for what I view as an ivory tower security restriction.

from base-images.