Recently the TRON-DELTA.ORG commenced a security review on TrueOS (github.com/trueos), which included a manual code and configuration review/audit (no static or dynamic code analysis) and a review of documentation as needed. It focused on backdoors and obviously problematic or questionable items, within the TrueOS PC-UPDATEMANAGER sub-project.
Please note, that our organization has not found any backdoor whatsoever within the TrueOS PC-UPDATEMANAGER sub-project.
However, to conclude the security review we have a remark/issue, directed to the TrueOS developers or TrueOS helpers, as listed below. We are aware of the complexity of this remark, which probably will take some time to address. However, we would greatly appreciate a short reply on it, as soon as time permits, to conclude our security review. Thank you!
A review of the Lumina project as well as the SysAdm project will take place in due course. In addition to that extensive image/ISO testing took place in Q1 2018. Depending on our resources the TRON-DELTA.ORG will also commence a FreeBSD and FreeBSD-ports project review, including code analysis.
The errors found are:
No packages matched for pattern, wrong pkg installed, No schema found, tar: Error exit delayed from previous errors), plus some minor errors.
Due to the difficulties in debugging the scripts we strongly suggest to add debug options to the script doPkgUp.sh (potentially all important TrueOS shell scripts, like rc-doupdate, etc.), especially for function run_cmd_wtee(). That should be done to improve the situation with debugging Errors like “Failed Updating!” and “Rolling back…” in the future, since we were unable to ultimately determine the reason for that error – probably one of the above, thus failing one function in the script. However, nothing helpful was written out to the logfiles and run_cmd_wtee() just failed without telling why it failed.
Based on these findings we suggest:
a partial rewrite of these upgrade scripts with sane debug pipes (plus e.g. an option to add -d or –debug as a parameter), adding debug functions/pipes and sane logging to logfiles
to use constructs like trap (if available in sh/bash) within the scripts for better error handling
to write out function parameters and return values to logfiles (only when –debug was given as a parameter, for security reasons)
that scripts should be split up into pre-install, install and post-install scripts to reduce complexity, even when that means to implement certain functions more than once
that function run_cmd_wtee() should be replaced (everywhere) with better logic and not only, quote: “Try to get error status of first command in pipeline”, which was not helpful post error/after the fact
that script functions should provide more helpful information on what exactly has failed (in general).