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

De root the applications and containers #187

Open
Jrc356 opened this issue Mar 3, 2020 · 8 comments
Open

De root the applications and containers #187

Jrc356 opened this issue Mar 3, 2020 · 8 comments

Comments

@Jrc356
Copy link

Jrc356 commented Mar 3, 2020

Is your feature request related to a problem? Please describe.
Since st2 uses a lot of root files, any underlying k8s configuration that blocks running containers as root (such as openshift) prevents the container from running at all because of all the configuration that is held in the roots (/etc, /root, /opt). It is also a massive security flaw to run the containers as root as any RCE can be used on the underlying host.

Describe the solution you'd like
De-root the containers and applications. Contain it to it's own folderspace instead of using system folders for configuration.

Describe alternatives you've considered
Not really any that I can think of for not running as root.

@arm4b
Copy link
Member

arm4b commented Mar 3, 2020

Good point.
I think this was discussed before StackStorm/st2#3298 (comment) and there is both historic and technical context why it's as it is right now.
Someone will need to explore what are consequences and limitations of running st2actionrunners with no root and what changes st2 core will require for that.

@arm4b arm4b closed this as completed in 6cc70fd Jul 17, 2020
transhapHigsn pushed a commit to DiligenceVault/st2-docker that referenced this issue Jun 8, 2021
You can find the old deprecated version in `DEPRECATED/all-in-one` branch archive: https://github.com/StackStorm/st2-docker/tree/DEPRECATED/all-in-one

Closes StackStorm#22, closes StackStorm#23, closes StackStorm#26, closes StackStorm#29, closes StackStorm#34, closes StackStorm#41, closes StackStorm#43, closes StackStorm#92, closes StackStorm#112, closes StackStorm#117, closes StackStorm#125, closes StackStorm#133, closes StackStorm#141, closes StackStorm#145, closes StackStorm#151, closes StackStorm#163, closes StackStorm#187,
closes StackStorm#188, closes StackStorm#189, closes StackStorm#190
Closes StackStorm#162, closes StackStorm#138, closes StackStorm#108, closes StackStorm#102, closes StackStorm#65
@rk4n3
Copy link

rk4n3 commented Mar 5, 2022

Are we sure this should be closed ?
Might it make more sense to keep the topic alive, and even encourage effort towards identifying resolution possibilities, starting work on such, etc ?

I'd observe:

  • Its very common security best-practice to reject pretty much anything running as root
  • Many large companies with particularly sensitive (i.e. regulated) security concerns are pretty rigid with regards to this
  • A concern like this having the effect of prohibiting use of StackStorm in such scenarios is rather tragic
  • Its also a legitimate concern for everyone, from perspectives of both security and engineering, where current rationale of "because reasons" doesn't seem sufficient to inspire confidence

Speculating along these lines, I'd ask:

  • Why are pack installs executed as "typical" actions, thus entangling the need for root elevation with ALL actions ? Couldn't they be seen as more like "meta-tasks" that engage mechanics that don't have to be intertwined with "routine pack-originated" actions ?
  • If pack installs HAVE to be run as actions, why can't they be a special class of action, where they're endowed with special-purpose capability that isn't present in "routine pack-originated" actions ?
  • Why aren't any/all capabilities that involve need for root privilege isolated to special-purpose programs that can be both handled separately from everything else, and justified in their purpose with respect to security concerns ?

@arm4b
Copy link
Member

arm4b commented Mar 5, 2022

@rk4n3 Thanks for bumping this!
Is it a limitation or bug, but at the end of the day, it's not desired behavior from st2 💯

I think someone would need to dig into it: try all the containers as a st2 user, run a bunch of manual tests and report back their findings. It's been a while and not sure if anyone can remember the reasons, but the root cause might be somewhere in the st2 core and action executions.

@cognifloyd
Copy link
Member

cognifloyd commented Mar 5, 2022

The st2web container is most likely to have issues because of nginx which uses a variety of privileged capabilities. I believe I've seen someone doing nginx without root, but I don't remember where, so it is probably possible with changes.

Another issue is the actions that can do sudo which might be odd.

And they last issue (off the top of my head) is that the deb/rpm files hard code root in some places, so this might be a rabbit hole that requires a series of changes, not just to the Dockerfiles.

@arm4b arm4b added this to Needs Triage in Maintenance Security via automation Mar 8, 2022
@rk4n3
Copy link

rk4n3 commented Jul 8, 2022

Hi all - just thought I'd provide an update on this ...

I've done the work of getting my employer's "Enterprise Offering" of StackStorm all de-root'd, but I've done it in the context of our own custom docker image construction.

I'd like to have (perhaps initially 1-on-1) discussion of pro's and con's with what we've done with our docker layout, and the possibility of adopting it as an alternative deployment strategy. Included in that would be some existing+planned refactoring for the purposes of enabling and evolving HA ... anyone interested ?

@rush-skills
Copy link
Member

@rk4n3 That sounds great. Would you be up for joining the next TSC Meeting (12th July 9.30 AM US Pacific) and discuss the changes for de-rooting the container and their pros and cons? I can add a discussion item to the meeting if you are available!

@rk4n3
Copy link

rk4n3 commented Jul 11, 2022

@rk4n3 That sounds great. Would you be up for joining the next TSC Meeting (12th July 9.30 AM US Pacific) and discuss the changes for de-rooting the container and their pros and cons? I can add a discussion item to the meeting if you are available!

Yes, I would absolutely be willing to attend.

@rush-skills
Copy link
Member

@rk4n3 Great, I have added an entry for this discussion in Tomorrow's TSC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Maintenance Security
  
Needs Triage
Development

No branches or pull requests

5 participants