Better Security Around ToolBox
Notice: For anyone reading this I'm recommending that you remove the TransferFilesInSession permissions and possibly the RunSharedToolInSession unless the user is an IT Admin and is allowed System Rights on a computer.
I know, this is hard for me too...
When we first looked at the RunSharedToolInSession permissions we assumed you had to be connected to the session and logged into the server / workstation which made it more acceptable. The good news is that we at least control the SharedToolBox and can remove harmful scripts.
What I found, is that by giving a user TransferFilesInSession or RunSharedToolInSession you are essentially giving users rights to run scripts on behalf of other users that maybe logged into the system, even when the screen is locked or run scripts as the SYSTEM account when no-one is logged into the computer. 😬
Meaning users can possibly -
- Change Local Passwords and or domain passwords depending on who is logged in.
- It makes you wonder, what's the purpose of locking the machine if someone can just change the password via a batch. 🤷♂️
- Install Software
- Run Custom Scripts outside the SharedToolBox
- etc.
The whole purpose of us removing the RunCommandOutsideSessions and SwitchLogonSession was to prevent things from running without someone being logged into the server / workstation. Also hoping this added an extra layer of security incase someone got into someone else's control account meaning users would first have to connect to the server then login again prior to any scripts being executed.
During my testing I tried disabling RunSharedToolInSession and i found out that you can still add scripts to the personal toolbox and execute them even though the shared toolbox grayed out.
To fully disable the toolbox you need to turn off both RunSharedToolInSession and TransferFilesInSession.
This is extra depressing because i need my support staff to have the power to transfer files but i don't want them running scripts as SYSTEM... 😞
Thinking about hiding the briefcase to prevent the user from using this function? Well that can easily be bypassed too just by editing an xml file, it's all optional on the users end.
This means ALL USERS that have TransferFilesInSession have SYSTEM rights and anyone that gets a hold of their account can abuse control.
Customer support service by UserEcho
Just to clarify this part. (personal opinion)
Essentially giving users rights to run scripts on behalf of other users that maybe logged into the system. --> This part is expected since the computer is unlocked but having the ability to run scripts with the screen locked is not preferred.
Meaning everyone with TransferFilesInSession permission essentially has backstage access.
Thanks for your report. I have discussed this with our architecture and information security teams and we agree we should find a way to make the toolbox behavior more predictable and clear especially when it comes to the required permissions. We do require the RunCommandOutsideSession permission to be able to run a tool from the host page, but not from the host client. we also have documented that the shared toolbox requires the TransferFilesinSession permission, and will make sure that we update this for the personal toolbox as well.
note: edited for a typo and clarity