sloane@UKANVAX.BITNET (Bob Sloane) (05/23/88)
Darren Griffiths writes: > Other things that were broken include programs >like PHOTO that use pseudo-terminal drivers to act as session loggers. > >It seems that some of the programs that use pseudo-terminal drivers will have >to be modified before they will be able to work again. This is unfortunate, >but it is necessary to provide extra security on VMS systems. I was wondering if anyone has any hints as to how PHOTO can be fixed to work with the new security patch. I am taking a lot of heat from users to get it working again. It appears that a process must have SYSPRV turned on to allocate a Pseudo Terminal device. Since PHOTO uses a PTY for the input/output files for LIB$SPAWN, it must have SYSPRV turned on when the LIB$SPAWN is done. This means that the subprocess has SYSPRV in its authorized privs. I don't really want to give all 2000 students on campus SYSPRV, and I haven't been able to figure out how to EXACTLY duplicate LIB$SPAWN using SYS$CREPRC. If you know of any way to get PHOTO working, PLEASE let me know. I agree that security is important, but it would be nice if DEC would help us out by keeping currently working software running when they issue these fixes, or at least providing clues about how to fix broken programs. Thanks for any help. Bob Sloane University of Kansas Computer Center (913) 864-0444 SLOANE@UKANVAX.BITNET
dagg@lace.lbl.gov (Darren Griffiths) (05/24/88)
In article <8805231259.AA16714@ucbvax.Berkeley.EDU> sloane@UKANVAX.BITNET (Bob Sloane) writes: >Darren Griffiths writes: >> Other things that were broken include programs >>like PHOTO that use pseudo-terminal drivers to act as session loggers. >> >>It seems that some of the programs that use pseudo-terminal drivers will have >>to be modified before they will be able to work again. This is unfortunate, >>but it is necessary to provide extra security on VMS systems. > >I was wondering if anyone has any hints as to how PHOTO can be fixed to >work with the new security patch. I am taking a lot of heat from users >to get it working again. It appears that a process must have SYSPRV >turned on to allocate a Pseudo Terminal device. Since PHOTO uses a >PTY for the input/output files for LIB$SPAWN, it must have SYSPRV turned >on when the LIB$SPAWN is done. This means that the subprocess has >SYSPRV in its authorized privs. I don't really want to give all 2000 >students on campus SYSPRV, and I haven't been able to figure out how to >EXACTLY duplicate LIB$SPAWN using SYS$CREPRC. If you know of any way >to get PHOTO working, PLEASE let me know. > I don't use PHOTO myself, and I don't have access to it so I can't do the the fixes, but I may be able to suggest one way to solve the problem. It seems clear that the program will need to be installed with privileges, but the privileges don't need to be turned on all of the time. The security fixes take away world read and execute access from devices that use the TTDRIVER. One possible fix maybe to have PHOTO turn on privs, grab the terminal it will be using and change the owner UIC and anything else that is required and then turn of privileges. I'm sorry I can't be a little more explicit, but that is basically what DEC has done with WTDRIVER. I suggest grabbing someone who is an expert on the PHOTO internals (or at least seen the source code) and can make the changes. >I agree that security is important, but it would be nice if DEC would >help us out by keeping currently working software running when they issue >these fixes, or at least providing clues about how to fix broken programs. The last time I talked to DEC about the problems they said that a letter was in the works and will be sent to everyone who received the security update. I haven't seen any letter yet, but if it does show up I doubt it will be to technical. DEC has been very helpful whenever I have asked them questions about these problems, perhaps if someone who uses PHOTO and feels like being responsible for doing the fixes could call Colorado they will be able to get some help. --darren (dagg@lbl.gov)
info-vax-request%kl.sri.COM%KL.SRI.COM%lbl%sfsu1.hepnet@LBL.GOV (05/29/88)
Received: from KL.SRI.COM by LBL.Gov with INTERNET ;
Sat, 28 May 88 16:51:59 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Mon 23 May 88 22:19:51-PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA28763; Mon, 23 May 88 18:09:42 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-vax@kl.sri.com (info-vax@kl.sri.com)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 May 88 00:57:43 GMT
From: helios.ee.lbl.gov!lace.lbl.gov!dagg@nosc.mil (Darren Griffiths)
Organization: Lawrence Berkeley Laboratory, Berkeley
Subject: Re: the recent security patch
Message-Id: <53@helios.ee.lbl.gov>
References: <8805231259.AA16714@ucbvax.Berkeley.EDU>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com
In article <8805231259.AA16714@ucbvax.Berkeley.EDU> sloane@UKANVAX.BITNET (Bob Sloane) writes:
>Darren Griffiths writes:
>> Other things that were broken include programs
>>like PHOTO that use pseudo-terminal drivers to act as session loggers.
>>
>>It seems that some of the programs that use pseudo-terminal drivers will have
>>to be modified before they will be able to work again. This is unfortunate,
>>but it is necessary to provide extra security on VMS systems.
>
>I was wondering if anyone has any hints as to how PHOTO can be fixed to
>work with the new security patch. I am taking a lot of heat from users
>to get it working again. It appears that a process must have SYSPRV
>turned on to allocate a Pseudo Terminal device. Since PHOTO uses a
>PTY for the input/output files for LIB$SPAWN, it must have SYSPRV turned
>on when the LIB$SPAWN is done. This means that the subprocess has
>SYSPRV in its authorized privs. I don't really want to give all 2000
>students on campus SYSPRV, and I haven't been able to figure out how to
>EXACTLY duplicate LIB$SPAWN using SYS$CREPRC. If you know of any way
>to get PHOTO working, PLEASE let me know.
>
I don't use PHOTO myself, and I don't have access to it so I can't do the
the fixes, but I may be able to suggest one way to solve the problem. It
seems clear that the program will need to be installed with privileges, but the privileges don't need to be turned on all of the time. The security fixes take away world read and execute access from devices that use the TTDRIVER. One
possible fix maybe to have PHOTO turn on privs, grab the terminal it will be
using and change the owner UIC and anything else that is required and then
turn of privileges. I'm sorry I can't be a little more explicit, but that is
basically what DEC has done with WTDRIVER. I suggest grabbing someone who
is an expert on the PHOTO internals (or at least seen the source code) and
can make the changes.
>I agree that security is important, but it would be nice if DEC would
>help us out by keeping currently working software running when they issue
>these fixes, or at least providing clues about how to fix broken programs.
The last time I talked to DEC about the problems they said that a letter
was in the works and will be sent to everyone who received the security
update. I haven't seen any letter yet, but if it does show up I doubt it
will be to technical. DEC has been very helpful whenever I have asked them
questions about these problems, perhaps if someone who uses PHOTO and feels
like being responsible for doing the fixes could call Colorado they will be
able to get some help.
--darren
(dagg@lbl.gov)