Why is custom options for Unbound removed in 21.7 ?

[franco]

> Development version for me is unstable.

The config is the same for Unbound whether you manually add it or let the GUI do it. That bundled with the same Unbound version I highly doubt instability suddenly appears in that fixes system and you will need to troubleshoot DNS anyway.


Cheers,
Franco

[Nekromantik]

> Development version for me is unstable.

The config is the same for Unbound whether you manually add it or let the GUI do it. That bundled with the same Unbound version I highly doubt instability suddenly appears in that fixes system and you will need to troubleshoot DNS anyway.


Cheers,
Franco

its not just DNS the router becomes un reachable.
even via IP.

[chemlud]

I had loggin derail (system) at some point on Development. Any real reason to stay on Developement and not to switch (back) to 21.7? 

[Nekromantik]

> Development version for me is unstable.

The config is the same for Unbound whether you manually add it or let the GUI do it. That bundled with the same Unbound version I highly doubt instability suddenly appears in that fixes system and you will need to troubleshoot DNS anyway.


Cheers,
Franco

I wiped and installed latest version stable version and it seems fine now.
Will wait for the changes from development to be in main release rather then trying development I think

[franco]

For all intents and purposes 21.1.9_1 development is the same as 21.7 development is the same as 21.7 release in terms of code and third party software.

The logging issue is also present in 21.1.8 -> 21.1.9 upgrade due to Syslog-ng and Python 3.7 updates. Not necessarily bad, but the missing reboot in this one (no new base or kernel updates) makes this log loop visible.

Honestly, I've never seen such a log loop before and there were no log code changes in 21.1.x either.


Cheers,
Franco

[CloudHoppingFlowerChild]

1. Ever since the OpenVPN custom options privilege escalation debacle in 2019 that affected *sense and prior widespread use of "just let us have custom configuration fields for all services" we decided to remove these ticking time bombs proactively and block their inclusion... slowly but steadily.

https://github.com/opnsense/changelog/blob/17ab9aee2c11fcaf811245b0b9a5e23a7c48a34f/community/19.1/19.1.8#L36

2. From a product perspective advanced users will add their custom glue and deprive meaningful use cases from the not so advanced users. It's better to work together and find GUI-driven solutions to problems everybody has.

3. For anyone saying "The GUI can't do this but when I edit the config file it gets overwritten" we usually advise to avoid using the GUI (core or plugin) and just use the service like anyone would on FreeBSD. Most decline, hence (2) is better in the long run anyway.

Cheers,
Franco

Franco,

Fuck you. I'm advanced enough to use the unbound config because I fucking learned how to do it because I needed to for the functionality. You just pushed that further out of reach. Now I have to jump through more fucking hoops in the name of protecting who? The less advanced don't know enough to break it.  fkja;lkadsf.,lk I can't fucking express how fucking mad I am. Not because you did it, but because your reasoning is so fucking broken. I wish I had paid for opnsense so I could dispute the charge, so I could demand my money back. I wish you had a patreon I supported so I could pull it.

[N0_Klu3]

You sir need to take a chill pill and relax!
Dont vent your frustrations like a child and act so horribly.

If you dont like this free open source software take your lack of business elsewhere and go whine to someone else that you pay for software.

[franco]

Franco,

[...]

Get over yourself. Just turn off Unbound in the GUI and run it via rc.conf with your own config file. I think that's time worth spent vs. pseudo-insulting open source code.  ;)


Cheers,
Franco

[blblblb]

Honestly the response is out of line and out of place... ranting antagonizes people (and I've had my share of vicious rants and trolling when I was younger ;P). If anything, I'm impressed with the way Franco responded (and I would have expected this to derail quickly if it happened in a different project).

On to the issue: custom config addendums are factually a security problem. Most of them allow for trivial UI to shell access, sometimes without a reboot. It's a good idea to remove them together with sanitizing inputs everywhere else, because in the end, you might as well be injecting a CRLF somewhere and a config snippet in some field. In that sense, they are taking the right steps in the long term. Of course at some point privilege separation of the web UI would be a proper course of action... but development roadmaps exist for a reason.

They left a nice way to include config mods for you... use it. All you need is shell access. Setup your user properly, add SSH pubkeys and voila. I hope you are aware that the custom options for Unbound was implemented in a way that was flakey and you had to work around it for most of the common uses. This problem is gone with the current custom config support.

edit for ref to documentation on the custom configs method: https://docs.opnsense.org/manual/unbound.html#advanced-configurations

[Patrick M. Hausen]

On to the issue: custom config addendums are factually a security problem. Most of them allow for trivial UI to shell access, sometimes without a reboot.

But you have to authenticate to the UI first. And if you are logged in you can create users, reset the root password, enable SSH, disable all firewalling ... anyway, to your heart's content.
I don't see how these free form custom options pose any additional risk.

Could you explain?
[/quote]

[blblblb]

On to the issue: custom config addendums are factually a security problem. Most of them allow for trivial UI to shell access, sometimes without a reboot.

But you have to authenticate to the UI first. And if you are logged in you can create users, reset the root password, enable SSH, disable all firewalling ... anyway, to your heart's content.
I don't see how these free form custom options pose any additional risk.

Could you explain?

[/quote]

Sure, a bunch of scenarios:

• You assume that everyone runs their firewalls as single-user/root only systems, whereas some people actually have user roles... so, let's say you have someone with access to a plugin that has custom options in the UI. Or a bunch of them. Call this "DNS admin intern".
• Custom options resulting in direct command execution or file manipulation override/bypass all ACLs in the UI, they just execute as the user of the httpd process or the CGI module (ex. WSGI or fastcgi).
• The entire ACL subsystem is moot so as long as there are obvious ways to bypass it.

Defense in depth. Also: you should not be administrating your firewall with a single user defined, and your root user data (including passwords and SSH keys) should be in offline storage (a Qubes system with a vault domain suffices.... along a HW password manager).

Of course if you do, you do so at your own risk and peril. But Franco and his team have to cater to the kind of users that do not run their systems with a maximum privilege principle.

[Patrick M. Hausen]

I did not know that OPNsense supports administrative roles. Thanks.

Most appliances I know don't.

[allebone]

Unacceptable behaviour from cloudhoppingflowerchild. As someone who has personally interacted with Franco multiple times and received essentially free enterprise support multiple times this reaction is unwarranted and unfair and not reflective of the hard and thankless work Franco performs. You should use a different product if a free community open source product provided to you in good faith does not meet your needs. I apologise on your behalf.

[franco]

You assume that everyone runs their firewalls as single-user/root only systems, whereas some people actually have user roles... so, let's say you have someone with access to a plugin that has custom options in the UI. Or a bunch of them. Call this "DNS admin intern".

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.

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.


Cheers,
Franco

[blblblb]

I did not know that OPNsense supports administrative roles. Thanks.

Most appliances I know don't.

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.