Conference 7.286::digital

[posted with permission]

From:	HOMBRE::LINDQUIST    "Born in East ZK" 17-JAN-1986 17:41
To:	PRSIS3::DTL
Subj:	Your comments in VMSNOTES

I'm assuming the follow is directed at me.  I didn't think that the
VMSNOTES forum was the appropriate place to discuss this, but I felt
that it did warrent a reply.  I don't think that I fall into category
two, but it doesn't really matter if I do or not, there are things like
ask/tell, phone/dir, ncp, transparent decnet, and whatever network
hacks people dream up to access remote systems.  I'm not a fan of
network browsing/theft, but I think the most intelligent solution is
for system managers to protect their systems.  If VMS doesn't give
them the ability to protect themselves, they should be screaming in
the VMS PHASE0 notes file.  If I leave my car unlocked, and something
is stolen, I think it at least partially my own fault.  If you are
concerned about your system, make the default DECnet account secure,
don't expect EVERYONE to not abuse network access.

	Lee Lindquist

As I told you via mail, my note is against nobody in particular, but refers
to a discussion we had somewhere between Paul S Winalski, Stan Rabinowicz
and someone else I don't remember.

But we are in the same camp, numer #2.

What do you think, readers?

I think the most important thing to keep in mind here is that we all work
for the same company.  The network and the machines on it are *corporate*
resources.  They may be allocated to one particular group for their primary
use, but ultimately their purpose in existing at all is to further the goals
of Digital as a whole.  If one group needs computing resources, and another
group has those resources to spare, it is sheer foolishness to let
organizational and turf boundaries prevent the sharing of the resource.

On the other hand, toys like TELL.COM can get out of hand.  My own cluster
(the TLE cluster) is a case in point.  We have a severe problem a while back
with looping TELL.COM network tasks bringing our systems to their knees.
I traced at least one of these to the door of our august friend Didier (:-).
Because these things are unreliable and have had a history of causing problems,
our cluster has disabled their use.

I am all in favor of open and free network access, but when there is a history
of abuse, I'm also in favor of shutting down the offending utilities.

--PSW

I don't know about you, but our cost center has a history of unceasing breakins
to our systems.  We just went through a complete password change last week.
The last thing we need is randoms using resources without permission.  If
you do it while you are working from home, you might find the FBI knocking
on your front door.

Also, while DEC's security policy states that no restricted distribution
company confidential documents be kept on systems connected to networks or
the phone system, I'd have to say that is a farce.  I assume there are documents
on every group's systems that are restricted distribution; facts that are
to be disclosed internally on a "need-to-know" basis.  We couldn't work
effectively, otherwise, since systems need to be on the E-net to be effective,
and computers have to be used for document preparation to make us effective.
I do not believe that random E-net inhabitants have the right to grovel around
on other groups systems and examine such data.  The data should be protected
by the authors, but they also have the right to expect that other employees
won't use "security holes" (and that's what we are talking about here) to
try and access them.

Furthermore, allocation of machine resources is not the right nor responsibility
of random occupants on the network.  My management has to pay millions of
dollars a year for floor space, support services and so on.  And we still
have unfulfilled machine requirements of our own.  (Hell, it costs hundreds
of thousands just for the managers who allocate the resources).

That money could be used for other things (for instance, paying the salaries of
4 of my co-workers whose projects dried up this summer and had to be
"out-placed" into other projects miles away).  If some other group is starved
for machine time, then perhaps they should pay some transfer costs before
they claim a right to what we have paid for in budget and lost bodies.

I do agree that it would be foolish and restrictive to take this too far.
I certainly read (and write in) enough notes files.  My comments take up
space and runtime on other groups systems.  We might even have less than
the usual number of at our site, so perhaps we are getting a free ride compared
to the rest of the network community.  (Though one might assert that we don't
do anything in my cost center that people want to know about).


To be more specific, as far as I am concerned, "batch runtime"
is not a resource that people from other sites are entitled to use without
permission on the systems I am responsible for.  And I am sure that my
management would agree.  If anyone else has runtime to spare, perhaps they
should advertise it so that others can take advantage of it.
				/AHM
P. S.  I'll revisit this question if I ever get a uVAX for us all to use.  Ha.

(An example of the kind of resource sharing that we have been successful
at is the guest accounts that certain projects in MR and ZK have shared with
each other over the years.  When it's time to get access to a library, convert
a test system, or just help a parallel group with questions, I think we have
both aided each other.  And respected each other's resources, too.  I've
never heard anyone say "let's log in to SPIT20 and compute pi").
				/AHM

