Why is custom options for Unbound removed in 21.7 ?

[blblblb]

Actually this is what https://github.com/opnsense/changelog/blob/a16acafb81b2df83a0c7feb1faa6f29fe2825107/community/19.1/19.1.8#L36 was all about over two years ago. Anyone with access to the OpenVPN configuration pages was basically able to dispatch arbitrary commands on the firewall. We locked editing custom options fields for non-administrators for that reason.

This why we also removed the raw file edit and command execution pages almost after our initial release 15.1:

https://github.com/opnsense/core/commit/f2a21ac4462
https://github.com/opnsense/core/commit/f958a96258d

The clearer issue is direct access through the ACL to those pages, but what if you could write arbitrary commands into the config.xml to gain access to those pages? From a harmless page you could get access to more dangerous pages.

I haven't looked into the internals of the webgui beyond checking if it runs unprivileged (it runs as root per the php-fpm pool configuration), but in the end, any loophole in the UI will allow for unconstrained root access. Since the process runs as root, you could even write a PHP stage to inject a module in the kernel, entirely off memory (has been done for Linux, for example), without requiring any sort of shell command interaction, just the API exposed via PHP and the POSIX & BSD syscalls.

This is why I mentioned defense in depth, it's not rational or making any sense to criticize the effort to remove custom options or anything in the UI that can allow for ACL bypasses.

This was also highlighted by the implementation of the read-only privilege which is per definition not allowed to write config changes, but if you have access to the configuration backup page you used to be able to switch to older config.xml backups or even upload a new config.xml:

https://github.com/opnsense/changelog/blob/a16acafb81b2df83a0c7feb1faa6f29fe2825107/community/18.7/18.7.7#L27

There are still pitfalls such as non-root shell access whereas potentially anyone could read the config.xml even if they have no GUI access at all. Basically we recommend never giving shell access to non-root users, but ultimately this should be fixed in a more sensible way. I think OpenVPN is currently blocking this effort because it wants to read the config.xml in an unprivileged manner.

As for *sense having an ACL... it is relatively flexible and was inherited from m0n0wall itself, but has a couple of implementational artefacts. Since it was never shipped with predefined roles I think the user base for this feature is relatively small even today. I know of a commercial m0n0wall fork that actually used this ACL extensively, but it was a special purpose fork aimed at captive portal operation where there were technical and non-technical people required to operate different aspects of it.

I forgot about that config.xml trick :-)

I agree that the user base for the ACL is small, but just to name one example for a system I was involved with (consulting/advice for the operations staff, they also used a well known fw product similar to OPNsense and repeated the same strategy): they had NOC users that could edit firewall rules and nothing else. This is plenty damaging (you can redirect traffic for higher privilege users...) but nonetheless they still separated things like VPN management, etc.

Of course the market for niche firewall solutions is very different than say, Palo Alto and co.

[Patrick M. Hausen]

I don't know any enterprise products that don't support fine-grained ACLs. If you talk about consumer/prosumer "crap", then yeah, most of them are garbage if you need proper security/privilege separation of some kind (let alone the ability to have audit trails), but they are meant for the market they cater to. Franco responded with far more detail.

I would not put the Sidewinder firewall or TrueNAS into the "crap" category. But TrueNAS has got only one root account for the web UI, and Sidewinder supports an arbitrary number of individual admin accounts but only with either r/w for everything or r/o for everything.

[blblblb]

I don't know any enterprise products that don't support fine-grained ACLs. If you talk about consumer/prosumer "crap", then yeah, most of them are garbage if you need proper security/privilege separation of some kind (let alone the ability to have audit trails), but they are meant for the market they cater to. Franco responded with far more detail.

I would not put the Sidewinder firewall or TrueNAS into the "crap" category. But TrueNAS has got only one root account for the web UI, and Sidewinder supports an arbitrary number of individual admin accounts but only with either r/w for everything or r/o for everything.

The use of "crap" there is synonymous for "consumer or prosumer gear" or lower tier network appliances.
TrueNAS has a lot of effort behind it, and even though I personally do not use it (I have gone through the pain of manually configuring zfs pools, nfs servers, etc), it fits a very specific niche in the market and it does so very well. :-)

As an entirely subjective observation: I would not put my money in any McAfee products as far as their SIEM offerings go and so on... but this is offtopic here ;P

[Patrick M. Hausen]

Sidewinder belongs to Forcepoint/Raytheon now and is EOL. But it definitely had its time, in my opinion.

[chemlud]

...just to add: the promised 50.- € donation for the project is out, plus 50.- € donation for general charity (flooging victims, refugees, social service). Mission accomplished, regarding DoT and OPNsense :-D

[franco]

...just to add: the promised 50.- € donation for the project is out, plus 50.- € donation for general charity (flooging victims, refugees, social service). Mission accomplished, regarding DoT and OPNsense :-D

<3

[sToRmInG]

Is there a reason that the custom config files I create disappear from the folder after I restart unbound?

To be more precise. Let's say I create a new config file /usr/local/etc/unbound.opnsense.d/plex.conf with the following content:

Code: [Select]

server:
    private-domain: "plex.direct"This config file disappears when I restart unbound.

*EDIT*
Nevermind, it seems to have been related to the indentation.

[Patrick M. Hausen]

Is there a reason that the custom config files I create disappear from the folder after I restart unbound?

Are you creating them in /usr/local/etc/unbound.opnsense.d as documented?

[sToRmInG]

Is there a reason that the custom config files I create disappear from the folder after I restart unbound?

Are you creating them in /usr/local/etc/unbound.opnsense.d as documented?

Yeah, I think there was an issue related to the indentation. The config file seems to be persistent now.

[crissi]

If now the custom-options Form is removed from the GUI, is there any chance to get the custom-options.conf with the adaptations in the backup / and later on with a fresh install recovered....

[franco]

Code: [Select]

server:
    private-domain: "plex.direct"

Private domain is supported, see Services: Unbound DNS: Blocklist.

If now the custom-options Form is removed from the GUI, is there any chance to get the custom-options.conf with the adaptations in the backup / and later on with a fresh install recovered....

The whole point is not making something uncontrollable stick in the configuration in the first place.


Cheers,
Franco

[Taomyn]

So after upgrading to 21.7 and temporarily setting a system external DNS beforehand, I have successfully gotten Unbound working as I want it.


I decided to drop DNS-Proxy for DoH/DoT and used the DoT option in Unbound (I might revisit using DNS-Proxy in the future). The only thing I needed to work around was getting Unbound to use the local Bind service for lookups of my internal domain - Bind is set up as a slave to the main internal zone as this helps the firewall use internal FQDNs when the it is starting up. So I used the Custom plug-in to allow me to add "do-not-query-localhost: no" then Unbound was allowed to contact Bind - hopefully this could be added as a standard option of the main GUI.

[sToRmInG]

Code: [Select]

server:
    private-domain: "plex.direct"

Private domain is supported, see Services: Unbound DNS: Blocklist.

Ah, thanks for the hint.

[crissi]

Code: [Select]

server:
    private-domain: "plex.direct"

Private domain is supported, see Services: Unbound DNS: Blocklist.

If now the custom-options Form is removed from the GUI, is there any chance to get the custom-options.conf with the adaptations in the backup / and later on with a fresh install recovered....

The whole point is not making something uncontrollable stick in the configuration in the first place.


Cheers,
Franco

the best to not get something uncontrollable in the configuration and have a backup of custom options in case of restore would be really easy, just add the custom-options form back ...

[franco]

Or just not. ¯\_(ツ)_/¯


Cheers,
Franco