On Tue, 11 Sep 2001, hermit1 wrote: > I have been asked for advice on how to do anonymous telnet to a server > here; the client could be anywhere. There is a need to provide access from > character-only terminals. Upon establishing the telnet session, a perl > script is supposed to run automatically. No, they didn't explain how > they expect a perl script to run without a user ID. Actually, the telnetd bundled with linux can do this. It's the -L option to telnetd, basically: telnet tcp nowait nobody /usr/sbin/tcpd in.telnetd -L /some/program I used this in a previous job to let a custom, pre-authenticated telnet-like client talk to a custom telnet-able application. > I refuse to customize the telnetd binary, the only way I know of to > eliminate the need for a user ID. I suspect changing some PAM > configuration might do it, but I don't want to try that, either. Isn't Solaris source code available nowadays? You could just make it run your custom program instead of /bin/login ... > Unless the strings accepted by the perl script are very carefully > validated, I assume that escape characters would allow the user to issue > system commands. I like the idea of rback from trusted solaris, but the > system is Solaris 7, not 8. Restricted shell would probably help, but I > know little about it. Taint checking in perl would help. Escape characters should have no effect unless they're handed to the shell or used as filenames. The issues are very similar to writing a secure CGI. > I would prefer that the developers would create their own telnet server > combined with the perl script, and I could have this run out of inetd on > port 23. I don't think altering one of the open source telnet servers > to [1. not require a login, and 2. automatically pass all input to the > perl script] would be difficult, and it is probably the safest way to meet > their goal. If you have the developers write their own telnet server, their code will likely be much simpler than the general-purpose telnetd. OTOH, you are relying on your developers to not write buggy code, or recycle buggy code from an existing telnetd implementation. In any case: audit the code, chroot() it in production, and monitor it. James _______________________________________________ firewall-wizards mailing list firewall-wizards@nfr.com http://list.nfr.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Thu Sep 13 2001 - 12:18:39 PDT