summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOwen Jacobson <owen@grimoire.ca>2020-05-21 00:08:27 -0400
committerOwen Jacobson <owen@grimoire.ca>2020-05-21 00:08:27 -0400
commit79111d6679b2de4c90fd3abcca11514316ec37bf (patch)
tree3b3ff9baf276ed07f18e55e35f9238db51ec4ecf
parent3549a2b880088d540c2e52cd8aef669d74454534 (diff)
Weaken the language around security promises to be more in line with my ability to responsibly support this code.HEADmain
-rw-r--r--README.rst6
-rw-r--r--docs/security.rst22
2 files changed, 18 insertions, 10 deletions
diff --git a/README.rst b/README.rst
index a18cf5c..8cf82ab 100644
--- a/README.rst
+++ b/README.rst
@@ -42,9 +42,9 @@ So I wrote my own. This is that language.
This is a tiny lisp, along the lines of Peter Norvig's `lispy`_, designed to be
embedded within Python programs. It provides minimal safety features, but the
-restricted set of builtins ensures that Actinide programs cannot gain access to
-the outside context of the program. The worst they can do is waste CPU time,
-fill up RAM, and drain your battery.
+restricted set of builtins ensures that Actinide programs **probably** cannot
+gain access to the outside context of the program. The worst they can do is
+waste CPU time, fill up RAM, and drain your battery.
.. _lispy: http://norvig.com/lispy.html
diff --git a/docs/security.rst b/docs/security.rst
index 027b0de..a9b793c 100644
--- a/docs/security.rst
+++ b/docs/security.rst
@@ -5,11 +5,18 @@ Security
In the README, I made this strong claim:
It provides minimal safety features, but the restricted set of builtins
- ensures that Actinide programs cannot gain access to the outside context of
- the program. The worst they can do is waste CPU time, fill up RAM, and
- drain your battery.
+ ensures that Actinide programs probably cannot gain access to the outside
+ context of the program. The worst they can do is waste CPU time, fill up
+ RAM, and drain your battery.
-This document expands on the underlying design choices used to support that goal.
+This document expands on the underlying design choices used to support that
+goal.
+
+**I do not promise that Actinide is any more secure than other embeddable
+languages**. If you are relying on Actinide to sandbox programs, you do so at
+your own risk. If you find a way to escape the sandbox, I very much want to know
+about it, and I'll do my best to address it and to communicate this risk to
+other users.
**************
Specific Goals
@@ -69,9 +76,10 @@ The remaining built-in types are represented using classes:
* Instances of the ``actinide.ports.Port`` class, which wraps an arbitrary
``file`` object to restrict the operations available. The only built-in
- mechanism for creating a ``Port`` creates one which wraps a string; it is not
- possible to open port to a file, shared memory segment, pipe, process,
- socket, or to any other OS resource using only built-in functions and types.
+ mechanism for creating a ``Port`` creates one which wraps a string. There are
+ no built-in capabilities to open ports that represent files, shared memory
+ segments, pipes, processes, sockets, or any other OS resources using only
+ built-in functions and types.
* Instances of the ``actinide.types.Procedure`` class, which is considerably
more complex than the other types. This class handles the mechanics of