Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 9:26 PM, Leo Razoumov slonik...@gmail.com wrote: Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. The only actions TH1 can take are to output text or HTML into designated areas of a webpage. TH1 cannot change the repository, cannot write to the disk, cannot open network connections, cannot read content from external sources, cannot consume large amounts of memory, cannot loop, and cannot call external programs or software. TH1 is not a serious threat for malware. TCL can do more mischief, but it is only enabled if you compile with FOSSIL_ENABLE_TCL, which is off by default, and if you either set the tcl property on your repository or have the TH1_ENABLE_TCL environment variable set. Moving forward, I think I'll make further security enhancements along the following lines: (1) Disable the TH1_ENABLE_TCL environment variable. TCL script capability is only available if you enable it using the tcl property of the repository. (2) Default the tcl property to off on a clone, even if it is on in the parent repo. (3) Provide extra setup screens that make it easier to audit scripts for malware prior to enabling the tcl property. At the place where the tcl property is enabled, include text warning users of the potential dangers and provide buttons or links to places where the TCL script can be audited for security. (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 7:53 AM, Richard Hipp d...@sqlite.org wrote: On Mon, Feb 13, 2012 at 9:26 PM, Leo Razoumov slonik...@gmail.com wrote: Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. The only actions TH1 can take are to output text or HTML into designated areas of a webpage. TH1 cannot change the repository, cannot write to the disk, cannot open network connections, cannot read content from external sources, cannot consume large amounts of memory, cannot loop, and cannot call external programs or software. TH1 is not a serious threat for malware. TCL can do more mischief, but it is only enabled if you compile with FOSSIL_ENABLE_TCL, which is off by default, and if you either set the tcl property on your repository or have the TH1_ENABLE_TCL environment variable set. Moving forward, I think I'll make further security enhancements along the following lines: (1) Disable the TH1_ENABLE_TCL environment variable. TCL script capability is only available if you enable it using the tcl property of the repository. (2) Default the tcl property to off on a clone, even if it is on in the parent repo. (3) Provide extra setup screens that make it easier to audit scripts for malware prior to enabling the tcl property. At the place where the tcl property is enabled, include text warning users of the potential dangers and provide buttons or links to places where the TCL script can be audited for security. (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. (5) If any script changes as a result of fossil config pull then the tcl property is automatically moved to off and the operator is notified. The tcl property must be turned back on by a separate manual step, that includes a warning to make sure the modified scripts are secure. -- D. Richard Hipp d...@sqlite.org -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 07:53, Richard Hipp d...@sqlite.org wrote: (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. IMHO fossil clone should *NOT* transfer scripts. Cloning is such a common operation that I do it all the time on a whim without much thoughts. Can easily do things that I will regret later. On the other hand, somethings like fossil configuration pull scripts ... requires just enough extra typing to make it a conscious effort. Also, it would be great to have a -n or --nochange dry-run option to tell a user whether there are any scripts to pull or push. Just my 2c --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 01:01:39PM -0500, Leo Razoumov wrote: On Tue, Feb 14, 2012 at 07:53, Richard Hipp d...@sqlite.org wrote: (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. IMHO fossil clone should *NOT* transfer scripts. Cloning is such a common operation that I do it all the time on a whim without much thoughts. Can easily do things that I will regret later. In the case where we want versioned hook script. Mean, calling script that is inside the repository. A clone/pull will update it, but the setting that make it enable or not would be in the configuration part. And That's why one of the Richard point was that if a script get modified during a pull, the hook would be disable systematically and the user would have to audit the script and decide if he want to enable it back or not. On the other hand, somethings like fossil configuration pull scripts ... requires just enough extra typing to make it a conscious effort. Also, it would be great to have a -n or --nochange dry-run option to tell a user whether there are any scripts to pull or push. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