If you feel you need resources that are not directly available to you,
why not ask rather than taking (or trying to take) them?

A group in need of some compute time recently sent out a mail message
to some (all?) system managers on the net asking for whatever time they
might be able to provide.  Given the resources, I'd be much more inclined
to cooperate with this group than with someone who attempted to "help
themselves."

	- Jerry

RE: .4 ff

Agreed that the restricted distribution policy is a farce.  If it were up
to me, I would ammend the policy to state that restricted distribution
documents may be kept on-line, but must be stored encrypted except when
actually being worked on.

Computer files stored on the net should be treated like employee's desks.
It is not acceptable behavior to enter somebody's office without permission
and browse through the documents on his desk.  [At ZK, this will get you
fired.]  Neither is it acceptable to browse through somebody's computer
files without permission.

As for allocation of machine resources, if one is not using all of the
time on one's machines, such that there are cycles left over that others
could use without impacting the primary work on the machine, then I have
two observations:

1)  Why should you care if somebody else is using the resources, if it's
    not impacting your work?

2)  Maybe you have too many computing resources in the first place.

In either case, I see no reason not to share your largesse with the rest
of the company.  Management bean-counting is not an issue here.  The money
that "buys" machines and floor space is funny money.  If your cost center
has extra compute resources lying around that your group really doesn't need,
then your manager is wasting the funny money, whether others are using the
resources or not.  From a company-wide standpoint, it is utter foolishness
not to let others use the resources.

Now, I agree totally that outsiders must NOT just submit batch jobs remotely
to other systems without asking permission first!!  An outsider cannot tell
whether there really are available resources without asking the system
manager.

However, such resources should readily and freely be made available to others
where and when they exist.

--PSW

Re .-1:

Perhaps your group has different funding and accounting procedures.  In our
cost center, a dollar in the budget can be spent for computing resources,
or for human resources (salaries).  (Or dancing girls, but that component
of our budget is greatly reduced this year).

We have a need for more computing resources (particularly VMS computes, as
people shift onto projects that use Vaxen instead of KLs).  If we had to
acquire another system to handle a computing load artificially inflated by
externally imposed batch jobs, there might well be more people let go.


I am glad that there is more than one thread running through this discussion
relevant to "the way we work at Digital" than just network etiquette.  We
wouldn't want to go out on a tangent unrelated to this file.
				/AHM

What happened to the original question: Should TELL be Allowed?

