Discussion:
[Bug-apl] Safe mode is not so safe
Elias Mårtenson
2017-03-29 04:21:29 UTC
Permalink
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
Christian Robert
2017-03-29 04:39:40 UTC
Permalink
Well,

[***@xtian:/home/xtian] $ apl --help 2>&1 | fgrep safe
--safe safe mode (no shared vars, no native functions)

what is the meaning of "no native functions" ?

to me the Doc should be updated, or some work done to make it true.

juergen will choose.

Xtian.
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.
* 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
Kacper Gutowski
2017-03-29 11:18:28 UTC
Permalink
Post by Christian Robert
what is the meaning of "no native functions" ?
A Native Function is a function that can be called in APL like a normal
user defined APL function, but is implemented in C++.
A native function is created with A ⎕FX B. A is a string that is the
path of a shared library and B is the name of the function in APL.
Dyadic ⎕FX with character string on the left gives a DOMAIN ERROR
when --safe is in force.

-k
e***@gmx.com
2017-03-29 14:34:46 UTC
Permalink
Are you doing this on your own irc server or in a 'freenode' type public channel?

Why not start by setting this up in a chroot 'jail' and in a vm :)




On Wed, 29 Mar 2017 12:21:29 +0800
Post by Elias MÃ¥rtenson
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.
- 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
Elias Mårtenson
2017-03-29 15:04:56 UTC
Permalink
On 29 Mar 2017 22:35, <***@gmx.com> wrote:


Are you doing this on your own irc server or in a 'freenode' type public
channel?

Why not start by setting this up in a chroot 'jail' and in a vm :)


I am, actually. But that is no reason to give unfettered access to even a
constrained system.

Regards,
Elias
e***@gmx.com
2017-03-29 15:21:07 UTC
Permalink
i did an irc bot in fpc and you get all the users inputs as strings to parse so i just made a matrix of things that i wanted to allow being done as user input (basically new things i implemented were added as i programmed) - so a block all then allow parse

you shouldn't be directly executing user input directly anyway for anything :)





