Conference noted::hackers_v1

26.0. "Discussion About "Crackers"" by VAXUUM::DYER () Thu Jun 21 1984 04:23

	Here's a discussion I lifted from VORTEX::SYS$NOTES:83ENET.NOT that
involves system "crackers" and their effects, etc.
		<_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

.0 - 28-SEP-1983 20:46 - ABLE::BREWER

	Just wanted to sample DECnet opinion... Since our network is flexible
(therefore vulnerable?) what is the net opinion of the much-publicized group of
students who accessed remote mainframes. From reading the Newsweek article it
is clear given some of the mentioned syntax (set proc/priv...) and other refer-
ences, that VAXen were involved.
	Has anyone encountered malicious/destructive meddling on the net?

	A personal opinion: I think the students should be awarded the public
service award of the year for pointing out to the media thru a (so the media
says) non-destructive exploration of computer vulnerability?

	How many nodes have unchanged SYSTEST/SYSTEM/FIELD passwords?  How many
of us are closet DECnet "hackers"? (another term it seems, that is destined for
immortality courtesy of the media)

	-John
-------------------------------------------------------------------------------
.1 - 29-SEP-1983 07:55 - RAVEN1::BLUEJAY     

Interestingly enough, I've always thought of the TOPS-10 systems as being the
most vulnerable systems, simply because of the variety of things you can do
without actually logging in.  On the other hand, they do have better file pro-
tection schemes (FILDAE, ACCESS.FTS)
-------------------------------------------------------------------------------
.2 - 29-SEP-1983 16:33 - ELUDOM::WINALSKI    

There have been a few incidents of break-ins on the ENET in the past few years.
One involved a hacker (or group of hackers) dialing in on an 800 number to a
customer QAR account on a machine here in ZK.  They discovered another account
on the machine (one with an obvious password) that was not captive.  They used
this account to SET HOST all over the Net.  They didn't get very far with other
VAXen, but they were TOPS wizards.  Almost every TOPS-20 system on the Net was
compromised.  The hackers were unaware that we knew about them and that we had
the account they were using "wired for sound."  We tightened up security behind
them as they broke into machines.  When they stopped finding new holes, we pul-
led the plug on them.

There was another rash of break-ins on RSTS systems.

RSTS and TOPS-10/20 are more vulnerable than VAXen because they keep passwords
in plain text in files.  Break into one privileged account and you can get into
any account.  This is not true of VAXen.

In all these cases, the original break-in was because people were careless
about their account passwords.  This is true of the much-publicized break-in
at LLL, as well.

I DON'T think that the Wisconsin hackers have done anybody a favor.  The media
have blown the incidents all out of proportion, in their usual fashion.
They've been spreading lots of misinformation about computer security (or the
lack of it).  All they've succeeded in doing is frightening and misinforming
the general public.

--PSW
-------------------------------------------------------------------------------
.3 - 29-SEP-1983 18:05 - VAX4::KONING      

Also, certain misguided newspeople, such as some clones at the Wall Street
Journal, have described this as "innocent" whereas in fact these juvenile del-
inquents have caused many of us a great deal of headache, wasted time, and the
like.  There has also been wholesale theft of sources plus some evidence of
meddling with files.
			Paul
-------------------------------------------------------------------------------
.4 - 29-SEP-1983 22:49 - ATFAB::WYMAN       

One aspect of this current excitement that really bothers me is that people are
pointing to problems with the technology and systems as the problem here.  In
reality, from everything I've seen, the 414 kids and others have been taking
advantage of people who use obvious passwords or do other such stupid things.
An analogy would be getting upset with a bank manager who used his home phone
number as the combination to his cash vault.  We certainly wouldn't get upset
with the manufacturer of the vault in such a case.  Nor would we lament the sad
state of technology in the vault business. We would probably suggest that the
twit manager be fired...

		bob wyman
-------------------------------------------------------------------------------
.5 - 29-SEP-1983 21:06 - ABLE::BREWER      

	Agree that the act was not one to be admired. It should, however, serve
