JSOTTILE@LOYVAX.BITNET (01/07/88)
I am attempting to tighten security here at our site. I wish to
remove NETMBX privileges to secure from the hole in DECNET with respect
to MAIL. We will be upgrading to VMS 4.7 (we are currently running 4.4)
in a few days.
I have tried removing NETMBX from an account and I find out that it does
everything nice and neat (MAIL was a big issue, but that has NETMBX privs). One
problem remains. We have 2 nodes, GREEN and GREY (don't look at me, I didn't
name them) and we would like our users to be able to SET HOST from node to
node. Both computers share the system disk and UAF files.
Is there a way to remove NETMBX and continue to allow users to SET HOST
or is it wishful thinking?
- John Sottile
(JSOTTILE@LOYVAX.BITNET)
Student Systems Programmer
Loyola College in Marylandnagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) (01/07/88)
> Is there a way to remove NETMBX and continue to allow users to SET HOST > or is it wishful thinking? In general, NO. NETMBX is needed to do anything associated with the network. Removal of it eliminates SET HOST, network file copies, network task-to-task. Here we make very heavy use of the network for lots of reasons and our users cannot function without NETMBX (you pays your money and takes your changes :-). Well, for SET HOST there is a workaround. Use INSTALL to re-install the RTPAD image. Normally this is installed with just TMPMBX privilege. Remove it and re-install it with (TMPMBX,NETMBX) privileges and your users should once again be able to SET HOST. = Frank J. Nagy "VAX Guru & Wizard" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (01/08/88)
I am attempting to tighten security here at our site. I wish to
remove NETMBX privileges to secure from the hole in DECNET with
respect to MAIL.
This is the second time I've seen almost these exact words, from the same
author, I believe; but I've heard of no "security hole" anywhere else. Are
you talking about the ability to forge who VMS MAIL is from? If so, you are
imposing a rather large inconvenience on users by removing NETMBX for a rather
minor increase in security; I wouldn't want to place bets on mail return
addresses being unforgeable even without NETMBX. (Certainly any security
would only be on the single system - any system that could talk DECnet to
it could lie.)
If this is NOT what you are talking about, could you at least indicate where
you heard of this hole, and give a brief description of what is being compro-
mised? {You needn't, and shouldn't, provide enough detail for others to make
use of the hole, but it should be possible to describe it well enough so that
system managers can determine if it is a problem for them.)
[Removing NETMBX and installing MAIL with NETMBX works, but] is
there a way to remove NETMBX and continue to allow users to SET HOST
or is it wishful thinking?
Try INSTALLing SYS$SYSTEM:RTPAD.EXE with NETMBX; it's the image SET HOST
runs.
-- Jerryhelen@uhccux.UUCP (Helen Rapozo) (01/08/88)
In article <8801070636.AA06723@ucbvax.Berkeley.EDU> JSOTTILE@LOYVAX.BITNET writes: > > >problem remains. We have 2 nodes, GREEN and GREY (don't look at me, I didn't >name them) and we would like our users to be able to SET HOST from node to >node. Both computers share the system disk and UAF files. > > Is there a way to remove NETMBX and continue to allow users to SET HOST >or is it wishful thinking? > If both systems share the same system disk and UAF files then why would one do a SET HOST to another node in the cluster (note: I have no experience with clusters)? In any case you can install SYS$SYSTEM:RTPAD.EXE so that it will have the NETMBX priveledge. It is that image that gets executed when someone does a SET HOST.