1$Id: SECURITY,v 1.3 2003/05/23 02:18:03 hbo Exp $ 2 3Security Considerations in Implementing Sudoscript 4 5How secure is sudoscript? The answer could be "not very," or "as 6secure as sudo." By itself, sudoscript does not confer any privilege 7or validate any credentials. It relies on sudo completely for those 8functions. Sudo itself can be configured to be fairly secure, or not 9secure at all. Unfortunately, configuring it for use with sudoscript 10tends to lean toward the latter condition. 11 12Giving People Root Access 13 14In its default mode, sudoscript enables (using sudo(8) and script(1)) 15an audited root shell. This is an inherently insecure thing to do 16because root owns all permissions in most Unix-like systems and can 17evade any audit trail the systems administrator tries to impose. There 18are very simple, and possibly innocent ways to do this. For example, 19on a system with X11, a simple xterm (or other X11 terminal program) 20will open a new, unaudited shell in a new window. Any other GUI 21application will be similarly unaudited. There are many, many other 22ways in which a root enabled user could evade sudoscript's audit 23trail. So the upshot of all this is, don't use sudoscript to give 24people root shells unless you trust them. Another possibility is that 25you may be forced into giving someone such a shell. In that case, 26sudoscript will give you an audit trail until the user decides to do 27something to evade it. 28 29Giving People non-Root Shells 30 31A new feature of sudoscript as of version 2.1.0 is the ability to run 32audited shells as users other than root. This narrows the scope of 33what a malicious user might do to evade the audit trail sudoscript 34provides. Unfortunately, there are still at least two ways (and 35probably more) that a user can do this. First, an xterm will still 36open an unaudited window. Second, with the current sudoscript 37architecture, a user must be able to write to the named pipe connected 38to the logging daemon. ANY terminal output in the audited shell will 39be written to the pipe. So a clever user could do something bad, then 40simply cat(1) a file containing a very large, but innocent terminal 41session to his or her screen. After a certain point, the sudoscript 42log files will turn over enough times to flush the evidence of the bad 43action off the system. There are defensive steps sudoscriptd could 44take to minimize some of the obvious attacks. The daemon could watch 45for large quantites of similar data, as would result from a 46'dd if=/dev/zero ..' or random data such as from 'openssl rand LARGENUMBER'. 47And having a very large logging partition would help deter such 48attacks. Also, looking at the timestamps might show suspiciously 49rapid command invocation in the case of a phony login session. But the 50weakness is open ended, since an attacker can choose practically any 51data to throw at the logging daemon. Frankly, I can't think of any way 52an application like sudoscript running on a more-or-less standard 53version of Unix could get around this completely. Because of this, 54I haven't taken the trouble implement any of the defensive steps 55outlined above. 56 57Conclusion 58 59Sudoscript was written in an environment where users already had 60root. (For details see http://egbok.com/sudoscript/PORCMOLSULB.html) 61In that environment, I was not concerned that my users would 62deliberately break system security. I was more concerned that they 63might inadvertently screw-up their systems. Sudoscript allowed me to 64have a recent audit trail of user activity to consult when something 65went wrong. It has saved my and my users' bacon many times. Used 66in that way, sudoscript is a useful tool. Used to try to enforce accountability 67on a hostile user population, it has dubious value in my opinion. 68 69