to keep managers on the ball. Newsweek etc seem to advertise the fact that any-
one with a Sinclair can access a bank file and make themselves millionaires.
Obviously this is not true, but being a system manager of a 750 and having wor-
ked at a "secure" government installation I find (especially in the case of the
Gov. CRAY/Cyber176 installation) here in New Mexico, that security in some sys-
tems is laughable.  Again, I do not condone the activity of the 414's, but if
some smart kids can access these machines after school, others whose job it is
to do so can do better. 

	I may be paranoid, but given the data we worked with at the Govt ins-
tallation nearby, and the (until recently) proliferation of "guest" accounts on
the net (and the number of TRS-80's...oops  Rainbows being sold throughout the
country) that the media attention, however garbled, is good in the long run for
those of us that have system responsibility.

	-John
-------------------------------------------------------------------------------
.6 - 30-SEP-1983 01:11 - ELUDOM::WINALSKI    

The thing I found most shocking and irritating about the ENET break-ins was the
ho-hum attitude and total lack of help that we (DEC) got from the FBI and phone
company in our efforts to nail the little twerps.  Ma Bell was extremely (in my
mind, criminally) uncooperative in trying to trace the long-distance calls.
These guys were dialled in for HOURS at a time and TPC wasn't able to trace
them, when they finally did try.  The FBI basically stifled a yawn and told us
to go away, they had more important things to do.

I hope the nerds break into NCIC and delete their entire database next time.
Maybe then they'll crack down on these electronic vandals.

--PSW
-------------------------------------------------------------------------------
.7 - 30-SEP-1983 07:09 - BRUTUS::SANDERS     

	What a funny attitude for the FBI, since we and IBM trainned them
	in tracking down computer crime. I wouldn't think that they would
	be so insensitive to something that could have become a major
	problem....Does anybody know the "net-worth" of the data currently
	being stored on our systems?

	When I was doing system management in the Albuquerque Plant, we had
	some RSTS/E systems networked to our Tops-10 system and when I
	turned on the Aux. password, the people that screamed the most was
	the MIS staff. They were ripped that I had impeded their paths and
	even more indiginat when I made them justify the need to know the
	password.

	As to Tops-10 it wasn't until very recently that serval sites even
	started using FILDAE. On of the problems is the tremendous amount
	of overhead it takes.

	(BTW I was working for the MIS programming manager at the time, life
	 was a little tougher then.)

	Bob S.

 (Hi John!)
-------------------------------------------------------------------------------
.8 - 30-SEP-1983 12:06 - REGINA::SPENCE      

I agree with Paul. I also worked on the "great break in" and found it impossi-
ble to get any authority interested in the problem.  Management couldn't take
any downtime to tighten up because of schedule slips, DEC security kept com-
plaining that this was too hard to solve and that their hands were tied. The
phone company wouldn't do anything with out the law requesting it (and DEC
wasn't complaining to the law).

I find the net very usefull, but I find it impossible to police all the users
who continue to protect files "WORLD" (not DEC) READ and I cannot restrict them
from being able to.

	Lynx
-------------------------------------------------------------------------------
.9 - 30-SEP-1983 16:13 - NUHAVN::CANTOR      

Lynx,

You, of course, mean users who UNprotect their files to WORLD READ.

The converse is almost as bad:  Users who UNprotect their directories to WORLD
READ & WRITE and then ask the system manager to delete the files that they
cannot!

Also some users protect their files (notably MAIL.MAI) to SYSTEM no access.

