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
gitserver: Only allow acceptable commands and POST method in /exec #30833
Conversation
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff 984cac8...c00d7c0.
|
c27e722
to
4ae48f7
Compare
4ae48f7
to
76b5a2d
Compare
76b5a2d
to
e610367
Compare
|
Other than the few questions I posted, this looks really nice! Very good job organizing this code to make it very readable and understandable. I also added @andreeleuterio to review this change. |
This commit fixes the following test: internal/gitserer/TestClient_Archive
|
I am also going to try running this locally and see what I can do. |
9b5bc5e
to
302c4a7
Compare
6bf41ff
to
4b8dce3
Compare
|
I think doing a first pass that logs commands that would have been blocked is a good idea. I'm not sure whether we need it behind a feature flag if it's only logging though. |
Sorry I didn't clarify it well. What I meant was:
That way we can flip it back if we see any new errors. |
|
Makes sense. Also worth adding a counter since this would a nice things to visualise. I think something as simple counting the number of blocked / allowed commands would be enough and the details of the actual commands can be in the logs. |
Good idea. Will go ahead and implement the feature flag and metric related changes. |
The feature flag is turned off by default and allows us to flip it when we are confident with the changes in production after observing the logs. Also, it lets us flip it back to the default in case there are any regressions. This commit also adds test to validate existing behaviour with an without the feature flag enabled.
|
Ready for a fresh round of reviews. Updated with feature flag and metric related changes and updated PR description with the latest status and suggested testing plan. |
|
This will require a gitserver rollout. |
…30833) Patch for sourcegraph/security-issues#213. This feature is guarded behind a feature flag: experimentalFeatures.enableGitServerCommandExecFilter The feature flag is turned off by default and allows us to flip it when we are confident with the changes in production after observing the logs. Also, it lets us flip it back to the default in case there are any regressions. This commit also adds a test to validate existing behaviour with and without the feature flag enabled. Finaly, this commit adds a metric to count the number of blocked command executions.

Patch for https://github.com/sourcegraph/security-issues/issues/213.
Note to reviewers
This PR also fixes an edge case with the
isAllowedGitCmdfunction. So it's suggested to look at the commits one after the other during review as this function and related functions and variables have also been moved frominternal/vcs/gittointernal/gitserver/gitdomain.Without this move,
golangci-lintcaught a cyclic dependency betweencmd/gitserver/serverandinternal/vcs/git:internal/vcs/git/main_test.goalready importscmd/gitserver/servercmd/gitserver/server/server.gowould now be importinginternal/vcs/gitif we didn't moveIsAllowedGitCmdtointernal/gitserver/gitdomainpackage.Regression concerns
On scanning the PR commit by commit, reviewers should also notice the addition of multiple new commands to the allow list. This does not introduce new behavior, but adds the existing set of commands which are already in use in the
/execendpoint. With the check for the allow list in infunc (s *Server) exec, existing tests were failing unless these commands and in some cases extra args were added to the allow list. My concern here is that if we have existing commands in use for which test cases do not exist, this PR could lead to a severe regression.My thoughts at this point are to keep the code around the allow list checking guarded behind a feature flag while at the same time doing a dry run check and logging any commands that fail the check for the next few days. Observing the logs in production should give us a concrete list of commands that are not present in the allow list at the moment. I'd appreciate any thoughts or suggestions on the best path to take forward.
Update
The PR now does the following in order to avoid regressions:
src_gitserver_exec_blocked_command_receivedif a blocked command is received by gitserver's/execendpointexperimentalFeatures.enableGitServerCommandExecFilteris set totrue, block the command from being executed or else default to current behavior of letting the command be executedNote: By default the feature flag is disabled and merging this PR WILL NOT fix the linked issue.
Test Plan
src_gitserver_exec_blocked_command_receivedfor 2-3 days0(Note: Userateorincreaseas this is a monotonically increasing counter)Tagging @sourcegraph/security for suggestions on testing plan and timeline with respect to SLA.