dan@rna.UUCP (Dan Ts'o) (04/18/87)
I did a PS on our 4.2BSD system today and found extra copies of /etc/update, cron and a few other running, owned by one of our users. I am surprised that all sorts of system daemons are executable by non-root uids. I know I could go through each one a chmod them but it seems strange to me that the system would be distributed in this manner.
todd@uhccux.UUCP (04/22/87)
In article <623@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: > I did a PS on our 4.2BSD system today and found extra copies of >/etc/update, cron and a few other running, owned by one of our users. I am >surprised that all sorts of system daemons are executable by non-root uids. >I know I could go through each one a chmod them but it seems strange to me >that the system would be distributed in this manner. I think this was discussed on the net not too long ago....but.... It seems that BSD releases are full of weird security holes as delivered. I know I spent weeks closing up holes in Ultrix (a mutation of 4.2bsd) before I was willing to have more than a few "real" users use the VAX. I guess the UCB folks are not too concerned with security...Maybe each person has their own VAX or Sun... :-) ....todd -- Todd Ogasawara, U. of Hawaii Computing Center UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd ARPA: uhccux!todd@nosc.MIL INTERNET: todd@uhccux.UHCC.HAWAII.EDU
swa@COMET.LCS.MIT.EDU (Steven Augart) (04/22/87)
From: The Perplexed Wiz <todd@uhccux.uucp> Date: 21 Apr 87 23:38:31 GMT In article <623@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: > I did a PS on our 4.2BSD system today and found extra copies of >/etc/update, cron and a few other running, owned by one of our users. I am >surprised that all sorts of system daemons are executable by non-root uids. >I know I could go through each one a chmod them but it seems strange to me >that the system would be distributed in this manner. I think this was discussed on the net not too long ago....but.... It seems that BSD releases are full of weird security holes as delivered. I know I spent weeks closing up holes in Ultrix (a mutation of 4.2bsd) before I was willing to have more than a few "real" users use the VAX. I guess the UCB folks are not too concerned with security...Maybe each person has their own VAX or Sun... :-) ....todd In what way does /etc/update or /etc/cron being world-executable constitute a security hole? After all, any user can write a program that does the same thing that cron or update does, and then run it themselves. Having /etc/cron or /etc/update executable only means that a user can run it without having to write one of their own. Anybody who tries to run programs out of /etc without knowing what they do deserves what they get, anyway... the only "security" problem is that by running these things they'll slow down the system slightly by creating more work for it to do. SWA
chris@mimsy.UUCP (04/22/87)
That the various daemons in /etc are runnable by all in 4.xBSD is *not* a security hole. It *is* an annoyance. But then, anyone can use syslog to blither all over your console and/or log files. It would be nice if this were a bit more traceable. This argues for some way to obtain the user ID of the other end of a connected Unix domain socket---something we happen to need here for something unrelated to logging. (This should be easy to add. Store the [real? effective?] uid of the owner of a Unix domain socket in the PCB for that socket. Use SO_GETOPT to get the remote uid, by following unp_conn.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
kre@munnari.oz (Robert Elz) (04/22/87)
In article <623@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: > I did a PS on our 4.2BSD system today and found extra copies of > /etc/update, cron and a few other running, owned by one of our users. In article <439@uhccux.UUCP>, todd@uhccux.UUCP (The Perplexed Wiz) replies: > It seems that BSD releases are full of weird security holes as delivered. I'm not sure what your definition of a "security hole" is, but this doesn't fit mine. Its just a slightly silly setup, it doesn't allow anything at all that users couldn't do anyway. If I have an inclination to run /etc/update, but /etc/update is 700 mode (or similar), I just cp /usr/src/etc/update.c .; cc update.c; ./a.out and it runs. If I can do it that way (so the system staff can't even see that its update that's running easily) I can't see why I shouldn't just be able to do /etc/update. Its a bit of a dumb thing to want to do, but not a security hole. If the source is protected incidentally, then I just do cat <<! >update.c main() { for (;;) sleep(60), sync(); } ! instead of the copy, and then continue. Exactly the same applies to cron .. having a user run it is a bit dumb, but not any kind of security hole. You might want to protect crontab rather than cron, so users can't see what processes you have cron run, but that's just obscurity security, and is only marginally useful. I should say that even given all that, I do recommend protecting cron, update, etc .. the type of user dumb enough to actually run one of those things is usually also dumb enough not to know any of the above techniques to get around the protection, and it does save wasting system resourses (an extra few copies of update running can limit the effectiveness of the buffer cache). kre
todd@uhccux.UUCP (04/22/87)
In article <6405@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >That the various daemons in /etc are runnable by all in 4.xBSD is >*not* a security hole. It *is* an annoyance. But then, anyone >can use syslog to blither all over your console and/or log files. The /etc stuff is not too bad (as you mention), however there are a whole bunch of directories and files with public write permissions set when 4.xbsd is dumped to disk fresh from a tape. As for the /etc stuff. I just turned off public access to the possibly annoying stuff...todd -- Todd Ogasawara, U. of Hawaii Computing Center UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd ARPA: uhccux!todd@nosc.MIL INTERNET: todd@uhccux.UHCC.HAWAII.EDU