r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Ladislav
10-Apr-2011
[7878]
That is why I am not a fan of using such a terminological mess
BrianH
10-Apr-2011
[7879x2]
But using them counts (indirectly) as using constructors.
I agree that it is a terminological mess, which is why I was careful 
with my phrasing.
Ladislav
10-Apr-2011
[7881]
I do not know whether I should repeat my opinion or not, but, here 
goes:

#[map! [...]]


and similar syntaxes are not "constructors" in the standard sense 
of the word. That is why I do not like seeing such phrases in documentation 
or elsewhere.
BrianH
10-Apr-2011
[7882x2]
I agree that it is a terminological mess
Andreas, in the OSes with which I am familiar, you can't set a file 
to read-only and then count on that file staying read-only unless 
the user is asked for permission to change that setting. In REBOL 
you can. The security of a DOable %user.r depends on it not being 
writeable between when REBOL shuts down and when it starts up again. 
So that means using OS permissions to guard it, and those are based 
on user capabilities, not enough protection. The situation is different 
with %rebol.r since we only load it from the same location as the 
R3 executable, and that location can be protected with user permissions; 
this is why we can still DO %rebol.r in R3.
Andreas
10-Apr-2011
[7884]
The security of a DOable %user.r depends on it not being writeable 
between when REBOL shuts down and when it starts up again.

Why?
Ladislav
10-Apr-2011
[7885]
I do not agree with "The security of a DOable %user.r depends on 
it not being writeable between when REBOL shuts down and when it 
starts up again."
BrianH
10-Apr-2011
[7886]
Because you can have a worm spread using a combination of REBOL and 
code that is not written in REBOL but writes %user.r to do its propagation.
Ladislav
10-Apr-2011
[7887]
you can have a worm spread using a combination of REBOL and code 
that is not written in REBOL but writes %user.r to do its propagation

- yes, you can, but when you run a worm like that, then you are insecure 
anyway, since the worm could overwrite even your rebol.exe file.
Andreas
10-Apr-2011
[7888]
Sure, and such a worm could spread much more easily by writing my 
.bashrc to do the propagation.
BrianH
10-Apr-2011
[7889x2]
And I don't really trust .bashrc for that reason, though there might 
be some OS protection for that file of which I'm not aware.
Ladislav, you can put the rebol.exe file in a place that only admins 
can write to; %rebol.r too. You can't do the same with %user.r.
Andreas
10-Apr-2011
[7891]
Depends on where you put %user.r and your OS capabilities, I guess.
BrianH
10-Apr-2011
[7892]
Until %user.r is validated, you can't trust it. We can compare against 
checksums for other scripts, but there's no safe place to store a 
checksum for %user.r where it can be updated by the user script, 
because we don't have a "trusted code" concept in R3.
Andreas
10-Apr-2011
[7893x3]
Just store %user.r read-only and owned by an admin group and be done 
with it.
(And still assuming you have eliminated all other similar security 
leaks from your regular OS usage.)
But thanks for the reformulated explanation. I now understand your 
concerns.
BrianH
10-Apr-2011
[7896x2]
Andreas, by %user.r, I mean a file that would be loaded from the 
user's home directory or some subdirectory of it (.rebol, %appdata%\REBOL, 
whatever), and which could be manually writeable by the user when 
REBOL isn't running (or else its syntax wouldn't need to be human-readable 
and writeable). If you decide to skip any of those constraints, you 
can secure it despite the limited security models of most the OSes 
we support.
Those are the standard constraints of a preferences file, but there 
are some programs that make exceptions.
Andreas
10-Apr-2011
[7898]
Agreed on all points. But if you don't make the file writable without 
having to elevate your permissions first, does that not solve your 
immediate security concern?
BrianH
10-Apr-2011
[7899x2]
Not all platforms supported by R3 have permissions elevation. We 
support Windows all the way back to 2000, and permissions elevation 
wasn't introduced until Vista. Plus, that wouldn't work for multiuser 
systems where the user doesn't have the admin password (possible 
because they're the target market of these restrictions).
Must run now, I'm late already :(
Andreas
10-Apr-2011
[7901x3]
So that's a "yes, that would solve the security issue", I gather.
With a "but (some) OSes can't do this" constraint.
See you later.
BrianH
10-Apr-2011
[7904]
With a "some OSes won't allow users to edit or save their own preferences, 
so preferences are half broken on those OSes" constraint, that would 
solve the issue.
Ladislav
10-Apr-2011
[7905x2]
I am still having issues with what is considered "secure" here. As 
far as REBOL goes, for me, it is not unsecure, if it relies on the 
user environment being secure. (How can any program be secure, if 
it runs in an insecure environment?) Thus, the only concern I do 
have as far as REBOL goes is my wish for the REBOL interpreter to 
not overwrite the %user.r file unless specifically allowed to do 
that.
Any additional security is just an illusion for me.
Gregg
10-Apr-2011
[7907]
I agree.
Nicolas
10-Apr-2011
[7908]
It seems that rebol3 is having some real problems. What's this I 
hear about Carl getting a job?
Kaj
10-Apr-2011
[7909]
He did
Nicolas
10-Apr-2011
[7910]
Is he still the benevolent overlord of r3?
Kaj
10-Apr-2011
[7911]
He's the absent overlord
Nicolas
10-Apr-2011
[7912]
What's happened to development?
Kaj
10-Apr-2011
[7913]
Well, he can only spend his time once
Nicolas
10-Apr-2011
[7914]
Has it stopped?
Kaj
10-Apr-2011
[7915]
Pretty much
Nicolas
10-Apr-2011
[7916]
When did this start?
Kaj
10-Apr-2011
[7917]
Almost half a year ago, at least visibly, in hindsight
Nicolas
10-Apr-2011
[7918]
Other people have the source code don't they?
Kaj
10-Apr-2011
[7919]
No, why would they?
Nicolas
10-Apr-2011
[7920]
Otherwise the community will just rot.
Kaj
10-Apr-2011
[7921]
Better pinch your nose
Nicolas
10-Apr-2011
[7922x2]
I feel let down. If Carl takes a break he has to entrust the source 
code and development to someone else.
Is there much action on boron?
Kaj
10-Apr-2011
[7924x2]
That makes more of us. The overriding argument for REBOL and its 
closedness was always that Carl was the leader, he always knew best, 
and development always continued
Boron is going steady, but it's an isolated project, much in the 
same style as REBOL. The community is more interested in Red
Nicolas
10-Apr-2011
[7926]
I heard about it. What's red for?
Kaj
10-Apr-2011
[7927]
Programming :-)