stv@qantel.UUCP (Steve Vance@ex2499) (06/22/85)
This has probably been asked before, but I don't remember seeing it. We
have 4.2BSD unix, which has a file /etc/remote which can contain the
names of systems people can "tip" to. You can say "pn=@" for an entry,
which allows you to put the phone number in a file called /etc/phones,
presumably so that you can chmod it to 400 so that only uucp can read
it--comperable to L.sys. You want to keep the phone numbers of other
systems a secret, at least I do. However, unless the permissions on
/etc/phones are 444, tip can't read the file, even if tip is suid to
uucp. Is this the way it should be, or is there a patch to tip, or am I
missing something? Why have /etc/phones, if you can't keep the numbers
secret?
--
Steve Vance
{dual,hplabs,intelca,nsc,proper}!qantel!stv
dual!qantel!stv@berkeley
Qantel Corporation, Hayward, CAroot@bu-cs.UUCP (Barry Shein) (06/29/85)
>From: keith@motel6.UUCP (Keith Packard) >Subject: Re: Read permission on /etc/phones >The problem with tip is that, after locking the modem port, it >setuid's back to the original invoker's uid/gid. This is >supposed to patch the security hole surrounding shell escapes >and file transfers. Fine but; alas; it doesn't read /etc/phones >until it has forked and setuid'ed so, unless the file is >444 or better, it can't read it. I can't think of a simple solution >to this, it has to read the phones file first and save the information >until it needs it. > >Keith Packard Good news! You only have to *open* the file while priv'd, the open file descriptor is not further checked (at least not in 4.2bsd tho I doubt it is different in any O/S, let alone UNIX...anybody?) If you want to fix this all you would have to do is open /etc/phones while priv'd, save the file descriptor/pointer into an extern (probably) and comment out the open you find later. Of course this assumes it only reads the phones file once but a rewind() and getting rid of the close should get around multiple reading also as long as file descriptors aren't precious commodities. Is this good news? I assume so, I think the only line of defense need be at the open, not the r/w tho sounds like a general place to scout around for security holes?! Like, what if I find a program that uses something like a -f arg and later goes interactive and I have the /dev/fd? driver...I dunno... -Barry Shein, Boston University Free associating in public, as usual
pilotti@telesoft.UUCP (Keith Pilotti @shine) (07/03/85)
In article <> root@bu-cs.UUCP (Barry Shein) writes: >>From: keith@motel6.UUCP (Keith Packard) >>Subject: Re: Read permission on /etc/phones > >>The problem with tip is that, after locking the modem port, it >>setuid's back to the original invoker's uid/gid. This is >>supposed to patch the security hole surrounding shell escapes >>and file transfers. Fine but; alas; it doesn't read /etc/phones >>... Another problem this causes involves /usr/spool/uucp security and LCK files. It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as this leaves a hole for (admittedly clever) vandalism. However, with the 4.2BSD version of `tip', this causes the LCK files to be left around after `tip' exits, preventing use of the port until manual intervention by a "privileged user". `tip' creates the LCK file while SUID, and no longer has write permission in /usr/spool/uucp once it changes the UID. The LCK file therefore remains. For binary sites the only "solution" seems to be to leave this directory writable. Yuck. /+\ Keith ________________________________________________________ KEITH F. PILOTTI -- TeleSoft (619) 457-2700 x172 10639 Roselle St, SanDiego, CA 92121 (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti (ARPA) Pilotti@UCSD
keith@motel6.UUCP (Keith Packard) (07/03/85)
In article <472@qantel.UUCP> stv@qantel.UUCP (Steve Vance@ex2499) writes: >This has probably been asked before, but I don't remember seeing it. We >have 4.2BSD unix, which has a file /etc/remote which can contain the >names of systems people can "tip" to. You can say "pn=@" for an entry, >which allows you to put the phone number in a file called /etc/phones, >presumably so that you can chmod it to 400 so that only uucp can read >it--comperable to L.sys. You want to keep the phone numbers of other >systems a secret, at least I do. However, unless the permissions on >/etc/phones are 444, tip can't read the file, even if tip is suid to >uucp. Is this the way it should be, or is there a patch to tip, or am I >missing something? Why have /etc/phones, if you can't keep the numbers >secret? >-- > >Steve Vance >{dual,hplabs,intelca,nsc,proper}!qantel!stv >dual!qantel!stv@berkeley >Qantel Corporation, Hayward, CA The problem with tip is that, after locking the modem port, it setuid's back to the original invoker's uid/gid. This is supposed to patch the security hole surrounding shell escapes and file transfers. Fine but; alas; it doesn't read /etc/phones until it has forked and setuid'ed so, unless the file is 444 or better, it can't read it. I can't think of a simple solution to this, it has to read the phones file first and save the information until it needs it. Keith Packard ...!tektronix!azure!motel6!keith ...!tektronix!reed!motel6!keith ...!tektronix!azure!keithp Tektronix
honey@down.FUN (Peter Honeyman) (07/04/85)
a possible solution is to follow honey danber's lock file treatment. assuming tip's lock files have the same format as uucp's, the lock file contains the pid of the process that created it. write a program that reads the lock file and issues signal 0 to the named pid. if the return is 0 or EPERM, the lock file is valid, otherwise it should be removed. if binary license is a problem, make tip a shell script that calls tip, then this program. i leave the details to your imagination. peter
root@bu-cs.UUCP (Barry Shein) (07/05/85)
>From: pilotti@telesoft.UUCP (Keith Pilotti @shine) >Newsgroups: net.bugs.uucp >Subject: Re: Read permission on /etc/phones >Keywords: tip, uucp, LCK >Summary: 4.2BSD `tip' "breaks" UUCP security > > Another problem this causes involves /usr/spool/uucp security and LCK > files. > > It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as > this leaves a hole for (admittedly clever) vandalism. > > However, with the 4.2BSD version of `tip', this causes the LCK files to > be left around after `tip' exits, preventing use of the port until > manual intervention by a "privileged user". > > `tip' creates the LCK file while SUID, and no longer has write > permission in /usr/spool/uucp once it changes the UID. The LCK > file therefore remains. > >** For binary sites the only "solution" seems to be to leave this >** directory writable. Yuck. > > /+\ Keith Not completely true: Write a little program, call it tip.c with the following flow: 1. set up whatever signals make you comfortable 2. exec the 'real' tip, passing it's argv down 3. wait for completion 4. remove the LCK file and exit Move the 'real' tip somewhere else (/usr/lib/tip comes to mind) and code that into your program #define TIP "/usr/lib/tip" compile and put this thing into where tip used to be (/usr/ucb/tip probably) and make *it* setuid (probably to uucp.) When tip exits this parent will have the priv to remove the offending LCK file. You could probably do it with a sh program, give or take various warnings on the net about setuid sh programs and how much that concerns you. I haven't done this but I have done things like it and it should solve your problems (and problems like it.) Although I vastly prefer the sources there are some standard tricks like this in UNIX to do workarounds easily. -Barry Shein, Boston University
anders@suadb.UUCP (Anders Bj|rnerstedt) (07/05/85)
In article <telesoft.154> pilotti@telesoft.UUCP (Keith Pilotti @shine) writes: > > However, with the 4.2BSD version of `tip', this causes the LCK files to > be left around after `tip' exits, preventing use of the port until > manual intervention by a "privileged user". > > `tip' creates the LCK file while SUID, and no longer has write > permission in /usr/spool/uucp once it changes the UID. The LCK > file therefore remains. > > For binary sites the only "solution" seems to be to leave this > directory writable. Yuck. You could circumvent the problem by writing a script (called say newtip) like: ---------------- #!/bin/sh #Newtip releases the lock file after tip terminates. if /usr/bin/tip $* then /usr/lib/uucp/lockrelease $* fi -------------- Where lockrelease is a simple program which suid's to root (or uucp) and removes the appropriate lockfile. We have a solution like this for using kermit over uucp lines while observing the locking conventions of uucp. This uses two small programs, both "lockrelease" and a "lockset". --------------------- Anders Bj|rnerstedt Department of Information Processing & Computer Science University of Stockholm S-106 91 Stockholm Sweden UUCP: {seismo,decvax,philabs}!{mcvax,ukc,unido}!enea!suadb!anders
dave@lsuc.UUCP (David Sherman) (07/07/85)
In article <154@telesoft.UUCP> pilotti@telesoft.UUCP (Keith Pilotti @shine) writes: || `tip' creates the LCK file while SUID, and no longer has write || permission in /usr/spool/uucp once it changes the UID. The LCK || file therefore remains. || || For binary sites the only "solution" seems to be to leave this || directory writable. Yuck. Why not just write a simple set-UID program which removes the LCK file and nothing else? You can get fancy with various checks, of course, but in its simplest form it's a one-line C program. Dave Sherman The Law Society of Upper Canada Toronto -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave
dave@lsuc.UUCP (David Sherman) (07/07/85)
In article <696@lsuc.UUCP> I write: ||Why not just write a simple set-UID program which removes ||the LCK file and nothing else? You can get fancy with various ||checks, of course, but in its simplest form it's a one-line ||C program. Whoops, I forgot one thing. You want this done automatically when tip exits. So move tip to /usr/lib and make tip a shell file which reads trap '/usr/lib/cleanLCK' 0 1 2 3 9 15 /usr/lib/tip $* Dave Sherman -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave
david@ukma.UUCP (David Herron, NPR Lover) (07/10/85)
In article <697@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: >In article <696@lsuc.UUCP> I write: >||Why not just write a simple set-UID program which removes >||the LCK file and nothing else? You can get fancy with various >||checks, of course, but in its simplest form it's a one-line >||C program. > >Whoops, I forgot one thing. You want this done automatically >when tip exits. So move tip to /usr/lib and make tip a shell >file which reads > trap '/usr/lib/cleanLCK' 0 1 2 3 9 15 > /usr/lib/tip $* How does this solve anything? I don't see where this removes the lock file. 1) cleanLCK isn't called explicitly, only on a signal, which won't happen. 2) cleanLCK *cannot* know which lock file to delete. Answer me one question, why are we discussing tip problems in net.bugs.uucp? -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> --- or david%ukma.uucp@anl-mcs.arpa --- Or even anlams!ukma!david@ucbvax.arpa --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david "It's *Super*User* to the rescue!"
ddl@harvard.ARPA (Dan Lanciani) (07/13/85)
> In article <697@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: > > How does this solve anything? I don't see where this removes the > lock file. > > 1) cleanLCK isn't called explicitly, only on a signal, which > won't happen. > 2) cleanLCK *cannot* know which lock file to delete. > > > Answer me one question, why are we discussing tip problems in net.bugs.uucp? > -- > --- David Herron > --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> > --- or david%ukma.uucp@anl-mcs.arpa > --- Or even anlams!ukma!david@ucbvax.arpa > --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david > --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david > > "It's *Super*User* to the rescue!" Although I never tried to fix tip, I encountered the same problem with cu on 2.9. The solution I found was to retain the effective uid by swapping uid's (setreuid(geteuid(), getuid())) after creat'ing the lockfile. With the effective uid set back to the caller's real uid, file accesses work correctly and the only pitfalls are shell escapes and such which much be prefaced with a setuid(geteuid()). When it comes time to remove the lockfile (or access /etc/phones) just swap uid's again. Of course, not everyone has a setreuid call, but it does seem to solve the common problem of setuid programs which must access user files. (The access system call really isn't much good for any user except root...) Also, while cu is simple enough that I could satisfy myself that this approach didn't introduce any security holes, tip may be more complicated. Almost forgot: If you do this to cu, be sure to swap uid's again before trying to kill the reader process or else have it run as your real uid. Dan Lanciani ddl@harvard
dave@lsuc.UUCP (David Sherman) (07/19/85)
References:<472@qantel.UUCP> <170@motel6.UUCP> <154@telesoft.UUCP> <696@lsuc.UUCP> <697@lsuc.UUCP> <1953@ukma.UUCP> In article <1953@ukma.UUCP> david@ukma.UUCP (David Herron, NPR Lover) writes: > In article <697@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: > >||Why not just write a simple set-UID program which removes > >||the LCK file and nothing else? You can get fancy with various > >||checks, of course, but in its simplest form it's a one-line > >||C program. > > > >Whoops, I forgot one thing. You want this done automatically > >when tip exits. So move tip to /usr/lib and make tip a shell > >file which reads > > trap '/usr/lib/cleanLCK' 0 1 2 3 9 15 > > /usr/lib/tip $* > > How does this solve anything? I don't see where this removes the > lock file. > > 1) cleanLCK isn't called explicitly, only on a signal, which > won't happen. > 2) cleanLCK *cannot* know which lock file to delete. (1) Notice the trap on 0. That will pick up the case of normal exit, on at least some implementations of UNIX. Of course, you can put another "/usr/lib/cleanLCK" after the call to tip. (2) As I SAID, you can get fancier. This version assumes you have only one dialout line, so the file to delete is LCK..cul0 or whatever. If you have several, just pass $* to cleanLCK and have it parse the args to tip to figure out which line should be unlocked. > Answer me one question, why are we discussing tip problems in net.bugs.uucp? Because that's where the discussion began, because the discussion will be short-lived, and because it's still related to UUCP, since that's where the LCK file goes. Dave Sherman -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave