Rebol2 had a useful feature of layering on top of the OS's traditional file permissions model, with an extra set of permissions that apps were allowed to have. A script couldn't necessarily assume it could delete files just because the account that ran it had privileges to do so. This was configured via the SECURE function, and it also had command-line switches.
R3-Alpha attempted to push a certain amount of the SECURE dialect into usermode. Carl wrote about the motivation, saying the usermode function was "about a page of source code. One of the largest functions in REBOL"
https://github.com/rebol/rebol/blob/master/src/mezz/mezz-secure.r
But the infamous "SECURE is disabled" message is there because it wasn't ready. R3-Alpha was released with the SECURE function overwritten with a no-op during boot.
I think it's time to mothball it, for now
I'm a huge fan of the principle of least privilege, and have always advocated for these kinds of features in OSes...long before I'd seen Rebol. So I'd not deleted it because it seemed like food for thought...serving as a reminder of the issue. ("Before one does some kind of thing you might think privilege escalation would be necessary for, there might should be a call to Check_Security()...")
But I'm going to strike it for now, here are some reasons:
-
The feature was unfinished and there's no time to work on it. There's really not much code there at all (such as there is no facility for asking you to escalate the privileges.)
-
I don't know what level of testing it ever received for making sure people aren't doing weird things with non-canonized file paths to get around any limits you tried to set. (e.g. "You can't access %/c/foo/* but you can write to %/c/bar/*, so you write to %/c/bar/../foo/hack.exe")
-
On that point, it's extremely difficult to get security right, and using a term like "SECURE" runs the risk of looking amateurish. Especially when it's a bunch of commented out code that no one has run. And Rebol has a lot to answer for as far as security goes. (See the "Philosophy of Security in Rebol" if you want to chime in on that.) Launching a feature with such a name carries along with it the suggestion of a lot of development and testing that there is no developers or testers chomping at the bit to volunteer time for.
-
If you're just trying to help people avoid shooting themselves in the foot, there are some completely-usermode ways of tackling this kind of thing today in Ren-C, using function compositions and HIJACK. You can create a screened version of READ or WRITE or GET-ENV and expose that with creative limits that the SECURE dialect wasn't going to implement (e.g. only allow reading from certain URLs with a given throttle rate, or between certain hours). Ren-C is trying to address these kinds of modifications and the binding/isolation that would make it work, vs. try and box in a feature that any other language might be able to offer just as easily.
-
Every OS (or browser) is tackling privileges as they apply to its own domain. While the SECURE of R3-Alpha's era may have only needed to think about integrating with a filesystem privilege model, designing a truly holistic cross-platform security dialect is probably a pretty big task. A concept based on the idea of bit-masks in tuples would need revisiting to mesh with modern systems (and I think TUPLE! needs serious review as a type and use of periods)
-
Pretty much all the calls are in code that's slated for replacement, and they kind of just complicate the picture with extra parameters. It's illusory that shuffling the commentary-code-that-doesn't-run with the parameters-that-aren't-used does any good in bringing about a better design. The only thing that brings about better designs is sitting down and actually thinking them all the way through.
But mainly, it's a tangent there's no time for...
It's hard to argue that Rebol has specific relevance to this problem area moreso than any other language does. Really, it's trying to take on what should be the OS's job. Because if an OS in this day and age doesn't do this kind of thing, what is it doing?
(Where the OS sadly lacks, third-party apps or tools can pick up the slack. One particularly good one UI-wise for Mac as far as the network goes I once used was Little Snitch. That doesn't help with things internal to the interpreter like having privilege to use debug routines...but can pick up some of the slack if it's really an issue, and likely do a better job of sandboxing all angles of access--e.g. calls through DLLs that aren't beholden to making Check_Security() calls inside the r3.exe)
This isn't a priority item for getting to a "Minimum Viable Product" (a term the WebAssembly people keep using). No one is not using the system because this feature isn't there, and no one would start using it merely because it was. It's a "nice-to-have" feature that would need significant design and testing cycles that aren't available.
So in the interest of clearing the air and making sure all the code in the system that's there has a reasonable reason to be there, it goes. Since no development has happened on it, the R3-Alpha GitHub snapshot is as good a place as any for someone who thinks that's the place to start looking into this...