Notes about SECURE

As you know, secure is a function that specifies security policies in REBOL.

In R3, there are many changes to secure and to the policy mechanism, and I want to cover a few of them here.

Please Note:

A52 is the first release that will work with these examples.

Also, please don't report bugs on this in CureCode as of yet. This is still in progress.

Post comments and ideas to R3 Chat heading #3515.

SECURE is a mezzanine

One of the first big changes is that secure is a mezzanine, not a native. Why? Mainly because it's difficult to write at a lower level.

It's still fairly complicated, view it with:

>> source secure

and you'll see it's about a page of source code. One of the largest functions in REBOL.

To get the official source code with comments, run R3, and enter:

>> chat
...
user>> 26
user>> get mezz-ports.r
--- Note: wrote file: work/r3/mezzanines/mezz-ports.r

The file is now local. (You can use the OD command to open the directory from chat.)

What does SECURE do?

You know that secure is used to set security policies. In R3, a few things have changed, but the general idea (and syntax) is the same as R2.

To get started, type:

secure query
[
    net allow
    file allow
    call throw
    envr allow
    debug throw
    browse allow
    plugin throw
]

This shows the initial policies for R3. Notice that there are a few new policy classes (called targets): envr, debug, browse, and plugin. Here's what they do:

	envr	access to system environment variables.
	debug	access to R3 internal debugging functions, like `stack` (that in the hands of a guru could be used to bypass security, so we protect it now.)
	browse	calling the browser
	plugin	loading plugin modules (because they can contain a type of native function that can do anything, so must be secured.)

When setting policies, keep in mind that various helper functions may use some of these features. For example:

>> secure [browse throw]
>> bugs
Opening web browser...
** Access error: security violation: http://curecode.org/rebol3/
** Where: browse bugs
** Near: browse http://curecode.org/rebol3/ exit

General vs. detailed policies

In the query above, you are seeing a block of general policies. This block is a dialect, just like it was in R2. You can define detailed policies for some targets, such as file and net.

For example, here are more detailed file policies:

secure [
    %files/ [allow read throw write quit execute]
    %cache/ allow
    file throw
]

In the future we will probably also allow detailed policies for call, browse, plugin, and other targets. Those are implemented at the lower level, but secure needs a bit more code for those.

What's missing?

In the A52 version of R3, a few things are still missing:

ASK policy does nothing yet. Before we can add that, we need a way to popup a security requestor for the user to respond to (or at least at the console level.)
Level change detection. You can modify security upward or downward right now. We need the requestor to popup when lowering security.
File path comparisons are relative. That's not going to work, because if you change-dir, your prior security settings won't work. More to do here.

How SECURE is secured

You might wonder how secure is protected as a mezzanine. Well, it's not, but if you attempt to redefine it, you'll find that your new version does not work.

If you look at the actual source code (the file) you will see why. The function binds two internal functions to system/state/policies, then protect hides those policies. Now, only those internal functions can access it (in theory at least - tell me if you find a way.)

Disabling security for testing

If you want to modify the secure function and test your changes, you must boot R3 with the -s option to disable security. When you boot that way, the protect/hide is not done on the system/state/policies, so it is possible for you to access them as you test.

How it works internally

At the C level, we want security to work efficiently. Rather than parsing the security dialect for every check, the security policies take the form of an object that holds either tuples (for general policies) or blocks of values and tuples (for detailed policies).

The tuples specify the policy as [rrr.www.xxx] where the value of each ccc indicates allow, ask, throw, and quit. If you boot with -s and probe system/state/policies, you can see the current values. The secure function translates to and from those values, to make the security dialect more user friendly at the REBOL programming level.

Post Comments