I like it. Thanks!
Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone
-------- Original message --------
From: Juergen Sauermann <[email protected]>
Date: 3/30/17 6:19 AM (GMT-06:00)
To: Blake McBride <[email protected]>, Elias Mårtenson <[email protected]>
Cc: [email protected]
Subject: Re: [Bug-apl] Safe mode is not so safe
Hi Blake,
we currently have a -p
option with a numerical argument N. That N is used
to select
one of several sections in the GNU APL preference file(s).
I am expecting that the actual configuration of --safe
features might become quite complex in the
long run, so we need an easy to use and central place for
configuring what shall be allowed and
what not in a modular way. Something like this:
apl -p 5
and in preferences file(s):
[5]
disable_SQL
disable_⎕FIO
...
Sometimes security options and non-security options go hand in
hand, and the profile mechanism of
GNU APL can accommodate both cases in a simple way.
Best Regards,
Jürgen Sauermann
On 03/30/2017 01:36 AM, Blake McBride
wrote:
Just a thought... What if --safe took an argument,
like "--save 1", "--safe 2", etc.
On Wed, Mar 29, 2017 at 10:52 AM,
Elias Mårtenson <[email protected]> wrote:
Very good points, thank you. You
articulated my own concerns as I tried to quantify the
requirements, and what the risks are.
The central need here is the ability to
compute formulas that are not entirely under your own
control. In my case, I want to provide the ability to
evaluate APL expressions on the #jsoftware IRC
channel. They already have a bot that does J, so APL
is clearly needed.
There are of course other use cases, and
as you pointed out a single option may not be enough
(or be too much).
I'm starting to think about a more
granular mechanism. Some way of evaluating just a
single expression using very strict protections, but
letting the rest be unconstrained. Controlled using a
quad variable perhaps? (the variable could contain a
list of the operations that should be allowed or
denied when evaluating a given string).
Regards,
Elias
On 29 Mar 2017 23:40,
"Juergen Sauermann" <[email protected]>
wrote:
Hi
Elias,
I understand and to some extent support the
desire to make the safe mode more safe.
However, we should not go too far with it
because
that has the risk of making --safe so
restrictive that useful operations are no
linger possible.
For example disabling SQL operations
completely would make it impossible to display
data from an SQL file in a web page.
I would rather argue that in this example,
setting the file permissions of the SQL files
would be more appropriate than disabling SQL
entirely. I also tend to believe that it is
simply impossible to implement the security of
a machine as a single command-line option
of one program.
And e.g. preventing )COPY would render
many existing workspaces useless. For example,
my own HTML pages do )COPY HTML
before anything else. Preventing ⎕FIO
would also disable socket() operations which
are quite useful if you want to do a web
server
directly in apl.
So lets discuss what a reasonable list would
look like, and then (based on the length of
the list) how to implement the restrictions
(via ./configure, or in preferences files, or
as command line option(s)).
Best Regads,
/// Jürgen
On
03/29/2017 06:21 AM, Elias Mårtenson wrote:
I'm implementing an IRC bot
that can run arbitrary APL expressions.
Since this bot can run code submitted by
anyone, I need to ensure that the code
can't affect the system where the APL
expressions are executed.
This is the purpose of the --safe
flag, but I have noted that several
destructive operations are still
permitted when using this flag.
In particular:
SQL operations
FILE_IO
)OUT
)DUMP, )DUMPV, )DUMP-HTML
)COPY, )LOAD, etc…
)HOST
There is probably more, but
preventing these would be a good
start.
Regards,
Elias