(And then complain that they can't receive mail.)

Should all users be made to go to Commands & Utilities?

Dave
-------------------------------------------------------------------------------
.10 - 30-SEP-1983 17:14 - VAX4::KONING      

Actually, you could scan your system periodically and either delete or repro-
tect files protected wrong.  That should show the turkeys.
-------------------------------------------------------------------------------
.11 - 30-SEP-1983 18:54 - COGITO::KANE        

	Sorry....  I trust hackers more than system managers who
	periodically protect me from myself!  I run across
	very few hackers, but I encounter many system managers.

								-mr. bill
-------------------------------------------------------------------------------
.12 - 1-OCT-1983 19:04 - AURORA::HALLYB      

We all can (with cause) bitch at Ma Bell and the FBI about them being uncooper-
ative.  However, in the past I have detected "suspicious" login failures and
net file accesses to AURORA.  I've run into difficulties tracing down who was
trying to do what, because people like to see the Enet be "open", and there are
system managers on the net who aren't particularly cooperative in supplying in-
formation.  (Such as "who had PID 00120047 last Tuesday at 8:02 AM?).

If we (DEC) can't even get our act together (should we?), then how can we act
so self-righteous?
-------------------------------------------------------------------------------
.13 - 1-OCT-1983 19:35 - ORPHAN::BRETT       

I, for one, occassionally amuse myself by looking at VAX's on the net.  There
hasn't been one I have looked at that I would regard as 'safe' in a university
environment.  Lately some, but only a  few, of the nodes seem to be tightening
up.

Anyone out there want me to try cracking their machine?

/Bevin
-------------------------------------------------------------------------------
.14 - 3-OCT-1983 21:27 - RANI::LEICHTERJ   

Na, Bevin, too easy.  I once found a node out there - which will remain name-
less to protect the guilty - that had its DECnet default account set up with
SYSPRV.  You couldn't log into it without a secondary password, but there are
ways...  (pretty obvious, at that).

(It was fixed REAL quick when I reported it, BTW)
							-- Jerry
-------------------------------------------------------------------------------
.15 - 3-OCT-1983 23:26 - SUPER::MORRIS      

I also found a node that gave the default DECnet account SETPRV, (and SYSPRV,
OPER, CMKRNL, and a few others).  The system manager saw the list of privs
needed to start DECnet and assumed that the default account needed them also.
What's worse is that the account was set up with NETNONPRIV/NONPRIV as the
username/password without any of the standard flags (captive, disuser, etc).
That also got fixed real quick.

There also are lots of systems out there that leave the system SYSUAF.DAT file
protected with world read.  That's a bigger problem then having guest accounts
available.
					Skip
-------------------------------------------------------------------------------
.16 - 4-OCT-1983 10:21 - BELKER::BLESSLEY    

"Break-ins" are the result of curiousity. Curiousity in a company like DEC is
terribly important... can you imagine DEC without curious engineers?  I think
maybe the networking curiousity is misdirected, tho - hardly a day goes by when
I DON'T find login failures on the '730 I manage.  Funny about the comments
about TOPS & RSTS being vulnerable - I'd say 70% of the login failures have
node names beginning with "KL". Somebody across the puddle decided to search
all nodes for *UAF.DAT. Cute.  Drove my blood pressure up 5 when I spotted the
NETSERVER.LOG.

-scott
-------------------------------------------------------------------------------
.17 - 4-OCT-1983 13:45 - VAX4::KONING      

The problem isn't so much DEC people; the problem is outsiders who think it's
quite amusing to steal copies of development sources, or read other people's
mail about new products, or even put Trojan horses into new code being devel-
oped (at least, some have claimed they did, although it appears to be an idle
boast -- but not for lack of opportunity).

That sort of thing is VERY serious.  Almost any action short of turning the
network off outright is appropriate to prevent it.  Certainly comments about
"system managers trying to protect me from myself" are quite irrelevant here.
Many nodes in a network can be hurt by one careless/irresponsible individual
who leaves files containing sensitive information (for example file access
passwords) in command files.  Another aspect is that the amount of information
potentially stolen is reduced when files are correctly protected.

I don't quite understand the point about the SYSUAF file.  Aren't passwords
hashed?
				Paul
-------------------------------------------------------------------------------
.18 - 4-OCT-1983 14:26 - NUHAVN::ANDERSON    

If SYSUAF is protected W:R then anyone can easily obtain a list of privileged
accounts.  This allows them to concentrate on finding passwords for those
accounts without wasting time guessing usernames and breaking into unprivileged
accounts.

	Dave
-------------------------------------------------------------------------------
.19 - 4-OCT-1983 12:40 - NERMAL::THORSTED    

I agree with response # 16.  I don't appreciate spending my time tracing
through 10 layers of nodes trying to track down a login failure to my SYSTEST
account, only to find that it was some "curious" engineer seeing if they could
break into my System for "fun".  I don't mind someone trying to break into my
System, but if you are going to try it, at least be kind enough to send me mail
so that I don't waste my time trying to determine if there was a real attempt
to break in.

/Wayne
-------------------------------------------------------------------------------
.20 - 4-OCT-1983 18:59 - COGITO::KANE        

	Sorry, I stand by my original statement.  You have *NO* right,
	system management or not, to delete one of my files because it
	has the "wrong" protection.

	If you resort to the same tactics as hackers, then to me you are
	one in the same!

	Nor do you have the right to change the protection for me.
	I just might want it protected world read.  What makes you,
	the system manager, a better judge about what is or is not
	confidential?

	Maybe I did make a mistake (quite likely if I'm a new user).
	TALK to me.  Tell me WHY it's not a good idea to have files
	set to world read!  I'm a reasonable person!  I'm *NOT* a
	turkey, luser, or whatever other deragatory expresion you might
	come up with.

	EDUCATION will work wonders.  And it will not take that much of
	your time.

	Then there are the fuzzier things.  Looking for files with
	passwords in them for one.  Yes, I think you have a right to do
	that, since it so damages SYSTEM security.  Delete a file with
	a password in it?  Definately not.  Change the protection on it?
	Yes, UNTIL you TALK to me.  Tell me how much it compromises
	system security.  I'll be very reasonable.  I'll delete it right
	in front of you eyes!

	Finally, stop saying the the "turkeys, lusers" etc.... are
	compromising security!  Most security breaches are caused by
	sloppy SYSTEM MANAGEMENT!  Get *your* act together before doing
	all of the above!!!  Who cares if the sysuaf passwords are
	encrypted?  Why does the file need to be world read???  Name
	me a good reason, and you can leave yours world read.  If you
	can't name a good reason, then why not protect it???

	And why waste your time tracking down a single log fail on a
	privileged account?  Sure, there is *no* excuse for *anyone*
	to attempt to log in over the net to your privileged account.
	The person who did that is a hacker, DEC employee or not!
	But there *are* passwords!  That's what they are there for!
	Half a dozen log fails, a dozen log fails, yes, track it down.
	But you changed the password didn't you?  It's an obscure
	password, many characters.  Your pretty damn safe!

	I'm on both sides of the fence!  I've been a system manager on some
	small VAX'n (750's and 780's).  I've felt my heart sink in my
	chest checking an accounting output and finding a stranger
	from the hinterlands of the network playing with my system,
	and assuming the worst.

	And I'm a user of other VAX'n.  I've done my share of foolish
	things over time.  But I've learned, and will continue to learn.

	Spend the hours you spent tracking down the log fail with
	some of your users.  EDUCATE your users.  It's actually quite
	challenging, although maybe not as much fun as tracking
	down log fails, but it is *much* more beneficial!


								-mr. bill
-------------------------------------------------------------------------------
.21 - 4-OCT-1983 20:04 - DVINCI::GREENFIELD  

	Sys$System:Sys*.Dat SHOULD ALWAYS BE WORLD READ PROTECTED.

	The reason why is as follows:

1) Priviledged accounts can be identified and focused upon for subsequent
   penetration activities.

2) Even though the passwords are hashed, if you have the hashed 
   username/password (which can be easily obtained from sysuaf.dat),
   you can cycle through every password guess, perform the same encryption
   that VMS does, and compare the resulting string.  I am not sure if the
   the password guess must be unique (there may be several passwords that
   will be permitted access?).  For short passwords ( len(password) .le. 5 )
   you can get the passwords pretty quick.  Longer passwords will take a long
   time.  As a matter of fact, we have run such a program on occasion to
   flag users who, against management decrees, select a short password.

	Two lessons here:

1) always protect sys*.dat
2) plead with your users to select good long ( len(password) .ge. 8 ) pass-
words.
-------------------------------------------------------------------------------
.22 - 4-OCT-1983 20:06 - DVINCI::GREENFIELD  

	As Mr. Bill's first System Manager, I can only agree.

 (Never do as I do, just as I say!).
