Open wschlich opened 6 months ago
A currently usable workaround for this problem could be to log session data to a local file using sudosh2 and having rsyslog slurp in this file using imfile, maybe: https://www.rsyslog.com/doc/configuration/modules/imfile.html
Syslog messages specifically aren't a great fit for several reasons (including that the files aren't ascii text and would need to be bas64 encoded or similar). I'm always open to PRs but we've been in maintenance mode, since 2010 primarily fixing bugs and compatibility issues and I exited the enterprise sysadmin scene not long after.
A ground-up rewrite would be a prerequisite for me to add significant features.
The following statement is written in the project
README.md
:This doesn't seem to make too much sense to me.
If an attacker can gain root privileges, he can probably just wipe these log files easily.
If sudosh2 could log to syslog which in turn could log remotely to an syslog server, these logs could not be wiped by an attacker.