uucp security - inquiring minds want to know
William E. Davidsen Jr
davidsen at steinmetz.ge.com
Wed Aug 10 22:33:35 AEST 1988
I give, I give! I got 60+ requests for this so here it is.
I am reposting a few articles about uucp hardening which I have used as
a starting point for hardening my own system. I don't totally agree
with all the things in them, but they are useful input. In particular, I
like to leave uucp as the main uucp file owner, and move all the logins
to other UIDs.
This is the heart of what I do; change all data files in /usr/lib/uucp
to be owned by uucp, rw to owner only, all uucp programs, such as
uucico, uuxqt, uucp, etc, should all be owned by uucp and run setuid.
The uucp related programs in /usr/bin should be done as well, except
uuto and uupick if you have them, they failed on my system when setuid.
The uucp account is made no login. A second account having the same UID
and GID is setup with your favorite shell to do maintenence. The second
login should follow uucp in the passwd file, to allow mail to work
correctly. Then each system dialing into yours is given its own
username and UID, and its login shell is set to /usr/lib/uucp/uucico
(or wherever uucico lives in your system). This prevents anyone from
running under the uucp UID.
If your system will allow it, make up a group just for uucp dialin, put
all the dialing id's there, and don't allow anyone but owner to execute
uucico (chmod 4700 uucico). On some systems this may not work, and you
will have to put the dialin id's as group uucp, and allow that group to
execute uucico (chmod 4710 uucico).
In all cases, no interactive users should run as UID or GID uucp, other
than the maintenence account. This will prevent executing uucico with
debug set and getting login info about systems you call, and/or forcing
calls you don't want to originate and pay for.
Here are the original articles I read about uucp hardening, they were
the starting point for my learning curve in this matter. They were
originally on the unix-pc, but contain info directly applicable to any
"old" uucp, and with modifications to HDB as well.
================
Path: chinet!ethos!gizzmo!fthood!egray
From: egray at fthood
Newsgroups: unix-pc.uucp
Subject: uucp security
Message-ID: <6700001 at fthood>
Date: 24 Nov 86 19:14:00 GMT
Lines: 117
Nf-ID: #N:fthood:6700001:000:5839
Nf-From: fthood!egray Nov 24 14:14:00 1986
The 'rules' of uucp security were not applied to the Unix PC, perhaps
because it was assumed that it was going to be a 'home' computer. That
might well be the case in quite a few instances but in other situtations,
the Unix PC might be in a 'hostile' environment. The following dicussion
is directed to those your wish to harden their uucp security.
The first rule is to have an administrative account to own the uucp
commands and directories (call it 'uucpadm' for example). This account
should NOT have the same UID number as the 'uucp' account. The account
should be a normal 'user' account and have one of the standard shells in
the 7th field of the password file instead of /usr/lib/uucp/uucico. The
purpose of this is to prevent a user on a remote system using 'uucp' from
gaining access to your uucp commands and directories.
The second rule is to restrict execute permission on the uucico program.
Any person who can execute this command can turn on the debugging with
the -x option and gain access to the login and passwords to your uucp
accounts on all of your remote systems. This can be easily prevented by
removing the execute permission to 'others'.
The third rule ties the first two together. In order for your uucp
accounts to be able to execute 'uucico', you must create a group for
these users. This group (call it 'uucpgrp' for example) would be
assigned to the uucico program the uucp directories and to the 'uucp'
accounts. In this way only members of this group would have execute
permission on 'uucico'.
Some additional consideration should be given to providing unique UID's
for each 'uucp' account. For example, if the remote machines 'sys1'
and 'sys2' both call your system then they should have unique UID's but
share the same group. This is to provide an accurate accounting records
of login times, etc.
Every uucp file and directory should have it's write permission removed
to 'others'. The files /usr/lib/uucp/L.sys and /usr/lib/uucp/USERFILE
should be set to mode 400 (read to the owner and no access to the
group or 'others').
The /usr/lib/uucp/USERFILE determines which accounts should have 'free
reign' over your files. This file should be set to give read permission
to whatever files your remotes systems need. On a 'generic' account
like 'uucp', the read permission should be set to /usr/spool/uucppublic.
This is to allow the machine calling in as 'uucp' to gain access to
only those files that you have placed in the /usr/spool/uucppublic
directory.
This is the /usr/spool/uucp directory:
drwxrwxr-x 2 uucpadm uucpgrp 272 Nov 23 19:13 .
drwxrwxr-x 5 root bin 80 Oct 11 1985 ..
-rw------- 1 uucpadm uucpgrp 58 Nov 23 18:33 AUDIT
-rw-rw-r-- 1 uucpadm uucpgrp 97 Nov 23 18:33 ERRLOG
-rw-rw-rw- 2 root root 4 Nov 23 19:11 LCK..ph0
-rw-rw-r-- 1 uucpadm mail 78 Jun 5 04:30 LOGDEL
-rw-rw-r-- 1 uucpadm uucpgrp 0 Nov 23 18:33 LOGFILE
-rw-rw-rw- 2 root root 4 Nov 23 19:11 LTMP.44
-rw-r--r-- 1 uucpadm uucpgrp 7320 Nov 23 18:33 Log-WEEK
-rw-rw-r-- 1 uucpadm uucpgrp 1693 Nov 23 18:33 SYSLOG
-rw-r--r-- 1 uucpadm mail 59 Nov 10 05:30 o.Log-WEEK
-rw-r--r-- 1 uucpadm uucpgrp 792 Nov 23 18:33 o.Log-WEEK.z
-rw-rw-r-- 1 uucpadm uucpgrp 202 Nov 23 18:33 o.SYSLOG
This is the /usr/lib/uucp directory:
drwxrwxr-x 4 uucpadm uucpgrp 368 Oct 11 1985 .
drwxrwxr-x 13 bin bin 992 Oct 11 1985 ..
drwxrwxr-x 2 uucpadm uucpgrp 32 Jan 1 1970 .OLD
drwxrwxr-x 2 uucpadm uucpgrp 32 Jan 1 1970 .XQTDIR
-rw-r--r-- 1 root uucpgrp 606 Nov 23 18:33 L-devices
-rw-r--r-- 1 uucpadm uucpgrp 24 Jan 1 1970 L-dialcodes
-r--r--r-- 1 uucpadm uucpgrp 39 Aug 11 09:54 L.cmds
-r-------- 1 uucpadm uucpgrp 180 Nov 23 18:33 L.sys
-r-------- 1 root daemon 180 Sep 24 17:19 L.sys.bak
-rw-r--r-- 1 uucpadm uucpgrp 18 Nov 23 18:33 L_stat
-rw-r--r-- 1 uucpadm uucpgrp 26 Nov 23 18:33 L_sub
-rw-r--r-- 1 uucpadm uucpgrp 84 Nov 23 18:33 R_stat
-rw-r--r-- 1 uucpadm uucpgrp 22 Nov 23 18:33 R_sub
-rw-rw-rw- 1 uucpadm uucpgrp 4 Nov 23 18:33 SEQF
-r-------- 1 uucpadm uucpgrp 55 Aug 11 16:13 USERFILE
-r--r--r-- 1 uucpadm uucpgrp 2581 Jan 1 1970 modemcap
---s--x--- 1 uucpadm uucpgrp 69376 Jan 1 1970 uucico
---s--x--x 1 uucpadm uucpgrp 15536 Jan 1 1970 uuclean
-rwxrwxr-x 1 uucpadm operators 390 Jun 11 20:08 uudemon.day
-rwxrwxr-x 1 uucpadm operators 134 Jan 1 1970 uudemon.hr
-rwxrwxr-x 1 uucpadm operators 332 Jun 11 20:08 uudemon.wk
---x------ 1 uucpadm uucpgrp 7586 Jan 1 1970 uusub
---s--x--x 1 uucpadm uucpgrp 21616 Jan 1 1970 uuxqt
These are the permissions of the uucp commands:
---s--x--x 1 uucpadm bin 21942 Jan 1 1970 /usr/bin/uucp
-rwxr-xr-x 1 bin bin 2108 Jan 1 1970 /usr/bin/uucppwd
---s--x--x 1 uucpadm bin 7378 Jan 1 1970 /usr/bin/uulog
---s--x--x 1 uucpadm bin 2248 Jan 1 1970 /usr/bin/uuname
-rwxr-xr-x 1 bin bin 1596 Jan 1 1970 /usr/bin/uupick
---s--x--x 1 uucpadm bin 18042 Jan 1 1970 /usr/bin/uustat
-rwxr-xr-x 1 bin bin 959 Jan 1 1970 /usr/bin/uuto
---s--x--x 1 uucpadm bin 25310 Jan 1 1970 /usr/bin/uux
This the line out of the /etc/group file:
uucpgrp:NONE:11:uucp,uucpadm,sys1,sys2
This is the part of the /etc/passwd file:
uucpadm:MslxlslvaW5E2:5:11:Admin for Uucp:/usr/lib/uucp:
uucp:QKqtywR1ggBeo:6:11:Generic Unix to Unix Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico
usys1:bksugI32a9Z/o:7:11:UUCP for sys1:/usr/spool/uucppublic:/usr/lib/uucp/uucico
usys2:g328dkfgl83wo:8:11:UUCP for sys2:/usr/spool/uucppublic:/usr/lib/uucp/uucico
This is a sample /usr/lib/uucp/USERFILE:
usys1,sys1 /
usys2,sys2 /
uucp, /usr/spool/uucppublic /tmp
greg,sys1 /u/greg
------------------------------
Path: chinet!ethos!mtune!shlepper!andys
From: andys at shlepper.UUCP (andy sherman)
Newsgroups: unix-pc.uucp
Subject: Re: uucp security
Summary: HDB uucico does not echo passwords
Message-ID: <119 at shlepper.UUCP>
Date: 25 Nov 86 13:51:48 GMT
References: <6700001 at fthood>
Organization: AT&T Bell Laboratories, Middletown, NJ
Lines: 33
In article <6700001 at fthood>, egray at fthood writes:
> The second rule is to restrict execute permission on the uucico program.
> Any person who can execute this command can turn on the debugging with
> the -x option and gain access to the login and passwords to your uucp
> accounts on all of your remote systems. This can be easily prevented by
> removing the execute permission to 'others'.
>
> The third rule ties the first two together. In order for your uucp
> accounts to be able to execute 'uucico', you must create a group for
> these users. This group (call it 'uucpgrp' for example) would be
> assigned to the uucico program the uucp directories and to the 'uucp'
> accounts. In this way only members of this group would have execute
> permission on 'uucico'.
>
First off, a lot of the lack of security for the 7300 uucp is in the
version of uucp distributed with the basic system. These
shortcomings, incidentally, are shared with any vanilla SysV R2 UNIX
system. The HoneyDanBer uucp package deals with a lot of these
security holes. For example, there is a port of the HoneyDanBer
uucp to the 7300 which does not echo passwords for uucico debugging.
(I know this package is available inside of AT&T. I don't know
if/when it is released outside the company.)
As for restricted access to uucico, I know that when I send mail,
the uucp stuff goes across under my UID. If you have mail set its
UID to call uucico as uucp or mail, don't you lose the ability
to see what user is attached to which jobs in a uustat or in the log?
--
andy sherman 480 Red Hill Road
at&t bell laboratories Middletown, NJ 07748
DDD: (201) 615-5708
UUCP: {ihnp4,allegra,akgua,cbosgd,vax135,mtune,...}!shlepper!andys
------------------------------
Path: chinet!ethos!mtune!mtung!jmd
From: jmd at mtung.UUCP (JM Donnelly)
Newsgroups: unix-pc.uucp
Subject: Re: uucp security
Message-ID: <837 at mtung.UUCP>
Date: 25 Nov 86 16:15:21 GMT
References: <6700001 at fthood> <119 at shlepper.UUCP>
Reply-To: jmd at mtung.UUCP (JM Donnelly)
Organization: AT&T ISL Middletown NJ USA
Lines: 3
I think that protecting /usr/spool/uucp will break the terminal
emulater (async_main) which tries to create a LCK file there.
--
bill davidsen (wedu at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
More information about the Comp.unix.questions
mailing list