-------------------------------------------------------------------------------
.23 - 5-OCT-1983 07:13 - ALIEN::SZETO       

I use long passwords.  However, on at least one RSX system, I found that its
NFT doesn't take passwords (on the remote node) longer than 6 characters.
Is that generally true of DECnet/RSX?
					-- Simon Szeto
-------------------------------------------------------------------------------
.24 - 5-OCT-1983 14:40 - NUHAVN::CANTOR      

There are some files which, I believe, the system manager DOES have the right
to change the protection on, but which are owned by users.  MAIL.MAI, for
example, must be S:RW minimum for the user to be able to RECEIVE mail.  Also,
the entire directory tree above it must be at least S:E.  Get the idea?

I agree with MrBill's point about system managers not deleting users' files,
though.

Dave
-------------------------------------------------------------------------------
.25 - 5-OCT-1983 17:35 - ELUDOM::WINALSKI    

I would add that a if the system manager changes something about a user's
account (such as the protection of a file, or a UAF quota), said system manager
should tell the user what was changed and why.

--PSW
-------------------------------------------------------------------------------
.26 - 5-OCT-1983 17:50 - BACH::PIERSON     

	It is also too simplistic to assume that one protection scheme is
    the one and only safe or good one.  For example, my default protection
    is W:R (because I sometimes use other UICs, etc).  However, my directories
    are generally protected either W: or W:E - the fact the the files in the
    directories are world readable is pretty much irrelevant...
