Lucee sandboxing - best practices?

Curious to what are the best practices and variable solutions in sandboxing/limiting access to different resources for Lucee?

What I am most interested in is limiting access to directories, database tables & functions, email accounts/servers and mappings - general access and additionally for each domain that appears in Tomcat’s server.xml config.

ACF used to have such a practical section in the Admin interface dedicated for sandboxing where all these could be set, along with restricting access to some functions (mostly file & directory related). Would be extremely nice to see something similar in Lucee.

The only solution I found and read on the forums is spinning up different parallel Lucee docker containers, each with separate settings, which is a both resource consuming and haste to manage.

The web.cfm interfaces for each domain seemed to be an attempt towards this but never really managed to make them work properly, don’t seem to persist, plus they didn’t allow sandboxing the above mentioned features.
Anyone found some better solutions?

OS: Alma Linux (6.12.0-211.56.1.el10_2.x86_64_v2) 64bit
Java Version: 25.0.3 64bit
Tomcat Version: 11.0.25
Lucee Version: 7.1.0.204
Docker build

@stevieosaurus, here are a few things in reply.

1 - First, I’m not aware that Lucee ever offered the same sort of control that CF sandbox security did. Partly that was because yes, the multiple contexts feature of Lucee was one way such segregation was possible. But note that Lucee 6 deprecated that “multi-mode” feature, and Lucee 7 has removed it. Using separate containers or instances would be the most suitable alternative.

2 - As for cf’s sandbox security feature, I’ll note that that was based on their leveraging the java “security manager” feature…which has itself now been deprecated for a few years and is slated for removal in a coming Java release.

FWIW, I’ve not heard from Adobe what they will do to replace that, if anything. Sadly, most people never used or heard of the feature, though I celebrated it in a two-part article series long ago.

3 - But here’s news: Pete Freitag (Foundeo) has stepped in to fill at least SOME of this gap, with his new commercial Jarlock tool, intended primarily for Java shops (who leveraged the security manager) but with some features for CF and Lucee–though definitely not all that CF sandbox security had offered.

Specifically, of those you seek, my read of its docs is that it could be used to blacklist functions (and tags, though you don’t ask that). But it does not provide for folder/directory control, nor dsn control (cf didn’t do “table” control), nor mappings (I don’t recall cf SB offering that). As for limiting what servers could be called (mail or db, etc), he does offer that (in his JARLOCK_ALLOW_SOCKET_CONNECT config element) . See his docs page for details. Again though, it’s not free.

I’ve also pinged Pete about this post and my planned reply here, so he may correct or elaborate things.

4 - Finally, it’s worth noting that a degree of the control you seek can also be afforded by using application-level configuration of things (dsn’ s, mappings, etc) rather than defining them in the admin. That way, only code in that app can use that thing.

That’s probably the most expedient approach that folks looked to for such separation, but just as you eschew containers I realize you may prefer a solution that doesn’t require altering your code (even just application.cfc/cfm). The sandbox did indeed offer such “global control”, for those who leveraged it.

And just as cf had that hidden gem, perhaps there’s something Lucee has up its sleeve that I’m not recalling. :slight_smile:

I suspect others will have more to say in reply to you. Until then, I hope this helps you and perhaps other readers.