44 lines
1.5 KiB
Text
44 lines
1.5 KiB
Text
# Security Concerns
|
|
|
|
The standard Retro is not a good choice for applications
|
|
needing to be highly secure.
|
|
|
|
## Runtime Checks
|
|
|
|
The Retro system performs only minimal checks. It will not
|
|
load an image larger than the max set at build time. And
|
|
stack over/underflow are checked for as code executes.
|
|
|
|
The system does not attempt to validate anything else, it's
|
|
quite easy to crash.
|
|
|
|
## Isolation
|
|
|
|
The VM itself and the core code is self contained. Nga does
|
|
not make use of malloc/free, and uses only standard system
|
|
libraries. It's possible for buffer overruns within the image
|
|
(overwriting Nga code), but the Retro image shouldn't leak
|
|
into the C portions.
|
|
|
|
I/O presents a bigger issue. Anything involving I/O, especially
|
|
with the `unix:` words, may be a vector for attacks.
|
|
|
|
## Future Direction
|
|
|
|
I'm not planning to add anything to the *image* side as, for me,
|
|
the performance hit due to added checks is bigger than the
|
|
benefits.
|
|
|
|
The story is different on the VM side. I've already begun taking
|
|
steps to address some of the issues, using functions that check
|
|
for overruns with strings and doing some minor testing for these
|
|
conditions. I will be gradually addressing the various I/O
|
|
related extensions, though it's unlikely to ever be fully guarded
|
|
against attacks.
|
|
|
|
## Rationale
|
|
|
|
Retro is, primarily, a personal system. I'm running code I wrote
|
|
to solve problems I face. On the occasions where I run code sent
|
|
to me by others, I read it carefully first and then run inside a
|
|
sandboxed environment if I'm worried about anything in it.
|