$Id: SECURITY,v 1.3 2003/05/23 02:18:03 hbo Exp $

Security Considerations in Implementing Sudoscript

How secure is sudoscript? The answer could be "not very," or "as
secure as sudo."  By itself, sudoscript does not confer any privilege
or validate any credentials. It relies on sudo completely for those
functions. Sudo itself can be configured to be fairly secure, or not
secure at all. Unfortunately, configuring it for use with sudoscript
tends to lean toward the latter condition.

Giving People Root Access

In its default mode, sudoscript enables (using sudo(8) and script(1))
an audited root shell. This is an inherently insecure thing to do
because root owns all permissions in most Unix-like systems and can
evade any audit trail the systems administrator tries to impose. There
are very simple, and possibly innocent ways to do this. For example,
on a system with X11, a simple xterm (or other X11 terminal program)
will open a new, unaudited shell in a new window.  Any other GUI
application will be similarly unaudited. There are many, many other
ways in which a root enabled user could evade sudoscript's audit
trail. So the upshot of all this is, don't use sudoscript to give
people root shells unless you trust them. Another possibility is that
you may be forced into giving someone such a shell. In that case,
sudoscript will give you an audit trail until the user decides to do
something to evade it.

Giving People non-Root Shells

A new feature of sudoscript as of version 2.1.0 is the ability to run
audited shells as users other than root. This narrows the scope of
what a malicious user might do to evade the audit trail sudoscript
provides. Unfortunately, there are still at least two ways (and
probably more) that a user can do this. First, an xterm will still
open an unaudited window. Second, with the current sudoscript
architecture, a user must be able to write to the named pipe connected
to the logging daemon. ANY terminal output in the audited shell will
be written to the pipe. So a clever user could do something bad, then
simply cat(1) a file containing a very large, but innocent terminal
session to his or her screen. After a certain point, the sudoscript
log files will turn over enough times to flush the evidence of the bad
action off the system. There are defensive steps sudoscriptd could
take to minimize some of the obvious attacks. The daemon could watch
for large quantites of similar data, as would result from a 
'dd if=/dev/zero ..'  or random data such as from 'openssl rand LARGENUMBER'.  
And having a very large logging partition would help deter such
attacks.  Also, looking at the timestamps might show suspiciously
rapid command invocation in the case of a phony login session. But the
weakness is open ended, since an attacker can choose practically any
data to throw at the logging daemon. Frankly, I can't think of any way
an application like sudoscript running on a more-or-less standard
version of Unix could get around this completely. Because of this,
I haven't taken the trouble implement any of the defensive steps
outlined above.

Conclusion

Sudoscript was written in an environment where users already had
root. (For details see http://egbok.com/sudoscript/PORCMOLSULB.html)
In that environment, I was not concerned that my users would
deliberately break system security. I was more concerned that they
might inadvertently screw-up their systems. Sudoscript allowed me to
have a recent audit trail of user activity to consult when something
went wrong. It has saved my and my users' bacon many times. Used
in that way, sudoscript is a useful tool. Used to try to enforce accountability
on a hostile user population, it has dubious value in my opinion.