mailing list archives
Re: Ncat's Lua socket abstraction - API protection, error behavior?
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 29 Aug 2013 12:25:16 -0500
On 08/29/2013 11:05 AM, Jacek Wielemborek wrote:
How nasty are we talking? Aborting the whole program is nasty, but
doesn't hurt if you're just developing a new filter and did something
wrong. As long as you get a decent error message that somewhat indicates
what went wrong, I think allowing filter authors to cause crashes while
developing filters is not a bad thing.
Since all filter scripts share the same namespace, there's a risk that
one filter layer can break another and lead to some nasty crash.
An API doesn't need to be bullet-proof, just idiot-resistant. If there
is a clear and easy way to do what is needed, it doesn't matter so much
if there's a difficult and non-obvious way to break it. Security issues
would be the exception; if you're designing an API that separates
privilege levels, then you have to be more strict. In the case of Ncat
filters, you would want to be sure that an author cannot accidentally
create a security bug. Intentional security problems are different: if
the filter runs every line through os.execute(), then prevention should
be a cricket bat, liberally applied.
while there could be some hacks done with
userdata, tables and such, they pointed out that there might be no
point trying to create a bullet-proof API.
This is essentially my view. Simple things like ensuring a value cannot
be changed by simple assignment is all that should be necessary. If
someone knows enough to mess around with metatables, then they can take
responsibility for their own actions.
Perhaps it would be better do define things that just shouldn't be
done (like overwriting the registry) and assume that user can't do
them by mistake, so there's no point securing them all?
But even in the worst case (perhaps one of your global vars can be
overwritten, borking the whole program) does it hurt anyone?It's part of
learning the development environment and API that you're setting up. I'm
sure I could "break" NSE by doing dumb things, but then I'm just stuck
with a script that breaks for me. Nobody else will accept it, because
it's broken.Unless I broke it in a clever and new way (hacked it) that
introduces useful functionality---this is the potential upside of a
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/