chip@ateng.UUCP (Chip Salzenberg) (04/13/88)
In article <7049@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >I'm uid=501(heiby) gid=101(mot) on my system, and bunches of "?" are >displayed instead of sensitive information when I invoke uucico. >When I invoke uucico while logged in as "root", I get to see everything. >If your implementation does not do this, then it should be fixed >by your vendor. Actually, what should be fixed are the access permissions of uucico: 6770. On all the SCO Xenix System V systems that I administer, I run the equivalent of the following: chmod 775 /usr/spool/uucp chmod 6770 /usr/lib/uucp/uucico chown uucp /usr/bin/uu* chgrp uucp /usr/bin/uu* chmod 6771 /usr/bin/uu* (Note that the /usr/bin/uu* excludes uuto and uupick, which are shell scripts.) This closes several security holes: Only root (and uucp) can invoke uucico at all. No one but user uucp and group uucp can create or remove files in the spool directory. Files in the spool directory are created with owner uucp and group uucp. By default, /usr/bin/uu* are setuid but not setgid, which causes all files in the spool directory to be created with modes 660 and with the current group of the user who requested the spool. Thus if you are in the same group with that person, you can read his outbound mail! Oh yes -- be sure to also run chgrp uucp /bin/cu chmod g+s /bin/cu or else cu won't be able to create the device lock file in /usr/spool/uucp. -- Chip Salzenberg "chip@ateng.UU.NET" or "codas!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't."
michael@stb.UUCP (Michael) (05/16/88)
In article <234@ateng.UUCP> chip@ateng.UUCP (Chip Salzenberg) writes: >In article <7049@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >>I'm uid=501(heiby) gid=101(mot) on my system, and bunches of "?" are >>displayed instead of sensitive information when I invoke uucico. >>When I invoke uucico while logged in as "root", I get to see everything. >>If your implementation does not do this, then it should be fixed >>by your vendor. > >Actually, what should be fixed are the access permissions of uucico: 6770. > [details ommited] Actually, there is something much better than this: 2770. All the uucp programs should use set-G-id for protection; it is sufficient to maintain security. The problem with set-U-id, especially for uucp, is that uucp and uux cannot read your files unless they are world-readable, which means anyone can read them, and the whole security feature is lost. Michael : --- : Michael Gersten uunet.uu.net!ucla-an.ANES\ : ihnp4!hermix!ucla-an!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : "Machine Takeover? Just say no." : "Sockets? Just say no." <-- gasoline
honey@umix.cc.umich.edu (Peter Honeyman) (05/19/88)
Michael writes: >The problem with set-U-id, especially for uucp, is >that uucp and uux cannot read your files unless they are world-readable, >which means anyone can read them, and the whole security feature is lost. fixed in honey danber. about 5 years ago. (by dan.) peter
mboen@nixpbe.UUCP (Martin Boening) (12/01/88)
Recently I had a problem with two suns connected via direct link using uucp. Any kind of I/O-Redirection didn't work. Things like uux - "remotesys!command" < inputfile resulted in XQT DENIED on the remote system as did things like uux "remotesys!command < !inputfile" (L.cmds allowed the command and it worked fine if no redirection occured anywhere in the uux- command. When I called at Sun and asked about this, I was told, that for security reasons I/O-Redirection had been eliminated from the uucp supplied by Sun. I couldn't get a more specific description from them. My question now is, why does stuffing the standard input for uux into the standard input of the invoked remote command pose a security problem ? Why, indeed, does any redirection of standard input for the remote command to a file on the local (invoking) system pose a risk ? (Especially since execution of a shell is not allowed by L.cmds) Any helpful hints are appreciated, as we are doing some work on security at the moment. (flames, however, will be copied to /dev/null) Thanks a lot Martin: Email: mboen@nixpbe.UUCP