-------------------------------------------------------------------------------
.27 - 5-OCT-1983 19:22 - SUPER::MORRIS      

It is very relevant (even dangerous) to allow W:R on a file that is inside a
protected directory (ie, W:).  I can copy any file on the system if its protec-
tion is set to W:R no matter how (or even if) any directory it may be in is
protected.  (Isn't PIP great).

If you want to protect your files, then PROTECT EACH FILE.  Don't
make the mistake of assuming that a the directory protects the file.

					Skip
-------------------------------------------------------------------------------
.28 - 6-OCT-1983 09:47 - ORPHAN::LIONEL      

You don't even need PIP - SET FILE/ENTER will do the trick.  I'll double
what Skip Morris said - don't depend on directory protection except to
discourage snooping.

V4 will make security a lot easier with access control lists, so that you
can indicate that a selected set of UICs (or other attributes) are allowed
to use your files, but the "world" (or even the network) isn't.
				Steve
-------------------------------------------------------------------------------
.29 - 7-OCT-1983 14:44 - RAINBO::BRENNER     

I agree with the essence of one of Mr. Bill's points--that explaining to
users the rationale for long passwords, appropriately protected directories,
and so on, would go a long way to heighten security consciousness. This kind
of user training is very unevenly available--when I got this account, I
merely got a form MAIL message telling me I'd been given a vanilla login.com
file (which had default protection set-ups in it, but I didn't know that
until I read the login.com file) and an instruction to change my password
from my first name, which was how it was created, to something longer than
six characters. Now I know the why of these things, but many of my
coworkers do not, and so some still have their first names as passwords.

Moreover, I had to indulge in a little network browsing to find this NOTES
file on VORTEX, because the NETNOTICE file on my node still said it was
on VAX4 or something. This points up a new issue--I am not a malicious
net-walker, I am walking around the net because stuff isn't documented
accurately where I reside and so I have to hunt for it.

The real moral, I think, is that user-awareness education, not to mention
proper documentation of a system, takes a hell of a lot more work than
people realize (forgive me, I'm a tech writer at heart--somebody has to
do the dirty work). Some network browsers are malicious, true, and I do
fear them. But many are like me--I'm just trying to learn. Indeed, this
set of replies will make me refrain from most random directory searches
now that I know some sys. manager somewhere is having heart attacks over
unknown accesses in his log files. But I didn't know that before, and
I'm not at all sure how I would have found out otherwise (except through
a nastygram from said sys. manager, perhaps).

