BigFix in a limited way for ILMT only

I work for a company that only uses BigFix for the collections for IBMs ILMT. We have another product that does what BigFix does. This creates several issues and limits the groups that can admin BigFix from a separations of duties perspective due to the inherent root access.

My question:

Could the BigFix clients be installed under a different ID than root or at least chowned to a different ID?

I am thinking either:

Installed under a single ID that is grouped to the IDs that the products are installed under with read.
Installed under the product ID.
The second option may still allow the fixlets for products to run. the only thing thing that must run is the app scan for the collections required for ILMT.

I realize this probably sounds crazy to those that use BigFix for it’s intended purpose, but for those that only use it for ILMT, this provides greater flexibility in who administers it and results fewer ways to access root that need to be secured.

Thanks

RJ

I’m not sure I understand the use case. While the BigFix Server services can be run under a non-root service account, the client will not function properly without full system access.

Are you trying to limit what the agent can do, under your current use case of ILMT-only, or starting to expand into other functionality?

It is the former.

With the agents running under root (I know this is unix only) the implementation can only be administered by a root user. That would be expected if BigFix were being used for it’s full capability.

The issue is we have another tool that does that and we ONLY use BigFix for ILMT. That leads to 2 issues.

  1. Only a root user can administer the implementation.

  2. It opens up yet another avenue to root that then has to be secured and monitored as a root user.

I realize the server components can run under different IDs but if the clients could be deployed under a non-root user and still satisfy the ILMT requirements, they it offers greater flexibility in terms of who administers the solution and you don’t have yet another avenue to root that you need to worry about.

Again, this is an ILMT only use case and is sacrificing what BigFix is capable of, intentionally.

Make sense?

I see. Yeah that makes sense…it just won’t work.

If you need to produce scans without running the agent as root, you might look into using the ILMT Offline Scanner.

But if you are going to do that on a number of systems, you’d need a way to distribute the scanner across all of your systems, execute it, and return the results to your ILMT server. Might I suggest…BigFix for that :slight_smile:
Otherwise perhaps you could wrangle something with your other tool. Or just have the same group of people run your BigFix deployment - it really doesn’t take make to keep it going.

Thanks

So, the client would not be able to do the scans if it were chowned to a non-root ID that was grouped read to the product IDs? Just the scans?

We have tools that can orchestrate actions across servers so once we have an image, install, config and propagation becomes easy.

Thanks

I’m…not sure why you’d even want to do a scan, if you were crippling the scanner to only report the software you already know about?

I honestly have no idea how well a disconnected scanner would run as a different account, or whether it would produce a result at all…but I know I wouldn’t trust whatever result it did give.

I think that is the issue, can you craft your configuration in such a way to satisfy IBM Auditors that your scans are accurate and correct, and can you swear to them you know your custom configuration is perfect?

The issue with changing BigFix Software scans to be done from a non-root user, is you can hide things from that non-root user.

This is true, you should restrict who has BigFix console access, hopefully require 2FA to login using SAML or similar means. Having access to the BigFix console is analogous to having root access to any machine you can target with custom BigFix actions. Generally with ILMT only, very few operators need access to the BigFix console, while more people may need access to the read only ILMT web portal.

What steps do you take to secure your other configuration management tool? Can you do the same or better with BigFix?

Have you considered using BigFix to help monitor the health of your other configuration management tool, and potentially fix it if it is broken?

1 Like

@JasonWalker, fair enough. Thanks for your time and thought on this!

@jgstew, BigFix is secured with appropriate access controls but from a root user perspective, since this is not a tool they use, this effort is required but effectively 100% overhead; no benefit. Switching tools to use BigFix is simply not in the cards. I think you for your time and thought on this matter as well!

The core issue is that the client runs as root and accepts commands from the FigFix server and executes them. Further, the only way to that I know of to limit this is through access controls in the BigFix server: thus, the admin has access to root and must be a root user.

Is there a way, through configuration to limit the commands the BigFix client can execute? Something like a Deny All and an Allow Scan Only?

I am trying to limit the access to root to something like a discrete sudo execution at the Client, not the server which could open admin of the server potentially to non-root users but only if the limitation on the access to root can be proven to be 100% at the client.

I don’t think there’s anything we could offer there, except to use the disconnected scanner (and let your existing root users run it).

I’m not sure how the IBM licensing team would regard it, so have a discussion with your sellers first. They will want to be able to audit that the machine counts and installations reported are correct, in particular if you are using their Sub-Capacity license features where they traditionally required BigFix or ILMT as a license term.

You got it.

Thanks for your time, thoughts and advice on this. I appreciate it. I was just checking to see if there was something out there. All of this discussion has brought me back to where I was in the beginning.

Thanks

I wasn’t suggesting it would be in this case. I was only mentioning that if your other tool stops working for some reason, BigFix could fix it. BigFix can passively monitor the health of your other tools.

The benefit is sub capacity licensing through IBM. This is the reason for ILMT. You get to pay less for IBM software by utilizing sub capacity licensing.

