Hello,
I have a request to create BigFix users that can run fixlets/tasks designed to patch things like WebSphere. Those application code components are not installed as root. They’d be more like “was-admin”. This is related to AIX LPARs.
BigFix’s agent seems to run as root and for the WebSphere Admin folks, we don’t want to give them full root capabilities through the agent/client. Is there a way to set up a BigFix user such that they can only work as a specific user like “was-admin”?
In other words, can I enable BigFix users to patch code components with the minimum account access that is needed to do that specific job (not the keys to the kingdom)?
I don’t know if what you are asking for will work or not.
The way BigFix is designed, you limit what someone does via the Client by the permissions you grant them in the Console. If you don’t want them to have unfettered access to the BES Client “root” capabilities, you don’t give them the ability to create Custom Content. In that case they can only perform the actions you specifically give them access to via Site Content Subscriptions.
If you really want to limit their access, only give them access to a single Custom Site, without the ability to create Custom Content and copy the content into the site that you want them to have access to.
I believe that the only site you cannot restrict access to is the BES Support site, I believe everyone gets Reader permissions to that site. (I might be wrong, it could be that all Endpoints get reader access to it).
Under Windows, it’s possible to create content that runs as the “Current” user.
Is it not possible to create a bash (or AIX equivalent) script, that can impersonate another account while it executes a command or script? If so, it’s just a matter of incorporating that into customized copies of the Web Sphere content you need them to access.
Thanks for the input Tim.
The real goal is for them to code their own fixlets so I’m not involved. You sound like you agree with my assessment that only enabling them to work as certain IDs isn’t an option. I’m not interested in doing all of their fixlet authoring so they can push the button to say go.
You might be able to run BigFix itself as a limited user instead of root, but then it would probably not function correctly and it would be limited in what it can do for all users, which would also cause problems.
I guess I don’t understand the situation where you would give someone the ability to manage a computer but not want them to be able to manage it entirely. The auditing capabilities of BigFix allow you to make sure the person is behaving. Ultimately you have to trust people at some point.
Let me try to explain.
I don’t want these people to manage a computer. Their role is to only manage WebSphere for example. They are not root administrators. They are WebSphere Administrators. They would like the ability to have fixlets for their WebSphere patching needs. However, they have no need for root. Sure, I can code up their fixlets and only give them access to run them. Sure, I could test “four eyes” or some other functionality they won’t like. I’d much rather be able to set a user up with the capabilities to only run with their needed permissions to do their job with no ability to change a script or run commands as root. Does that make more sense? The idea is that everyone doesn’t need to run as root to do their job. However, BigFix tends to require a root privilege for all users.
Delegating specific rights to an operator is indeed a limitation. As someone who has carefully crafted Active Directory delegations and permissions for our workstation administrators, print server operators, service desk, etc. I have also been frustrated by the lack of fine-grained permissions.
The best I see that you can do is to create operators that have permissions to a single Custom Site (hiding their view of patches, software deployments, etc.). You can add the Fixlets/Tasks that you want them to execute to their custom site. You can restrict their ability to shut down / restart the endpoints. But, everyone has access to the BES Support site; and there’s a lot of dangerous stuff they could run from there. And if you want them to write their own fixlets, then all bets are off anyway.
All I see that you can do, is to build an entirely separate BigFix instance that they could use as their “Integration & Test” system; then when they are happy with their content they could send fixlet exports to you, and you would import it into their custom site on the production system (where they don’t have custom content authoring rights).
Four-eyes doesn’t work as well as you’d like either. Their actions don’t go into any kind of a “holding queue” - that second set of eyes has to be over their shoulder right then and there when they take the action. I’ve used 4-eyes as a kind of a “read-only” role - their management approver group is empty, so they can’t take any action at all, but they can read Analyses, relevance results, etc. and call us when they see a problem.
Thanks for the commentary. I work with AIX, so it unfortunate that not many functional fixlets are delivered. Yep… we get to pretty much code up all of our own fixlets. I can’t be in the business of coding everyone’s fixlet needs in that rolIe or I’d never get anything done for myself. It sounds like BigFix is designed mostly just for O/S administrators and past that the functionality just isn’t there to let others rule their own non-root worlds. It seems that an assumption is made that non-root users have no patching or other duties. That is simply not the case at my employer. Additionally, I can’t be their change control coordinator; and I can’t be their action runner in test and prod. So… it sounds like this is made for O/S admins and little else.
We were thinking about Server Automation. However, this now sounds like any WebSphere or other 'advanced patching" components would still have to come to the root users so I’m even thinking that module would not work for us either.
It sounds like 4eyes, can work for my read-only needs given that these people would NEVER need to take an action. Hard to believe a commercial application in today’s world doesn’t come with a premade auditor or read-only role though.
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.
Thanks again. Yes, it is a hairy discussion and topic.
In my opinion, the heart of this is that BigFIx wasn’t initially developed for AIX. Therefore, it ends up forcing Windows assumptions upon us. This is what also leads to us having to download the patch code and build our own fixlets. Just in the past few weeks, we’ve even noted errors in the delivered relevance. Those fixlets are “generic” and don’t do fixes so they don’t really get tested so well either apparently. So… there are several ways AIX isn’t like a Windows box for BigFix purposes. We can very rarely use a packaged fixlet to quickly test a patch fix. You can do that for Windows and some Linux… just not the IBM AIX O/S (which is what we bought it for initially and were disappointed)
Our root users on AIX are responsible for AIX. Application Admins like for WebSphere are responsible for their applications and individual file systems to a large degree. They NEVER have root privileges. Thei apps and IDs and groups control their security. Root could switch user to do their work but they can’t switch to do root’s work. We use SUDO to enable them to switch and do some things, but those are very strictly limited and approved for specific commands.
Maybe Windows more often has a single admin type that governs the whole box and all things on it with a single ID.
That is very different from my mainframe and AIX world.
I don’t have experience with other products like BigFix. I know that tools are sometimes used to upgrade things like WebSphere. Those tools are definitiely not running as root. They are running with the minimum privilege needed to upgrade WebSphere with its ownership and group permissions. The personnel with those rights and privileges use their IDs for that work (not root). Actually using root can cause problems in some cases.
Happy to chat via phone if it makes sense but the answer seems to be that AIX ain’t Windows.
I’d say everything you are talking about applies to Windows when servers were hosting lots of services and using least privilege to manage them.
I think this is the big difference. Everything is going to more virtualization and containerization for both Windows and Linux. You may often have root access to a VM, but that VM only hosts 1 thing and 1 thing only, so the potential damage is minimal.
The root level access you are talking about sounds more similar to having full permissions to vSphere or Hyper-V, rather than having access to a single VM, having access to all VMs, but in this case VMs are each only doing 1 thing.
So the main issue is not the “Windows” origins (the product actually first came from the Mac though the first commercial product was on Windows) its the OS’s requiring us to be root to examine a lot of the things you need to see for the basic functionality of the product.
Security - requires root to protect the keys and other items from the general users of the machines
Inspectors - there are TONS of inspectors where we need to be root to get the data or the OS prohibits us from seeing the data. There is only one that is the reverse I know of where there is an occasional issue when running as root.
Actions - Its an interesting type of operator that could only take actions running as a specific user. Could be done but it seems rather a small request (I’ve not heard it before)
There is of course WebUI which I believe has enabled the “read only” user within it. Though it sounds like you would like to have the users be able to run actions but just not as root?
Can I ask how useful that is? The majority of actions are patching and this either requires many logins or root to be able to do a lot with the installed packages and seems to have pretty low usability?
I’m interested in what the view you are envisioning is as I haven’t heard that request before.
I suppose a decent way to describe the request is to enable non-root users to use BigFix to patch or upgrade things that are not owned by root. In fairness, that will generally involve things like applications/middleware like my WebSphere example. Those involve a non-root but still administrative role.
The crux of the matter is that it is NOT just root users that could have uses for a patching solution like BigFix. However, it is difficult to ensure that a non-root user can’t effectively end up with root privileges given that the client runs as root. Sure I can keep them to specific boxes and content but that doesn’t really allow them to be their own independent user for their specific non-root job role.
I think I’ve seen recent delivery of “Advanced Patching” which we don’t have. That was for WebSphere. However, I don’t know how they are getting around this issue… unless they are just having things done as the root user.
I think I can understand that. Its almost like requiring every action performed by this user would always be run as a user rather than as a root account.
I can see issues with that though, many installs require Administrative permissions (root or equivalent) to do anything so I’m not sure of the complete usage levels for this type of user.
I’m not saying it is easy. It’s just something that I have application administrators requesting and I can’t provide it. Folks want to use the product and we can’t let them.
My mental horsepower is measured in single digits, but my pondering of this might could be done by saying every user in BigFix defaults to a read only console. That’s the base. Then, each user could be set to be read only, or they might get to select which authorized user they wish to work as. In my example, the WebSphere folks would be read only unless they selected a user that I allowed them to be. They could not select full-root access. Then, BigFix would effectively “SU” to the chosen account and all of their activities would run with the permissions and rights provided to that account on the AIX box. If they had a different WebSphere account for other WebSphere instances, they’d need to logout and log back in to select the new user to be used in their current session. Again, they’d either be read-only or they could choose “who” they needed to be for their current task. I’d have to set up all of their approved accounts. Acutally, it would be good to do this with roles and such too.
How impossible would something like that be? I’m just making BigFix enforce which user accounts on the target box can be used by any given user. I force the “SU” functionality into the BigFix login instead of the “action scripts”.
Yes it makes sense and matches my thought. This would depend on a feature we currently don’t have which is to run as any arbitrary user so it will take thought.
With that type of feature content can easily be created that would essentially do that, but not for every action this user does. That would be an interesting extension of the model.
We dropped that effort way back when. At this point, it has come back alive.
As an FYI… my testing indicates that we can run their scripts from the Console with an su command.
In that light, the non-root users still own their scripts. They can edit their scripts. What they can’t do is edit the content in their BigFix site. They can read and execute their site. Given that all the commands in the fixlets will be run as an other ID (with “su”), any command they run in their script will run as the required ID and not root.
We just have to build their intial sites and infrastructure and a few fixlets pointing to and running their scripts. For example, different fixlets may be built to start JVMs, stop JVMs, install JVMs, and uninstall JVMs. They then admin their own code in their own scripts. BigFix just schedules and runs them.
Does that make sense and sound like a practical solution? I still don’t know of BigFIx addressing the requested need in other ways.