So try telling us first.   /Ellen
-------------------------------------------------------------------------------
.30 - 7-OCT-1983 17:33 - BACH::PIERSON     

	Yes, but browsing is what the default file protection is for!  If some-
    thing *really* needs to be protected then most any default is useless.

	File Id access is great only if you either know what you're looking for
    or are doing serious spying.
						dan
-------------------------------------------------------------------------------
.31 - 11-OCT-1983 23:50 - SUPER::MORRIS      

This might be an appropriate place to report a break-in I found a while back.

I noticed a user on one of our systems had suddenly changed habits.  An editor
for the Ed Services group, she normally never did anything except for running
the Editor, Runoff, and Spell (and NEVER after hours).  I happened to notice
her logged in late at night using compilers and running games.  Turns out it
was her 15 year old son hacking w/o his parents knollege.  (I fixed the twerp,
sent him a letter bomb that generated lots of noise on the terminal and woke
up his parents...he got his hide tanned good).

When talking to him I found that his (and his friends) explorations of the
network had gone a lot further than anyone had thought.  They hadn't been able
to use his mothers account due to long-distance charges.  Instead they had
spent lots of time at night dialing random numbers at the local DEC facility
trying to find numbers that answered with a modem tone.  When one was found
they used a Trash-80 to try the brute-force method of breaking in.  It probably
didn't help that he had access to employee names (newsletter, facility phone
list with node names, etc).  When I noticed him he was set host in from another
system (logged into the "Host" account on the other end...the type that only
lets you set host to other systems in the network).  Mostly what they were
interested in was running games.  I had a talk with his mother and the problem
seemed to go away.  (This kid's burning ambition in life is to come work for
DEC.  I think he was told that he would never get hired if we caught him
"stealing" computer time).  However I'm sure we didn't stop them.  He also
told me about all the other (non-DEC) systems that they had broken into (other
companies, schools, etc).  Quite a list for kids that young.

The point is is that it was very easy for him to gain access to our network.
If instead he had been a person bent on doing damage or stealing confidential
(and knew what he was doing) we wouldn't have had the slightest chance to stop
it.  Even detecting an access like that is difficult.  And I'm not even sure
I know how to go about doing something about it.

						Skip
-------------------------------------------------------------------------------
.32 - 13-OCT-1983 09:06 - RANI::LEICHTERJ   

Sounds very similar to a breakin we had a couple of years back on a RSTS sys-
tem.  For various reasons, everyone on the system ran privileged.  Also, since
the system was stand-alone for years (no network, no dialins) everyone just
left their name as their password.  Then, without anyone thinking about the
consequences, someone installed a dialup.  Shortly thereafter, the son of
the cost center manager came by for a visit.  He was given a non-privileged
account to play with.  He soon discovered the conditions on the system, and
found he could get into a privileged account - mine, in fact!  Well, HE
didn't do much with it, but of course he showed it to a friend, who started
logging in and playing around - mainly games, but a real danger potential.
Our system manager at the time - a part-time job in that group, it got passed
around - found out about the kid pretty quickly, and put in a secondary
password on the dialup line.  Unfortunately, he didn't have the "true hacker's"
mentality; the kids broke it within a day.  There was a running battle for
about 2 weeks before we cut them off...
							-- Jerry
-------------------------------------------------------------------------------
.33 - 28-OCT-1983 12:01 - ELMO::GOUTAL      

