Re: [NSE] Script Dependencies Replacement for Runlevels

[Patrick Donnelly <batrick () batbytes com>]

Hi David,

On Mon, Nov 9, 2009 at 6:06 PM, David Fifield <david () bamsoftware com> wrote:
> > I have created a patch to NSE that replaces runlevels with a table of
> > dependencies that clearly outlines what other scripts the script
> > depends on. The table is of the form:
> >
> > dependences = {"script1", script2", ...}
>
> What do you think about using "depends" instead of "dependencies"?
> "dependencies" is hard to type.

I'm not particularly attached to the word, but I was trying to follow
the "established" convention of nouns for field names in the script
(action, description, author, etc.). Doesn't really matter to me.

> "dependencies" doesn't correspond to anything in the current system,
> right? There's no way currently for one script to require the execution
> of another? weak_dependencies is what we emulate using runlevels.

Right.

> I think people will have trouble with the distinction between "strong"
> and "weak" dependencies. How about using a name like "run_after" for
> weak dependencies?

I personally would prefer keeping dependencies over "run_after". I
think the weak/strong distinction will be transparent to users and
will only surface when a dependency is missing, in which case I think
it is clear the user should add the offending dependency or remove the
dependent script from their script group.

> > Runlevels become an internal representation of the order of scripts
> > that are generated by the dependencies. If a dependency is not present
> > in the current group of scripts then an error will be raised noting
> > the missing dependency. Alternatively, you can use the new command
> > line option --script-autoadd to automatically add dependencies to the
> > current group of scripts (this can potentially add dangerous scripts
> > and therefore is not the default).
>
> It took second to figure out what --script-autoadd is doing. At first I
> thought it was going to modify the script files themselves and add a
> line with dependencies inferred from their runlevel ("automatically add
> dependencies to the current group of scripts"), but that's not it at
> all. Really, it's this: If a strong dependency is not satisfied by the
> scripts you list, you get an error. So, for example I made html-title
> depend on http-auth:
>
> ./nmap --datadir . --script=html-title scanme.nmap.org -p 80
> NSE: failed to initialize the script engine:
> ./nse_main.lua:516: missing dependency in chain `html-title->http-auth`
> (use --script-autoadd to automatically add missing dependencies)
>
> Using --script-autoadd will automatically fill in any dependencies of
> scripts, so you won't get that error. It's like "apt-get install ..."
> installs all the packages that are recursive dependencies of the one you
> want.

Right, sorry that wasn't clear enough.

> ./nmap --datadir . --script=html-title --script-autoadd scanme.nmap.org -p 80 -d
> NSE: Script dependency './scripts/http-auth.nse' in chain `html-title->http-auth` added automatically.
> NSE: Loaded 2 scripts for scanning.
>
> My question is, do we need support for strong dependencies? I'm assuming
> I'm correct in thinking that strong dependencies are a new future, and
> that weak dependencies are equivalent to runlevels. If there is a use
> case for strong dependencies I'm not against them, but I would like to
> avoid having a --script-autoadd option.

Strong dependencies would be the new future. I don't really know how
many scripts would use strong dependencies (right now) if they were
available. I think maybe one or two would. Right now we have scripts
using the information generated from previous scripts in a loose
fashion. It may be better if these scripts could rely on that
information being there through a dependency system.

> I can think of one thing that runlevels offer that explicit dependencies
> don't. Say you have a brute force script, and you want it to run after
> every script that can potentially find a login for you. For example,
> telnet-brute might want to run after http-userdir-enum because the
> latter can identify usernames. We could do this with runlevels by giving
> a the login-finding scripts a low runlevel, but with explicit
> dependencies every brute force script will need to know about every
> login script. I suspect this is not easy to solve from a user interface
> point of view. One idea I had was something like
>
> weak_dependencies = {"*login"}
>
> "*login" would stand for a class of scripts that would somehow signify
> that they satisfy it. The runlevel assigned to the brute script would
> have to be at least one more than the highest runlevel of any *login
> script.

Ron and I considered adding something like the above. I believe the
consensus was that we would wait for a script that clearly needs it
rather than add it right now. We don't actually have a unified
approach with our scripts with respect to host state/information
saving. As an example, we don't save the usernames we find in some
agreed upon "official" location. Until we do, scripts won't be relying
on unknown scripts that produce this information (a generic *-login
wildcard).

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/