If the code already exists, you can have them deploy it through something like the WebUI so they wouldn’t be able to do anything else in the production system. They can develop the fixlets and tasks in a dev environment so they don’t have access to production. A lot of this could be automated.
Can you provide an example of a management solution that doesn’t run as root by default, or makes this option particularly easy? I’m not aware of any examples.
I believe you could use BigFix which would be running as root to execute commands as a non-root user, but that would be a bit messy to achieve and wouldn’t prevent someone from removing that limitation if they can make custom content.
The only way I can see to accomplish what you are asking for is to make the BES Client itself not run as root, which then means it would have that limitation for everyone, which would significantly reduce what it could ever do on that particular machine unless it could invoke
sudo which would entirely defeat the purpose of having this limitation.
The only other option would be for a console operator to be assigned a limited user that all of their content would run under. This would be messy in that it would require credentials to be stored somewhere somehow, which has it’s own set of insecurities. Also, would every console operator in this limited mode use the same limited user? How would this limited user get created on all systems that this console operator creates actions for?
BigFix has quite a lot of granular access controls that work rather well as compared to other management solutions, but in general, if you can run custom actions on a particular machine, then you essentially have root access. In general this is not a problem because usually the person already has root level access to the machine anyway.
I don’t know much about AIX or WebSphere but generally you’d have only the applications that the non-root users manage running on the system anyway, so the only applications they can affect are the ones that they manage anyway with root level access. If the only data flowing through the system can be accessed by the single non-root user, then a compromise of the non-root user is just as bad for getting the data as compromising the root user if the only goal was to get the data on the system.
If these non-root users need to run as something other than root in order to make the changes they need, then that is a different situation and that can be addressed.