PPP Security and Those Pesky Run-Only Scripts

Question: who should be allowed to initiate PPP connections?

The answer, if you examine the permissions of the PPP utilities, is confusing at best. Four components are involved in starting up the connection: two scripts (ppp-on and ppp-on-dialer) and two programs (pppd and chat). As they are set up by the PPP utilities installation process (note: the assumptions about permissions change for PPP utilities obtained through other distributions), these four files have the following permissions:

• ppp-on is readable by root and executable by all; the limited read permissions protect the passwords contained in the script while theoretically allowing anyone to run. (The ppp-off script to shut down the connection has the same permissions.)
• pppd, called by ppp-on, is setuid root, allowing any user to gain access to the serial port.
• ppp-on-dialer, called by pppd with the actual user's privileges, is read-write-execute by root only—very strange permissions for a file containing no secrets and performing an operation (running chat) that any user could do.
• chat, called by ppp-on-dialer, has normal execute permissions.

There are two barriers to initiating PPP connections by non-privileged users:

1. The permissions of the ppp-on-dialer script are restrictive.
2. Run-only programs work but run-only scripts (such as ppp-on) do not.

The latter limitation is a UNIX security feature: you have permission to execute the script, but do not have permission to read it into an interpreter. If you try to use the utilities “as is”, you must indeed be root to start PPP. Alternately, you could follow Phil Hughes' advice in his May 1997 LJ column and write a special setuid program to start and stop PPP.

I have decided on my system (I am, admittedly, the only user) that non-privileged users can initiate PPP connections. This policy was effected with one change to the utilities—making ppp-on-dialer read/runnable by all—and one hack: rscript.

The rscript utility is a setuid-root program to solve the run-only script problem; it opens the script as a privileged user, then interprets it as the actual user. The invocation:

rscript

• The interpreter is capable of accepting script input through stdin while recognizing positional parameters. For example, Bourne-style shells can be invoked as sh -s a b c to accept script input through stdin and pass a, b and c to the script as positional parameters. The syntax for doing so differs among interpreters, so rscript uses the interpreter's base name and the information in a table to construct the proper command line.
• The script must not expect any input from stdin, since that channel is otherwise engaged.

Despite the restrictions, rscript is useful in conjunction with the PPP scripts.

Is rscript a security hole? Barring the user's ability to replace the interpreter executing the script, rscript does not appear to allow the user access to the contents of the script or to perform any privileged operations. (If I'm wrong, I'm sure I'll hear about it.)