modularisation = towards installs with lower vulnerability/attack surface

[chol]

From the OPNsense roadmap it becomes clear, that this new project is going to a more closer path with FreeBSD and its security-maintained standard packages .

?Is it therefor planned to construct a modularisation of OPNsense, with install options like small, medium, full OPNsense installs, meaning, to have a feature/service-rich or a feature/service-poor install? Not everyone needs all the features, esp. when the full install come with cluttered GUI branches and flamboyant services all not touched/needed.

A feature stripped or exactly on-site customized OPNsense install would gain in security and a lower vulnerability.

[weust]

This has been discussed on IRC. Stop by there to discuss as well ;-)

[franco]

Is it therefor planned to construct a modularisation of OPNsense, with install options like small, medium, full OPNsense installs, meaning, to have a feature/service-rich or a feature/service-poor install? Not everyone needs all the features, esp. when the full install come with cluttered GUI branches and flamboyant services all not touched/needed.

I am traveling right now so I do not know what the IRC discussion is all about but I think this is more or less the gist of what we want to achieve with the new package system building on further feedback we got from the m0n0wall community:

Instead of just adding packages on top we'll start splitting off bits and pieces of the main installation into packages as well (e.g. PPTP is one such thing to hopefully appease everybody). This will severely reduce the attack surface of the standard installation and avoid feature bloat, but don't expect to suddenly get rid of a large install media as PHP and Python are needed for core functionalities as well as a standards-compliant base system (world and kernel with most kernel modules).

On top of that, again, we try to deliver fast security updates and general fixes to keep the project moving forward at a sensible pace.

I hope this helps.

[weust]

Franco, it was a week or two ago I believe. Think you were there as well.

[franco]

In any case, was the summary spot on or did I miss something?

[chol]

So - for clarity to me, and I am not exactly the  sharpest or fastest in thinking- you may give users in near future the install-gui (or CLI) options to select packages or bundled ones  (called "roles" in PC-BSD, as I noticed during a recent install)  to tailor the OPNsens one needs?
I mean the real end-user choic -or power so to speak- over what gets on the disk during install? With later options to glue on more features/services/options via packages?

Thanks!

[weust]

Think it was, Franco

Chop, I think one of the ideas was to activate roles based on need.
Chosen from an advanced part of the GUI. Something like that.
But, those were mere ideas and thoughts. Nothing set in stone as of yet.

[franco]

Roles and packages are different things. The new ACL will support controller/action based access. So you can view certain functions or not at all, or set fine-grained read/write access through individual controller actions.

Packages in OPNsense will be as follows: the install media is pretty small and will only install the minimal base system. Afterwards, you'll be able to pull packages through the GUI much like pfSense does it, but with FreeBSD's native pkgng system. The key difference will be that we do split down the current base version in installation base, official packages, and unofficial packages from the community.

While all of this seems logical and some may have talked about it for years, actually doing it in a way that it works as simple as possible is the hard part we will definitely focus on getting right.

[weust]

I see a lot of IRC discussions coming
All for the better, but I like what you put here do far.

[franco]

Indeed, I'll be back on Friday. We've found that today's 15.1.8 will be a huge step forward in this direction. Stay tuned.

[weust]

Looking forward to it, as always