Re: hiding global variables



yahalom wrote:
I still wish there was some way of disabling info commands and info
args.

In 8.5 you can. The [info] command is an ensemble and those subcommands
are implemented as calls to other commands (whose names I forget right
now). You can simply delete the commands that they map to, and the
capability will be gone. But...

Without them tcl compiled code was much securer.

That's so deluded it's rather funny. You've forgotten to list many other
info subcommands that would probably be useful to the attacker too. For
example [info procs], [info body], [info default]. You'll also have to
disable [load], as it's really easy to take the code to implement, e.g.,
[info args] and put that in an extension.

Added to which I've heard of code that makes use of many of the [info]
subcommands for non-hacking purposes too, which you seem to be proposing
to break...

I could even
change procedure names using sed before compilation and then even
developers where finding it hard to hack the program.

You could write it in classical Basque too, but it wouldn't actually
make much difference other than annoying your developers. The command
names aren't really that important to anyone who is taking the trouble
to pry. (Really!)

Another approach
could be requiring a password in a package like:
package require cryptic -password secretPass
so you cannot load the package without the password.

What you *could* do is require a special global variable (containing the
password) to be set before the package is loaded, with the package
deleting the variable during load. Or you could only distribute the
package on an encrypted virtual filesystem, requiring the password to
mount. But it's really *much* more secure to put the encrypted code in
another interpreter so that user scripts can only execute *exactly*
those special commands of yours that you want them to and which you've
presumably documented for them. Note that the separate interpreter
mechanism is designed to be a real security system, and in particular is
designed to handle the case where the called code (e.g. the users') is
actively antagonistic to the caller (yours). At that point, you're much
safer because you never run code that would want to probe your secrets
in a context where you expose them.

Donal.
.



Relevant Pages

  • Re: LaTeX and Friends: Less Preliminary Version
    ... Chapter 1: Introduction to LaTeX ... The tabular Environment ... The booktabs Package ... Basic Typesetting Commands ...
    (comp.text.tex)
  • Book Announcement
    ... o Gary Smith for the research on installing TeX Live and LaTeX ... The booktabs Package ... The tabbing Environment ... Basic Typesetting Commands ...
    (comp.text.tex)
  • Re: Finding installed package files
    ... >, and who is going to supply this documentation. ... > is a package with the common man pages for the thousand odd common commands ... tell me, as an installation option for some large packages, what was ... >>a set of commands and 'man' pages, could produce such a directory to make it ...
    (alt.os.linux.redhat)
  • Re: Finding installed package files
    ... is a package with the common man pages for the thousand odd common commands ... Seeing as how 18 percent of the package is documentation - have you looked ... >a set of commands and 'man' pages, could produce such a directory to make it ... There are 16 books in front of me between the monitors, ...
    (alt.os.linux.redhat)
  • Re: New list commands ... What do you think ?
    ... That's the risk of every developer writing basic commands. ... allow some discussion about some of them, that are really good for core ... runtime consuming and could be done more efficiencly in C using the tcl ... Critcl builds a package which is loaded. ...
    (comp.lang.tcl)