I have used TELL in good faith to try and determine why I can't copy a file
one of you kind people in a NOTES file told me I could have. I didn't think
TELL was capable of stealing system resources (unless it starts looping as
has been mentioned.

I always have seen TELL as nothing more that a very limited terminal connect
to a system through the DECNET account. DECNET accounts should have very
restricted privs any way.

What I find interesting is the amount of documentation that is floating around
the DECNET directory. Someone wants to use the LN03 on your system... after
all you are in the next office, and does:

$ copy file.lis system::tti0

Notice there is no ":" after tti0. The confidential document winds up in
the DECNET account as tti0. and anyone can copy it.

Ramble ramble...

	Mike

As has happened in every discussion I've ever seen of this issue, a number of
unrelated issues have gotten mixed together.  In addition, several falsehoods
get repeated.

First:  TASK access has NO EFFECT WHATSOEVER on file security.  Anything
acces- sible by this mechanism is equally accessible using remote file access.
In fact, the same thing applies to just about any notion of "security" you can
name, with the exception of "free CPU time", which I'll come back to.  The
common kinds of arguments - that it lets hackers find lists of valid accounts,
for example - don't wash, since there are equivalent methods of doing the same
thing WITHOUT TASK (like PHONE DIR).

There are two real issues involved here:  One of perception - to a manager it
may FEEL as if the system is somehow "more used" via TASK than via something
like FAL; and that old story, the remotely-submitted number cruncher.  The
first of these needs to be dealt with by education and an appropriate
corporate policy.  The second CAN be a real issue, but in practice it is not.
Unlike some others, I do NOT claim the right to use any random VAX on the net
as a compute engine - any more than I claim the right to walk into any empty
office and make use of the terminal in there, or the phone.  A policy that
said "Get permission before using others' systems" makes a lot of sense.  IT
IS ALSO EASILY ENFORCEABLE.  Any remote submission, or use of the TASK object,
leaves tracks behind.  It is no problem to find the person and talk to them -
or their managers.  Violations are not going to be common - especially if
violaters are seen to be dealt with appropriately.  And before you say, "Am I,
as system manager, supposed to check for such jobs", my answer is, "Of
course!".  When I've run systems, I've made it my business to know who uses
them, when, and with what kind of usage pattern.  That's the ONLY way to spot
the REAL hackers - or to really understand what is going on on your system.
Besides, it's not that hard to do.

VMS also contains mechanisms to help enforce this policy.  For example, you
could set up object 0 to use some account other than DECNET - say, DECNET0.
DECNET0 would have the same UIC as DECNET, and in fact would be identical to
it in all respects - except that it would have a CPU time limit of, say, 3
minutes.  That would make it totally useless to anyone who wanted to use the
machine as a "compute server".  (Other parameters - like the priority - could
also be changed, if that seemed desireable.)

Finally, let me give an example of something that I have done with TASK object
that just cannot be done easily without it:  Suppose I want to copy a large
number of files from a remote directory.  BACKUP is the most efficient tool
for the job, but it cannot takes its input files cross-net.  So the best
approach is to run BACKUP, producing a (remote) saveset back on MY system,
from the system where the files are.

Now, have I "stolen time" from your machine?  NO!  I've simply run BACKUP
instead of FAL, which would have run if I had used COPY.  In fact, it will
almost always be the case that the total resources I use on your machine using
this approach are significantly LESS than a COPY would have used.  In fact,
the resources used on MY machine, and on the net itself, are ALSO less.  So
EVERYONE - me, my cost center, your cost center, and DEC - wins.

And to repeat one more time:  I could only do that because the files were
accessible to the DECNET account.  YOU made them publically accessible, or
my BACKUP would have failed - in exactly the same way as a COPY would have
failed.
							-- Jerry

1. if noone is logged in, the PHONE utility is useless

2. the root note discusses about TELL and not the TASK network object

3. TELL allows anyone to LOG IN a system, under an ACCOUNT, and becomes
   a regular USER of the system, without permission of the system manager
   (except if s/he is ok to have TELL on the system, of course)
You can do all DCL commands, run tasks, type the sys$sylogin file if not
protected W:E, do SHOW LOGICALS, search for access control lists in DCL
command procedures (non)protected W:R, etc..

So my conclusion is still this: TELL is a security risk.

RE: .8

OK.  Your group is short on compute resources.  In that case, if somebody
asked if they could run remote batch on your systems, you would rightly say
no and that would be that.

There are other groups in the corporation with spare compute resources.
What I'm saying is that such groups should allow others (like yourself)
who are strapped for compute resources to use their excess.  The fact that
group A paid its funny money for the computes it's not fully using shouldn't
prevent group B from making use of those resources.

RE: .11

You don't need TELL.COM to do this.  Merely defining the TASK object allows
anybody to do this.

--PSW

re .11 and general:

A system that would be compromised by TELL.COM doesn't have a very good system
manager, period. 

- M

A Bank security that would be compromised by an open door at night doesn't have
a very good security manager. Period.

Period? Sure not. If I were the bank security mgr, I would have locked the
damned door. 
  
:-)

Just as there is value to opening the front door of the bank (to do business),
there is value to the TASK object.   If you as a bank security manager can't
figure out how to keep people from wandering into the vault (by closing the
VAULT door, rather than the front door) while doing normal business... well...
see .14.

Just as banks are built with security features other than the lock on the
front door, so is VMS.  

- M

One doesn't need TELL to submit jobs on another system, just use SUBMIT/REMOTE.

The most common uses of TELL are for things that are reasonable but that can't
be done without a "local" command.  For example, printing something with a
specified form or printing a group of files as a single job.  It seems unlikely
to improve security to give accounts to a large number of users simply to
allow them to issue print commands, nor is this a particularly good use of
resources to use time to setup the accounts or deny access simply becuase the
idle printer on one system isn't being paid for by another group.  How many
groups actually need printers, especially LN01s, on a full time basis.

Furthermore, I find it more convenient to use TELL even when I do have an
account of the target system.  With TELL, I'm logging in by proxy which is
far less effort on my part, especially if I need to access both systems at
the same time.

I think that this is a good example of a problem where the expected response
is "do what's right".  What's right is to make resources available to people
on the assumption that they will use them properly; if this proves not to be
the case, then address the situation with as specific a remedy as possible.

One of the more frustrating things I see are the people who need access to
resources which their group has but is unwilling to give them access, but that
I have no problem in granting them access to the equivalent or greater resources
on my system.  A particularly good example is privileges.