[SOLVED, adapt to change] Shell for non-admin users

[linore]

After testing the update to OPNsense 24.1.1, our tooling regarding shell login for non-admins got broken with the info message "The login shell for this non-admin user is not active for security reasons" on System: Access: Users. This is because of the following change "system: prevent activating shell for non-admins":
https://github.com/opnsense/core/commit/a0581ae0f62b1d3886e8dd5c6fb3c81e3afd8908

The suggested solution is: "This may cause custom tooling to stop working, but can easily be fixed by giving these required accounts the full administration rights."

For us, this increases the attack surface rather than strengthening security. In our environment, webinterface and shell access reside in two seperate management networks with a non-admin user granted very limited read access via shell. If this user has to be part of the admin group, this would extend the authorization via webinterface unnecessarily. This is because there are cases where "permissions(ssh) < permissions(admin)".

This change may have good intentions with unintended consequences. Following compliance requirements such as audits and certifications might actually decrease the overall security of some setups.

On the other hand, I can well understand the security concerns regarding a possible privilege escalation via shell access.

I've come up with the following constructive suggestions:

• Instead of blocking shell access for non-admin users, keep the infobox with a warning, e.g.:
  "The user has been granted shell access without being part of the admin group. This is a danger zone. Please be aware of unintended security implication. If no further steps are taken to limit the users shell permissions, the user might have broader access via shell than via webinterface."
• Introduce a dedicated predefined shell group for non-admin users. Users with shell access will have to be explicitly added to the shell group. This could be supplemented by a similar information about security implications.
• Introduce an opt-in-check-box per user explicitly enabling shell access. This again could be associated with a warning about unintended security implications.

One of these suggestions might be a more user-centered approach than the current change.

[franco]

The side effects are not unintended. The spurious CVEs being produced by "researchers" are exactly what makes this a necessity so this is a case of "it is what it is".

You cannot secure a single shell user on against something bleeding through from "administrative" purposes, be it service config files, sockets, logs or otherwise.

> 1. Instead of blocking shell access for non-admin users, keep the infobox with a warning, e.g.:

Researchers have long ignored best practice when issuing their CVEs. If it's configurable they will raise an issue for something else they say they can do with it that they shouldn't.

> 2. Introduce a dedicated predefined shell group for non-admin users.

Could do that, but you have to keep in mind it creates  false sense of security. The shell is really all you need to exploit something same as given for point 1.

>3. Introduce an opt-in-check-box per user explicitly enabling shell access.

Same same but different. That's what the shell selection is for actually. It's still being mishandled like said in point 1.

I'm not against exploring other options, but the past and also the current LINCE certification process make hard requirements on this for good reasons.

I think since a few major version you can add add your own users from the console not handled by but also not scrubbed by subsequent reboots (unless the user file/db was corrupted).


Cheers,
Franco

[linore]

Thank you for your quick and detailed reply with references to the certification.

In order to adapt to the change and take it as "it is what it is", a possible solution in our environment could be to use seperate user accounts for webinterface as well as shell access. This reflects our setup with two seperate management networks. The account with shell access can be created using the option "Generate a scrambled password to prevent local database logins for this user". Thus the user may be part of the admin group, but actually not be able to access the webinterface. For SSH, we've already used authorized keys. That way, we'll be able to keep our tooling and processes with only little adjustments without worsening our security footprint.

Just for curiosity, I've asked ChatGPT for an idiom regarding my initial post. The answer seems to be spot on:

In the context you've provided, a relevant phrase could be:

"Too secure for its own good."

This phrase is used to describe a situation where something is made overly secure or restrictive to the point where it becomes impractical or unusable. In the case of the ICT certification requiring OPNsense to be locked down and limited in functionality, it may indeed result in the product being extremely secure according to theoretical security threats. However, this excessive security measure could render OPNsense ineffective or dysfunctional for practical use cases.

In essence, "too secure for its own good" implies that while the intention may be to enhance security, the outcome is a product that is overly restrictive and ultimately less useful or valuable. It highlights the trade-off between security and usability, suggesting that an excessive focus on security measures can sometimes undermine the practicality or functionality of a product.