Path: utzoo!attcan!uunet!convex!killer!vector!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Crackers and Worms Message-ID: <8701@rpp386.Dallas.TX.US> Date: 19 Nov 88 00:19:14 GMT References: <1308@zippy.eecs.umich.edu> Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Organization: River Parishes Programming, Dallas TX Lines: 29 In article <1308@zippy.eecs.umich.edu> cja@crim.eecs.umich.edu (Charles J. Antonelli) writes: >In article Rahul Dhesi (dhesi@bsu-cs.uucp) writes: >> But at's jobs to be executed are owned by daemon, so isn't being daemon >> just a trivial step away from being root? Somebody mentioned this >> earlier and nobody contradicted him. > >consider the statement contradicted. daemon is just another non-root uid. Rahul may be correct. Various old versions of at(1) were very lax in the security department. Newer at's use the SUID and SGID bits of the file for authentication. It was possible under old at(1) implementations to forge an at-job and become root. The only fix was to turn it off or have it run as some non-privileged user, such as daemon. In which case, you couldn't execute any privileged commands. However, if the work files were stored in a directory which only daemon had write permission in, and this was being used to protect an at-daemon running as root, then being daemon would be one step from root. In short, the problem MAY exist. Other situations might be scripts or crontabs owned by a non-priviledged user, but executed by privileged programs, such as at(1) or cron(1). -- John F. Haugh II +----------Quote of the Week:---------- VoiceNet: (214) 250-3311 Data: -6272 | "Okay, so maybe Berkeley is in north- InterNet: jfh@rpp386.Dallas.TX.US | ern California." -- Henry Spencer UucpNet : !killer!rpp386!jfh +--------------------------------------