Taint support

[msteveb]

See README.taint for details

[dbohdan]

I have only played with this feature in the REPL so far, but I can see it being useful. Some feedback:

• It might help if tainted data errors had a specific errorcode, so you could distinguish them not just by message.
• info tainted without an argument returns 1. Unless I am missing something, it should be an error.

[msteveb]

Thanks. All feedback is useful. I am hesitant about adding new error codes, but I'll consider yet. Yes, info tainted with no arg should be an error.

[dbohdan]

Thanks.

You're welcome!

I am hesitant about adding new error codes, but I'll consider yet.

Why? I understand that there is no central accounting for -errorcodes, so the effect of adding new ones will be between a command and its users. I can't see any negative impact from it.

Yes, info tainted with no arg should be an error.

Ah, good.

[dbohdan]

I have a feature request: check for tainted data in the Redis extension, too, and in Win32_ShellExecute in jim-win32.c.

[msteveb]

Yes, for sure with Win32_ShellExecute. Not so sure about the redis extension, as there is no quoting in args passed to redis, it is hard to get an injection attack. We could check for taint in the command (first arg) to redis, as that certainly shouldn't come from outside the system, but this seems like a low risk.

Regarding -errorcode, my apology - I confused this with return codes. Error codes aren't particularly well supported in Jim Tcl at the moment. Basically exec will set $errorCode which will be picked up by try/catch to set -errorcode, but nothing else sets $errorCode. I'm open to concrete suggestions.

[dbohdan]

Yes, for sure with Win32_ShellExecute.

Great! \o/

Not so sure about the redis extension, as there is no quoting in args passed to redis, it is hard to get an injection attack. We could check for taint in the command (first arg) to redis, as that certainly shouldn't come from outside the system, but this seems like a low risk.

There is also the command EVAL, which evaluates its argument as Lua code, and I can think of several others where one would pretty much only pass something from the user to them by mistake. I think it is not worth playing Whac-A-Mole trying to blacklist sensitive arguments to all of them. (Blacklists are a weak approach to security: new dangerous commands may be added later, in forks, or in other software that speaks the Redis protocol.) "Check nothing", "only check the command argument", and "check all arguments" are probably the only viable options.

Regarding -errorcode, my apology - I confused this with return codes. Error codes aren't particularly well supported in Jim Tcl at the moment. Basically exec will set $errorCode which will be picked up by try/catch to set -errorcode, but nothing else sets $errorCode. I'm open to concrete suggestions.

Ah, I see. I'd set ~~the -errorcode~~ $errorCode to TAINTED or TAINTEDDATA in Jim_SetTaintError.

[msteveb]

Thanks. Will merge once I've updated the documentation.

[msteveb]

Thanks. Now that 0.82 is released I plan to get this into the next release

[msteveb]

FYI, I plan to merge this as part of https://github.com/msteveb/jimtcl/tree/cmd-register in the coming weeks