On Wed, 29 Mar 2017 23:04:56 +0800
Post by e***@gmx.com
Are you doing this on your own irc server or in a 'freenode' type public channel?
Why not start by setting this up in a chroot 'jail' and in a vm :)
I am, actually. But that is no reason to give unfettered access to even a
constrained system.
Regards,
Elias
Juergen Sauermann
2017-03-29 15:40:34 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Elias,<br>
<br>
I understand and to some extent support the desire to make the
safe mode more </font>safe. However, we should not go too far
with it because<br>
that has the risk of making --safe so restrictive that useful
operations are no linger possible.<br>
<br>
For example disabling SQL operations completely would make it
impossible to display data from an SQL file in a web page.<br>
I would rather argue that in this example, setting the file
permissions of the SQL files would be more appropriate than
disabling SQL<br>
entirely. I also tend to believe that it is simply impossible to
implement the security of a machine as a single command-line option<br>
of one program.<br>
<br>
And e.g. preventing <b>)COPY</b> would render many existing
workspaces useless. For example, my own HTML pages do <b>)COPY HTML</b><br>
before anything else. Preventing <b>⎕FIO</b> would also disable
socket() operations which are quite useful if you want to do a web
server<br>
directly in apl.<br>
<br>
So lets discuss what a reasonable list would look like, and then
(based on the length of the list) how to implement the restrictions<br>
(via ./configure, or in preferences files, or as command line
option(s)).<br>
<br>
Best Regads,<br>
/// Jürgen<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/29/2017 06:21 AM, Elias Mårtenson
wrote:<br>
</div>
<blockquote
cite="mid:CADtN0WJDnr3S=8pivs311+dA5t76U+0W-***@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>This is the purpose of the --safe flag, but I have noted
that several destructive operations are still permitted when
using this flag.</div>
<div><br>
</div>
<div>In particular:</div>
<div><br>
</div>
<div>
<ul>
<li>SQL operations</li>
<li>FILE_IO</li>
<li>)OUT<br>
</li>
<li>)DUMP, )DUMPV, )DUMP-HTML</li>
<li>)COPY, )LOAD, etc…</li>
<li>)HOST</li>
</ul>
<div>There is probably more, but preventing these would be a
good start.</div>
</div>
<div><br>
</div>
<div>Regards,</div>
<div>Elias</div>
</div>
</blockquote>
<br>
</body>
</html>
Elias Mårtenson
2017-03-29 15:52:09 UTC
Permalink
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
Post by Juergen Sauermann
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
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.
- 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
Blake McBride
2017-03-29 23:36:16 UTC
Permalink
Just a thought... What if --safe took an argument, like "--save 1",
"--safe 2", etc.
Post by Elias MÃ¥rtenson
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
Post by Juergen Sauermann
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
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.
- 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
Juergen Sauermann
2017-03-30 11:19:17 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Blake,<br>
<br>
we currently have a <font face="Courier New, Courier, monospace"><b>-p</b></font>
option with a numerical argument <b>N</b>. That <b>N</b> is used
to select<br>
one of several sections in the GNU APL preference file(s).<br>
<br>
I am expecting that the actual configuration of <b>--safe</b>
features might become quite complex in the<br>
long run, so we need an easy to use and central place for
configuring what shall be allowed and<br>
what not in a modular way. Something like this:<br>
<br>
<font face="Courier New, Courier, monospace"><b>apl -p 5</b></font><br>
<br>
and in preferences file(s):<br>
<font face="Courier New, Courier, monospace"><br>
<b>[5]</b><b><br>
</b><b>   d</b><b>isable_SQL</b><b><br>
</b><b>   disable_⎕FIO</b><br>
...</font><br>
<br>
Sometimes security options and non-security options go hand in
hand, and the profile mechanism of<br>
GNU APL can accommodate both cases in a simple way.<br>
<br>
Best Regards,<br>
Jürgen Sauermann<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 03/30/2017 01:36 AM, Blake McBride
wrote:<br>
</div>
<blockquote
cite="mid:CABwHSOs0WSWF1S42-***@mail.gmail.com"
type="cite">
<div dir="ltr">Just a thought...  What if --safe took an argument,
like "--save 1", "--safe 2", etc.
<div class="gmail_extra">
<div>
<div class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr"><span
style="font-family:Helvetica;font-size:medium">
<div><br>
</div>
</span><span
style="border-collapse:separate;color:rgb(0,0,0);font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span
style="border-collapse:separate;color:rgb(0,0,0);font-variant:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span
style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">
<div><span></span><br>
</div>
</span></span></span></div>
</div>
</div>
<br>
<div class="gmail_quote">On Wed, Mar 29, 2017 at 10:52 AM,
Elias Mårtenson <span dir="ltr">&lt;<a
moz-do-not-send="true" href="mailto:***@gmail.com"
target="_blank">***@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">Very good points, thank you. You
articulated my own concerns as I tried to quantify the
requirements, and what the risks are. 
<div dir="auto"><br>
</div>
<div dir="auto">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. </div>
<div dir="auto"><br>
</div>
<div dir="auto">There are of course other use cases, and
as you pointed out a single option may not be enough
(or be too much). </div>
<div dir="auto"><br>
</div>
<div dir="auto">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). </div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards, </div>
<span class="HOEnZb"><font color="#888888">
<div dir="auto">Elias </div>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 29 Mar 2017 23:40,
"Juergen Sauermann" &lt;<a moz-do-not-send="true"
href="mailto:***@t-online.de"
target="_blank">***@t-online.de</a><wbr>&gt;
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <font
face="Helvetica, Arial, sans-serif">Hi
Elias,<br>
<br>
I understand and to some extent support the
desire to make the safe mode more </font>safe.
However, we should not go too far with it
because<br>
that has the risk of making --safe so
restrictive that useful operations are no
linger possible.<br>
<br>
For example disabling SQL operations
completely would make it impossible to display
data from an SQL file in a web page.<br>
I would rather argue that in this example,
setting the file permissions of the SQL files
would be more appropriate than disabling SQL<br>
entirely. I also tend to believe that it is
simply impossible to implement the security of
a machine as a single command-line option<br>
of one program.<br>
<br>
And e.g. preventing <b>)COPY</b> would render
many existing workspaces useless. For example,
my own HTML pages do <b>)COPY HTML</b><br>
before anything else. Preventing <b>⎕FIO</b>
would also disable socket() operations which
are quite useful if you want to do a web
server<br>
directly in apl.<br>
<br>
So lets discuss what a reasonable list would
look like, and then (based on the length of
the list) how to implement the restrictions<br>
(via ./configure, or in preferences files, or
as command line option(s)).<br>
<br>
Best Regads,<br>
/// Jürgen<br>
<br>
<br>
<div
class="m_1072432389707822552m_-7925622178338296248moz-cite-prefix">On
03/29/2017 06:21 AM, Elias Mårtenson wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>This is the purpose of the --safe
flag, but I have noted that several
destructive operations are still
permitted when using this flag.</div>
<div><br>
</div>
<div>In particular:</div>
<div><br>
</div>
<div>
<ul>
<li>SQL operations</li>
<li>FILE_IO</li>
<li>)OUT<br>
</li>
<li>)DUMP, )DUMPV, )DUMP-HTML</li>
<li>)COPY, )LOAD, etc…</li>
<li>)HOST</li>
</ul>
<div>There is probably more, but
preventing these would be a good
start.</div>
</div>
<div><br>
</div>
<div>Regards,</div>
<div>Elias</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>
Blake McBride
2017-03-30 20:31:34 UTC
Permalink
I like it. Thanks!


Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone

-------- Original message --------
From: Juergen Sauermann <***@t-online.de>
Date: 3/30/17 6:19 AM (GMT-06:00)
To: Blake McBride <***@gmail.com>, Elias MÃ¥rtenson <***@gmail.com>
Cc: bug-***@gnu.org
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 <***@gmail.com> 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" <***@t-online.de>
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

Loading...