I've been pondering security issues lately, motivated by an interest
in having a web- (or other net-) server which contains a library of
scripts or functions which could be run at will (or automatically
synchronized frequently) on a net-connected box. It's really tedious
keeping N+1 boxes synchronized by hand!
However, that increases the number of potential attacks on the
client box. Hence the paranoid mutterings below.
-jn-
[EMAIL PROTECTED] wrote:
>
> > This is dangerous if you're running scripts that other people gave
> you.
>
> Good point. One idea would be to use a different extension for "safe
> scripts", like .RS
>
> One extension is as good as another to REBOL.
>
Hmmm... That just displaces (and enlarges) the security problem.
To make the point, let me oversimplify and ignore the differences
between file and net security (and levels, etc.) and focus on WHEN
the security decision is made, in broad brush terms.
In practical terms we currently have these kinds of options:
1) Naive mode:
Always run unsecured (via -s or {secure none} in user.r)
2) Cautious mode:
Insecure intervals at a loose timescale (disable security,
do a bunch of stuff, then turn security back on)
3) Nervous mode:
Lower security just enough to run a trusted script, then
immediately crank it back up.
4) Raving paranoid mode:
Always leave security at the highest setting, leave the modem
off, unplug the network cable, and don't even boot the box.
With the .RS option, I could mount an attack on your system using
new techniques to bypass your choice of 1-4 above:
a) Social engineering, part 1:
Try to get you to run a script (send it via email, ask you to
'do my web-page, etc.) and hope you don't notice the name
%email-threat-to-white-house-and-erase-hard-drive.rs
b) Social engineering, part 2:
Send you a useful (SAFE!) script with an *.rs name. You can
look it over carefully and test it (change its name to *.r
and explicitly monitor all dangerous actions, etc.) until you
trust it enough to leave it enabled with *.rs all the time.
Then I send you an "upgrade", with an *.rs name, that has a
Trojan horse (possibly implemented via self-modifying code
after a certain number of executions or elapsed time) and
hope that the new version inherits the trust you placed in
the older copy.
c) Catch-you-not-looking attack:
Get at your box long enough to change a script's name from
%foo.r to %foo.rs (there's a bit more, but you get the idea).
Just thinking in paranoid mode here... ;-) I'm wondering if we
could come up with new security techniques that would be viable
alternatives to the sandbox or the signature methods.
Old joke: "I'm from the government. I'm here to help you."
New joke: "I'm from microsoft. I'm safe to execute on your box."
