Implementing Least Privilege - Visual Studio & Git

 The process of actually implementing a "least privilege" strategy usually has a few surprises along the way. I'm not going to list out all of our choices, but I am going to note a few things that caught some of the team by surprise.


- Permissions and restrictions are likely to be different on computers and accounts within the same department

Not everyone has years of support and administration in their history; so, it is worth saying that any time a second user account is involved it is vital to validate permissions. 

If there is a resource that you are sharing with your other account, or that multiple people need to work on, you have to be able to see explicitly defined access to have any realistic chance of success with the rest of your strategy.

This ultimately is the root cause behind several of the observations below.


- Keep your working folders and local repos inside of your user profile structure. It's structured in a way that is consistent, predictable, and that programs have been designed to be compliant with. 

If you legitimately need that folder on the C:\ of your development PC, then that means that you should mark that software as out of compliance with modern architecture. Backlog it and move on if you need to, but don't perpetuate the problem by tolerating things that "need" a custom folder in their root when you can simply start doing it right.

The dev with the most recent account structure was able to overcome several obstacles for least privilege when we simply pursued the question "Why should the repositories be outside of his user profiles?" and found that there was no legitimate need.

- "Ownership" alerts during commit and clone are indications of folder permission issues.

- Git likes to have a %HOME% variable

    Discovered because: a developer did not have a homedrive and homedirectory set for one of their accounts. When VS encountered a problem with the .gitconfig file for a repository, and tried to fall back to their account settings, it tried to establish it as c:\windows\system32\.gitconfig 

    Resolution notes:
            In theory this point shouldn't be reached, so we didn't research deeper, but here is a reference on the subject: git for windows - does not load %USERPROFILE%\.gitconfig when launched "run as" - Stack Overflow

            We've requested to have that set in his AD properties since it keeps consistency with the rest of the team. But the observable problem was also resolved by changing the local repository path.


Our final take-aways:

Validate effective permissions
Use the %userprofile% structure effectively
When we our summer interns come in, assume that we need to proactively define the permissions for their environments,


General principles:

The things standing in front of good strategies, are often bad practices that we inherited without ever questioning. When starting a new strategy be prepared to question all existing assumptions.

For achieving least privilege goals, remember that each module in the system has its own authorization context, and represents a decision. Sometimes a single decision spans multiple modules, but it still should be seen as a decision for that module.

Comments

Popular posts from this blog

Default Browser - set url association with PowerShell

LINQ within a foreach()

Rules of Automation