Along the lines of Paul Koning's suggestion,
I have had for quite a while a nightly batch job that does,
basically, just two things:
    1.	Purges my entire directory space back to one,
	and then deletes all my FOO, BAR, GAG, TMP, LIS, and OBJ files
	(too keep my disk usage down to what I'm actually using).
    2.	Changes the protection of all my files to WORLD:NONOTHING,
	except for some specifically-named files which I keep
	readable in the interests of network utility,
	like a couple of NOTES files and some dinky tools.
This thing runs *every* *night* on any machine I've had an account on for the
past year and a half.  This is in addition to setting my default protection for
my process to WORLD:NONOTHING.  The point of my nightly cleanup is to reprotect
any files on which I may have loosened security momentarily so that some spe-
cific person might copy it, and then forgot to close it back up again.
-------------------------------------------------------------------------------
.34 - 29-OCT-1983 09:30 - RANI::LEICHTERJ   

A warning (from painful experience):  It is possible to have multiple versions
of MAIL.MAI (if new mail arrives while you are reading mail, or if multiple
messages arrive at once).  A PURGE that got rid of MAIL.MAI;1 would be a disas-
ter!  Fortunately, MAIL creates the file with OWNER:RWE, so the purge will
fail; but there are a lot of accidental ways to give yourself delete access to
your mail file, leaving a ticking time bomb to go off at some indeterminate
time in the future.

(Of course, this can happen with a PURGE you typed by hand just as easily;
but a "background" PURGE that you forget about after a while makes this whole
thing sound scarier.)
							-- Jerry
-------------------------------------------------------------------------------
.35 - 29-OCT-1983 09:34 - RANI::LEICHTERJ   

(The reason it's scarier - I guess this might not be obvious:  Having been
burned, I ALWAYS check for multiple versions before typing PURGE, so that I
know ahead of time what is going to go away.  The easy way to do this is:

		$ DIR ;-1

It's also simple to expand this into a fast command file that will show you
all the versions of multi-version files (other than the first).)
							-- Jerry
-------------------------------------------------------------------------------
.36 - 29-OCT-1983 16:51 - SUPER::MORRIS      

The file protection doesn't help you if you have sysprv privilege.  The
system protection for mail files is RWD.  I lost a mail file by accident
that way.  Now I no longer run with excessive priv's all the time.

						    Skip
-------------------------------------------------------------------------------
.37 - 9-NOV-1983 11:58 - KRIKIT::PORTER      

Eh? Seems to be ambigous terminology here. Is 'world read proected' supposed
to mean 'protected against world read' or 'protected so as to allow
world read'. There are examples of both usages here!
-------------------------------------------------------------------------------
.38 - 9-NOV-1983 12:01 - KRIKIT::PORTER      

Yup. The problem is that the block which you format up for an outgoing connnect
request, using RSX DECnet, has a fixed-length field to hold the password spec.
Limit is 8 chars, which is the maximum size password that RSX-11M (etc) allows
in the system account file. Tough luck about you VAXies, ain't it?
-------------------------------------------------------------------------------
.39 - 18-NOV-1983 10:30 - ORAC::COVERT      

Actually, RSX only allows six characters in the system account file.

But NFT always allows up to eight characters to be specified.

Using more than eight characters probably doesn't enhance security on VMS very
much, since the resulting encrypted password is still only eight, there is
probably some eight character version which will encrypt to the same thing.
-------------------------------------------------------------------------------
.40 - 21-NOV-1983 20:05           R2ME2::ROBERTS     

Back to the sysuaf.dat file being readable by world...a variation is the sys-
uaf.lis file which is created using the LIST command (if i remember correctly).
This file is readable by the world, and offers the potential intruder a list of
accounts - and indicates which are the ones to 'beat upon' - those with privs.

'World readable' - in the days before networked machines, having a file protec-
ted so that it could be read by all, meant that it could be read by 'everyone'.
However, 'everyone' was simply those people who had accounts on the machine in
question, now 'everyone' means everyone on the network.  Shouldn't there be a
seperate protection field for people on the same machine? Thus I could let ev-
eryone on my machine read a file and deny access to everyone on the network.
But what is 'the same machine'? - with VAX Clusters there are several node
names which have access to shared user disks...

Do Access Control lists solve this one?
-------------------------------------------------------------------------------
.41 - 22-NOV-1983 11:13 - ORPHAN::LIONEL      

     Yes, ACL's let you separate network users from local users in regards
to file protections, etc.
					Steve

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-