I’m not entirely clear what you mean by this. It is possible for a BigFix operator to have limited permissions which would prevent them from doing anything on an endpoint.

Yes, in a way there is. You can “lock” the bigfix agent for accepting actions, and you can exclude a particular site. So you could have the BigFix agents in your environment only allow processing of actions from the ILMT scanning site. This seems like part of the solution you are looking for.

I’m kind of confused at what you mean by this too.

You can give someone access to BigFix Console and WebUI but you can prevent them from creating custom content and from creating actions, at which point they DO NOT have root access to the systems that appear to them in BigFix. If however you give someone access to systems that appear in BigFix the ability to create custom content and deploy actions, then they DO effectively have root access to the systems in BigFix they can manage, though that does not have to be ALL systems in BigFix, as their scope can be limited to only the systems they SHOULD be able to manage.

I think you are confusing the scope in BigFix granted by the “Master Operator” permission vs that of a regular BigFix operator, which can be much more limited. There is also the ability to enable “4 eyes authentication” within BigFix which can either prevent an operator from taking any action at all, including a “Master Operator” or requiring 2 different operators to approve an action. One issue with “4 eyes authentication” is it ONLY works within the BigFix Console, but that doesn’t seem like an issue for your limited use case.

BigFix allows operators to have different levels of access, so some operators could have the equivalent of root access through BigFix while others would not, depending on what access you give them. This wouldn’t work if BigFix was restricted on the client side entirely, because there would NOT be a good way to give different levels of access to different operators on the BigFix side.

Another thing to consider is that access and activity within BigFix itself is easier to audit than on individual devices, unless you can already perfectly audit activity on your devices themselves, in which case you can use the same mechanism to audit what BigFix does on that system.

I understand the benefits of ILMT and I understand that the BigFix can be configured to restrict the creation of custom content. The problem is the app can create custom content. The process of creating the roles that cannot create content requires a person that can create roles that could create custom content which means if the system has access to root, they could have access to root. This is not a criticism because this is exactly how the system was designed and intended to be used. It is just unfortunate that IBM decided to use a tool this robust for the 1 narrow use case they required.

There is one exception to that. If the clients could be deployed or configured in a way that they (the clients) never provided custom access to root, then the core server would never have access to root. You said that:

Are you saying that there is a base configuration that all clients could be installed with that would “lock” the bigfix agent for accepting actions?

  • At least separate from the scan actions?
  • And / or that there is a configuration through which we could restrict the client agents from accepting actions from all sites?

If so, this sounds very promising. This sounds like a configuration that all agents could be installed with that would deny access to root meaning that the BigFix servers do not have that access and could be administered by non-root admins.

I am sorry but we missed that configuration when we were setting up BigFix the first time. If you could point me in the right direction, I would very much appreciate that!

And think you for sticking with me and trying to understand my questions!

1 Like

You can set all clients to be in a locked state by default, in which case they would not accept any actions.

You can set the ILMT scan site to be the only site that is exempt from client locking, in which case the clients would stay locked and reject any action from any other site.

You could “unlock” certain clients if you want, but then they would accept any incoming action sent to them.

This can actually be limited by using the 4 eyes authentication I mentioned above. In the ILMT only use case, lets say you have a central group responsible for the setup and configuration of BigFix & ILMT. You could have only 3 or 4 of them with the ability to do this (Master Operator), but require at least 2 of them to take an action or make certain changes. See useFourEyesAuthentication BESAdmin setting.

Also, in the ILMT only use case, generally you would create an automatic computer group in BigFix and that group would get targeted with the ILMT scanning actions, and then you would control computer membership to that group using the existence of a file or a BigFix client setting, or any combination of that and other things. This way you never have to do anything in BigFix to add or exclude computers from ILMT scanning and that can be handled within BigFix or outside of BigFix.

BigFix is extremely flexible, and as you are finding out, probably has a solution to your config requirements.


Here is a screenshot of the Action Locking settings in the Windows BESAdmin GUI: (you can run it on the same system as the console, otherwise there is a Linux command line version)

NOTE: The example site URL of ILMT above is NOT correct. Would need to figure out what that should be exactly for the ILMT site.

@jgstew Thanks. I will need to look into this.

I guess the only question I have is

Is the client agent lock a client side configuration or a server side configuration?

You description reads like a Server side configuration in which case, the FourEyesAuthentication becomes very important.

Again, thank you very much for your time and thoughts on this matter.

1 Like

It can be either. If you choose “Console” then it can be configured server side OR from the client side. If you choose “Client” then it must be configured on the Client machine directly.

In your case, you want the “Action Lock Controller” to be “Client”

See this screenshot from the same BESAdmin GUI Interface:

My BESAdmin has the default configuration in all of the screenshots, but showing the changes to be made, other than the “Gathering Interval” which is set to 8 hours instead of the default of 24 hours.

Yes, Client side. In our case, I would expect that we would put the client code in Nexus and then define a script that set the configurations, standard and host specific, through a VRA Blueprint. The tag you mentioned would be part of any Platform Build for an ILMT monitored product to dynamically create the group.

Thank you