World: r3wp

Since MAKE object! isn't a hybrid function like MAKE module! (which 
calls sys/make-module*), we probably don't want to reduce capabilities 
on a per-object basis.

It seems to me that you are still talking in terms of plugging all 
the holes in the myriad of capability that would supposedly be around. 
This is not how true capabilities work. They implement POLA: there 
is no capability unless it is needed, and in that case, it needs 
to be handed down as a token by the assigner of the work. If the 
boss doesn't have the token, the employee will by definition not 
be able to do the work

REBOL is a virtual machine with strong typing (as long as extensions 
are protected well enough). You have complete control over the world 
the code executes in, so the potential is there to make the process/thread 
separation irrelevant for security

I don't see why capabilities would need to be checked on every word 
access. The critical point is the binding, and REBOL uses this well 
to optimise word access. Capabilities would need to be determined 
at binding time, so that binding will fail if the required capability 
token isn't available

Three security models:
- SECURE protects access to external resources.
- (UN)PROTECT protects changeability of internal structures.
- PROTECT/hide manages binding visibility.

We don't jsut need to protect files, we need to protect things like 
passwords in memory, access to capability tokens, etc.

Which can all be done in a capabilities model

Have you studied the E language, and Genode for that matter?

If you use capability tokens to protect binding visibility, then 
every word access would need to check against a capability token.

I still don't see that. Binding doesn't change on every access; that's 
the point of this optimisation

Binding visibility, not binding change.

First you have visibility, than binding, than access. Why go through 
all those stages on each access?

OK, let's work this through for only PROTECT/hide to see how the 
concept would affect things. PROTECT/hide works by making it so you 
can't make new bindings to a word - that way words that are already 
bound can be accessed without extra overhead. Adding capabilities 
to this means that you could create new bindings to the word if you 
had the token, but not if you didn't. However, with PROTECT/hide 
(currently) the already bound words don't get unbound when they are 
hidden, just new bindings to that word, and if you have access to 
such a prebound word value then you can make new words with that 
binding using TO, which effectively makes prebound words into their 
own capability tokens. So PROTECT/hide *as it is now* could be the 
basis of a capability system.

Cool :-)

The problem that a capability system has of making sure capability 
tokens don't leak is pretty comparable to the problem with leaking 
bindings that we already have to take into account with the PROTECT/hide 
model, so switching to a capability system for that model gains us 
nothing that we don't have already. And we've already solved many 
leaking binding problems by doing things like having BODY-OF function 
returning an unbound copy of its code block rather than the original. 
The PROTECT/hide model works pretty well for that, so it's just a 
matter of closing any remaining holes and making sure things are 
stable.

The fundamental gain is that you switch to a POLA model from the 
current model where all code in a REBOL process has all capabilities 
unless you manage to stop some of them

For PROTECT/hide we already have that. So let's move on to the other 
security models.

Does all code get created PROTECT/hidden?

No, but all code created after the word is hidden doesn't get access, 
and only code created before the hiding has access to a token (bound 
word) that will let it create new code with access. You get the same 
sharp separation between code with access and code without.

A POLA model is where you start out with no access. If you have to 
PROTECT/HIDE afterwards, that's the reverse of POLA

Basically, the code that creates the token is the only code that 
has access to the token, and it can pass that token along to other 
code if it is safe to do so. The only difference is that code isn't 
protected unless it needs to be.

Yes, the reverse of POLA. Capabilities is about building a POLA system

For the benefit of those trying to follow this discussion without 
having read the articles, could you at least once expand the POLA 
acronym?

Principle Of Least Access

Thanks.

Again, did you study true capabilities, especially in the E language, 
but also in Genode and the ground-breaking KeyKos and EROS systems? 
If you didn't, I can understand why we don't understand each other. 
By the way, POLA is not a capabilities term, but a generic security 
term

I got the overview, but there are some limitations when talking about 
a language like REBOL.

There are limitations in the current implementation, but not in the 
concept

Please study http://erights.organd http://genode.org.Without that, 
this discussion probably won't go anywhere

Not so.

OK, the problem with that model *in this case* (PROTECT/hide) is 
that we are talking about object fields here, bindings of word values. 
REBOL objects bind their code blocks before executing them. If there 
is going to be any blocking of bindings, at least the object's own 
code needs to be bound first. This means that if you are going to 
make word bindings hidden, you need to do so after the object itself 
has been made, or at least after its code block has been bound. You 
can do this binding with PROTECT/hide, or with some setting in an 
object header, it doesn't matter. Since words are values and their 
bindings are static, being able to create a new word with the same 
binding means that you need access to a word with that binding, with 
*exactly* the same visibility issues as token access. The difference 
in this case between POLA and PROTECT/hide is whether object fields 
are hidden by default or not, not a matter of when they are hidden.

We can't directly use the E model because E is compiled, so there 
are things that happen at runtime in REBOL that happen in the compiler 
in E.

It's a VM, so you still have control over them

It's still compiled, and word lookup is handled by the compiler, 
not at runtime.

What difference does that make?

For E, these capabilities can basically be resolved statically in 
a lot of cases by the compiler. For REBOL, every capabilities check 
would need to happen at runtime.

Yes, obviously. So, no difference in possibility

I have to go now (well, an hour ago). May we continue this later?

Certainly. It's been a favourite topic of mine for a decade :-)

From http://erights.org/history/original-e/programmers/Econcepts.html

Once the capability to reference an object or send a message has 
been granted, no further run-time check is required.

I hadn't checked E for a long time, but they are now implementing 
capabilities in JavaScript for Google, so we're going to hear from 
it whether we want or not:

http://code.google.com/p/google-caja/

I guess this is another one of those things where REBOL has the choice 
between being ahead or staying behind a lost opportunity

Pretending that security doesn't matter is a worse policy.

 - for me, security does matter, but this just pretends to be security

And what never matters to me is pretence.

Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

 - this is exactly a complicated way how to pretend something is more 
 secure than it actually is. The only real effect is obtaining a less 
 comfortable and more annoying system

As for the

    a: quote (1 + 2)
    a ; == (1+ 2)


, that is not a "security measure". It is just a more comfortable 
behaviour.

...and I know it, since it was me who proposed it

On the other hand, I would never propose

    do a


to yield anything other than 3, pretending it might be perceived 
as "more secure".

Regarding APPLY- I was the one who implemented the first APPLY in 
REBOL, and I was the first who used it to obtain a more secure evaluation 
than using DO