Taint support

[msteveb]

See README.taint for details

[gromgit]

Was this really planned 10 years ago?

[msteveb]

Yes, really. Been out of tree for that long. I thought it was time to share.
Thanks for your edits below. I'll integrate them.

[gromgit]

Suggested change

	to a web application) should not inadvertently be output
	to a web application). This data should not inadvertently be output

[gromgit]

Suggested change

	Standard Tcl does not support tainting. Instead it uses "safe"
	Standard Tcl does not support tainting, but uses "safe"

[gromgit]

Suggested change

	While the tainted value can be distinguished from other values
	in the container, the container is not tainted. However if the container
	needs to change representation (the entire container becomes tainted.
	If the tainted value can be distinguished from other values
	in the container, the container is not tainted. However, if the container
	needs to change representation, the entire container becomes tainted.

[gromgit]

Suggested change

	Each taint type is associate with a bit field. The standard taint
	Each taint type is assigned a bit in a taint bit field. The standard taint

[gromgit]

Suggested change

	In order to simplify taint propagation, the interpreter
	To simplify taint propagation, the interpreter

[gromgit]

Suggested change

	- The taint and untaint commands operate on variables and taint/untaint the contents of the variable
	- The taint and untaint commands operate on variables, and taint/untaint the contents of the variable

[gromgit]

Suggested change

	- Adding/modifying a list/dict/array element taints that element plus the "container" but not
	- Adding/modifying a list/dict/array element taints that element plus the "container", but not

[gromgit]

Suggested change

	a command creates a new object while any of it's arguments are tainted,
	a command creates a new object while any of its arguments are tainted,

[gromgit]

Suggested change

	However the list-related commands are more intelligent.
	However, the list-related commands are more intelligent.

[gromgit]

Suggested change

	maintain the taint of existing list elements, but will avoid tainting untainted elements.
	not change the taint of existing list elements.

[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.

[dbohdan]

Looks good to me!

Welcome to Jim version 0.80
. source jimlib.tcl
. set a 5
5
. taint a
. lib::try { exec echo $a } trap TAINTED {x y} { list $x $y }
{exec: tainted data} {-code 1 -level 0 -errorinfo {} -errorcode TAINTED}

[msteveb]

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

[dirkf]

Suggested change

	Taint Suport for Jim Tcl
	Taint Support for Jim Tcl

[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