[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

411.0. "No SYSUAF.DAT ??" by WHOARU::MCCARTHY (Just another colorful metaphor) Fri Feb 20 1987 15:58

    	I was asked a question the other day that go me thinking.  If
    SYSUAF.DAT was "gone" or was replaced by a phoney version with only
    a few accounts, what would happen?
    
	I did not know the answer.  If a SYSUAF.DAT exists with only
    two entries, that means that only two people have accounts and can
    access the system (right???).  All other attempts of former accounts
    (in the case of replacment of SYSUAF) to log in would not exist in the
    eyes of LOGINOUT.  I thought that maybe there was a DEC back door into
    all VMS systems but that would blow the idea of a secure system
    out of the water.
    
    	Any comments thoughts?????  My answer was that the system would
    have be taken down and brought back up using a different system
    disk????  No one could log in if no SYSUAF.DAT existed.
    
    mac
T.RTitleUserPersonal
Name
DateLines
411.1SYSUAF accessMOTHRA::DUTKONestor Dutko, VMS/VAXclusters CSSEFri Feb 20 1987 16:3517
    If a SYSUAF is found and it is in tack (no file corruption), the
    file will be used for ALL user authorization checks upon login/process
    creation.
    
    Should the file not be found, either through a logical name
    redefinition of SYSUAF to a bogus or non-existent file, or the file
    just not existing, only one terminal may be logged into.  That terminal
    is the system console, and the account is SYSTEM.
    
    Now, you can also use the SYSGEN parameter UAFALTERNATE to try and
    specify an SYSUAFALT file to be used to restrict usage when you
    are doing something strange.
    
    Make sense?  As always, the weakest link in system security is the
    console subsystem.  Once you get to it, breaking in is a snap.
    
    -- Nestor
411.2I thought it wasn't just SYSTEM thoughFROST::HARRIMANAnnouncements..Art..It's Only TalkFri Feb 20 1987 20:0114
>    Make sense?  As always, the weakest link in system security is the
>    console subsystem.  Once you get to it, breaking in is a snap.
    
    Sure, that's why you put locks on your doors. That's why physical
    security is supposedly so important. 
    
    BTW, I thought that if SYSUAF and SYSUAFALT weren't found it just
    logged onto OPA0: using any username, not just SYSTEM, and it
    gave you all privileges. Maybe I wasn't reading the LOGINOUT source
    correctly...? (calls it an "emergency login")...
    
    /pjh
    

411.3SYSTEM is created.MONSTR::DUTKONestor Dutko, VMS/VAXclusters CSSESat Feb 21 1987 14:162
    You are right...  It does log you in using any username and password,
    however the user account created is SYSTEM.
411.4Say that one more time...GENRAL::RINESMITHRoger's Opinion stated belowSat Feb 21 1987 14:486
    Point me to what you mean by the weakest link in system security
    is the console subsystem.  I assume you mean that someone could
    take down the system and then reboot using an alternate login or
    are you saying that anyone who has access to the console can just
    "LOGIN" ?
    
411.5MOTHRA::DUTKONestor Dutko, VMS/VAXclusters CSSESat Feb 21 1987 23:074
    You can just login, however, if the SYSUAF is in tact, you may only
    login to a valid account.
    
    
411.6PASTIS::MONAHANSun Feb 22 1987 15:019
    	Anyone who has physical access to your console has full control
    of your system. Whether he can use this without being noticed is
    another matter, since he may have to reboot the system or at least
    temporarily halt it to use his power.
    
    	Bearing this in mind, it is intentional that you should be able
    to log in to a privileged account from the console if the SYSUAF
    is corrupted, since it may provide a faster recovery from a minor
    user error than a complete restore from backup of the system disk.
411.7Console tricksCAFEIN::PFAUYou can't get there from hereMon Feb 23 1987 01:2713
    If SYSUAF.DAT is not found or is corrupted, anyone can log in at
    the console under any username with any password.  No one will be
    able to log in anywhere else.  The created process will have all
    privileges.
    
    Even without removing SYSUAF.DAT, one could reboot the system with
    a conversational boot and redirect the startup file to the console
    (SYSBOOT> SET/STARTUP OPA0:).  This will have the effect of giving
    the person a fully privileged process.
    
    Make sure your console terminal is ALWAYS secured.
    
    tom_p
411.8MKTUP1::EIBENMon Feb 23 1987 16:0720
    .. when I finally a couple of years ago got a little bit 'deeper'
    into VMS [having a 'workstation' at Your desk is a phantastic learning
    tool] I was concerned about that too.... [and still am..]
    
    1. How do You 'secure' a Console terminal ?? ye olde saying still
    holds true - that operators will disclose/allow anything for a case
    of beer.
    
    2. How do You 'secure' a Console terminal of a 'work-station' ??
    
    I sure didn't appreciate one night long time ago - having to scrounge
    [long after midnite] for another 'system-pack' - since MARKET {still
    running TOPS-20} lost against an intruder making use of a too trusting
    operator - but I sure enough felt pretty safe, knowing that operators
    {as any human being could make errors} - but could hardly circumvent
    security fences - AND DEFINITELY NOT using the CONSOLE TERMINAL.
    
    Rgds,
    Bernie.
    
411.9rotsa ruckCAFEIN::PFAUYou can't get there from hereMon Feb 23 1987 20:0410
411.10HumorTLE::RMEYERSRandy MeyersMon Feb 23 1987 21:324
Re: .8
> ... MARKET {still running TOPS-20} ....

I heard they once tried to run VMS, but the KL wouldn't boot.
411.11Maybe a case to learn from ??MKTUP1::EIBENMon Feb 23 1987 22:1113
    MARKET is {to my knowledge} the only system in this corporation,
    which is on both E-net and ARPA-net and also tolerates {with
    practically no supervision} PUBLIC LOGIN via LCG.KERMIT password
    KERMIT - sure we had our share of problems - but {knock on wood}
    MARKET was {and is tried} very often for 'break-ins' - not-so-much
    'cause of E-net linkage but more ARPA-net access - and its being
    secure for the last three years.
    
    Btw TOPS has no 'security' rating but University proven security
    
    Rgds,
    Bernie - for about 15 years involved with TOPS - its history ...
    
411.12PASTIS::MONAHANTue Feb 24 1987 07:597
    	If you give me half a minute's free time at your microvax console
    I can walk away with your RD53 in my brief case. This is actually
    a quicker and easier way of stealing your data than going through
    a messy and complicated reboot sequence to get privileges.
    
    	I expect the operator on MARKET could have done a similar thing
    (if he had a large enough brief case :-).
411.13GENRAL::RINESMITHRoger's Opinion stated belowTue Feb 24 1987 12:533
    RE: .12
    		So your the one...   No wonder I could't get my
    microvax to boot.  
411.14was it a joke or was/is it true...???PUZZLE::JOSEPHLet your spirits soar...Tue Feb 24 1987 18:248
    I was told at one time , if you do NOT have a SYSUAF.DAT you then
    have an open system.
    
    Was that ever true ??? If yes, is it still true??
    
    Regars,
    
    	Bob.
411.15Did you read previous replies?CAFEIN::PFAUYou can't get there from hereTue Feb 24 1987 20:228
    If LOGINOUT can't find SYSUAF.DAT or finds it corrupted (that is,
    unreadable), ANYONE can log in AT THE CONSOLE TERMINAL with ANY
    USERNAME and ANY PASSWORD.  No one will be able to log in at any other
    port even if they enter a valid username and password (how can LOGINOUT
    determine if it's valid if it can't read SYSUAF.DAT?).  The account
    created at the console terminal will have ALL privileges. 
    
    tom_p
411.16I think I heard what you askedFROST::HARRIMANAnnouncements..Art..It's Only TalkTue Feb 24 1987 20:5910
    re: .-2
    
    What I believe I heard you ask was "was it ever that way". As far
    as I know, it never was. VMS V1 was pretty simpleminded compared
    to V4, etc, besides, the sources don't say - I suspect that VMS
    has performed like this for a long long time, and whoever told you
    that never tried it themselves.
    
    /pjh
    
411.17MKTUP1::EIBENTue Feb 24 1987 22:4016
    I'm NOT really concerned about the mVAX cluster I'm "managing" --
    
    1. Its {only} in MARKETING [only kidding ..]
    2. I don't put anything on it , I would put VALUE on [not so straight
       copy of a saying of Richard Stallman - author of EMACS and GNU,
       who had an account on MIT-ITS with name RMS - password RMS.
    
    I'm only slightly concerned {as a technical 'marketeer'} about us
    trying to get into 'big Blue' land with this type of attitudes
    regarding 'security'....
    
    Rgds,
    Bernie - who just found out, that nearly ANY failure regarding the
    	LOGIN-tree will let You in still as SYSTEM... a nice 'feature'
    	for 'hackers' ... and an 'open door' for invaders.
    
411.18what would you do?37935::ZARLENGABigger they are, Harder they hitThu Feb 26 1987 18:549
    Bernie,

        What would you suggest the system should do if confronted with
    a "corrupted" SYSUAF.DAT?
    
    	Any alternative I can think of (individual "backup passwords"
    inscribed inside the cabinet, etc) is still subject to tampering.
    
    -mike z
411.19Showing my RSTS/E ancesctryMAY20::MINOWI need a vacationThu Feb 26 1987 23:258
>        What would you suggest the system should do if confronted with
>    a "corrupted" SYSUAF.DAT?

Take the system down and boot another system (from disk or magtape),
then create/recreate SYSUAF.DAT.  Or, is this impractical on VMS?

Martin.

411.20no answers, only questions38007::ZARLENGABigger they are, Harder they hitSun Mar 01 1987 19:4916
    	Not impractical if it's a VAX in a computer lab environment
    where backups are handy.  But if it's at home you may be stuck
    for quite awhile.
    
    	The point is, that if someone has access to the computer
    hardware (ie console, cabinet, front panel, etc) then with
    the right knowledge, they have complete access to the whole
    system.
    
    	Now, if you are going to protect the "system", you should
    consider the console terminal a part of that system that must
    be protected, just as the computer's front panel is (where
    a HLT, MEM EXA, MEM DEP, RUN can also and with much less of
    a trail).
    
	-mike
411.21New CBOOT system parameterBARNA::SOLEPONTMon Mar 02 1987 17:0311
    What about a new system parameter called CBOOT_ENABLED ?

	If CBOOT_ENABLED = 1 then SYSBOOT should act as usual.
	If CBOOT_ENABLED = 0 then SYSBOOT should prevent CONVERSATIONAL 
				bootstrap (bypassing R5 contents).

    At least, this should protect 90% of (actual remaining) security holes
    and it is very easy to implement because SYSBOOT reads VAXVMSSYS.PAR
    just before checking if must enter in conversational mode.

    *Jaume	
411.22What about emergencies then?FROST::HARRIMANbicker,bicker,bickerMon Mar 02 1987 18:577
    re: .-1
    
        Then what do you do when SYS.EXE or something like that gets corrupted,
    or worse, your page or swap file, and you GOTTA do a conversational
    boot, and the system won't let you?
    
    /pjh
411.23Coming soon to a disk near youSQM::HALLYBAre all the good ones taken?Mon Mar 02 1987 21:1213
.21>    What about a new system parameter called CBOOT_ENABLED ?
.21>
.21>	If CBOOT_ENABLED = 1 then SYSBOOT should act as usual.
.21>	If CBOOT_ENABLED = 0 then SYSBOOT should prevent CONVERSATIONAL 
.21>				bootstrap (bypassing R5 contents).

    With Local Area VAXClusters there is in fact a SYSGEN parameter
    that does just that.  No conversational boot allowed.
    
    If you're paranoid about a corrupted SYS.EXE I suppose you could always
    have a backup version on another system root.  Just be sure to check IT...

      John
411.24Don't use if you don't like itBARNA::SOLEPONTTue Mar 03 1987 06:1312
    re: .22

	Emergencies can be solved with the remaining 10% of security hole.
	Plugging another system disk, bootstrapping alternate system roots
	or equivalent actions, wich in fact are more detectable/control-
	lable than just few console commands.

    comment: .23

	Alternate system roots should use CBOOT_ENABLED = 0 too!

    *Jaume
411.25Too easyULTRA::CRANEOlorin I was in the West that is forgotten...Tue Mar 03 1987 12:277
Anyone with access to the console has complete control of the system. Just
login on your nonprivileged account, halt the processor, poke a few locations,
start it running again, and you're logged-in with all privileges.

Hack, hack, hack,

Ron 
411.26exactly!37934::ZARLENGABigger they are, Harder they hitTue Mar 03 1987 12:528
    re .25, That's what I was trying to say in .20
    
>    consider the console terminal a part of that system that must
>    be protected, just as the computer's front panel is (where
>    a HLT, MEM EXA, MEM DEP, RUN can also and with much less of
>    a trail).

411.27PASTIS::MONAHANTue Mar 03 1987 14:585
    	I think 7ffda800 is the location to try, but I do not have a
    stand-alone machine to check. Let me run TELL.COM on your machine,
    and give me 10 seconds on your console terminal, and I will confirm
    it.
    	(or crash your system :-}  )
411.28Not so easy!BARNA::SOLEPONTTue Mar 03 1987 17:0715
.25>                             -< Too easy >-
.25> Anyone with access to the console has complete control of the system. Just
.25> login on your nonprivileged account, halt the processor, poke a few ...


			    -> Not so fast, Ron... <-

	When I was system mangler I had a system wide login procedure that
	nicely dropped out users without OPER privilege from _OPA0:

    *JAUME

	(But _YES_, I am agree that if anyone has access to the console,
	 sooner or later will hack everything [or crash it :-)] )
411.29yes, its too easy (when you know how)PASTIS::MONAHANTue Mar 03 1987 19:257
    	The job one logs in on need have nothing to do with OPA0. The
    one location poke gives the *current* job, that is, the one that
    is actually using CPU time, full privileges. It can even be a batch
    job.
    
    	Dave
    
411.30ULTRA::CRANEOlorin I was in the West that is forgotten...Wed Mar 04 1987 13:575
Well, it's not that hard to find the PCB of the right process (via the PCB
vector), and then the PHD, via PCB$L_PHD, and then to poke the
PHD$Q_PRIVMSK... 

Ron
411.31re: .30 ... i don't think soTOLEDO::VENNERWed Mar 04 1987 18:4614
    re: .30
    
    if i remember things correctly from the VMS internals class, all
    of the PCBs are in system space so you can get to them, but the
    address of the PHD which is found in the PCB is a virtual address
    and can only be resolved when you are the current process.
    
    so you can't just halt the system and pop values into anyone's
    PRIVMSK, only the PRIVMSK of the current process.  can anyone
    more knowledgeable back me up on this?
    
    - marty
     
411.32CAFEIN::PFAUYou can't get there from hereWed Mar 04 1987 22:236
    Both are in system space so both should be addressable.  The problem
    is that the process header is located in paged pool and the address
    you try to poke may equate to a page that is not in physical memory.
    Since the machine has been halted, it won't be faulted in.
    
    tom_p
411.33MONSTR::DUTKONestor Dutko, VMS/VAXclusters CSSEThu Mar 05 1987 01:4813
    RE:.-1
    
    That is not as much of an issue as assuming that the process which
    you are mucking around with is your current process.  Your process
    may be in some nebulous wait state (LEF) and you just elevated someone
    elses priv's.
    
    The Virtual address within the PCB$L_PHD is the virtual address
    of teh PHD. You should be able to muck with it, given that nothing
    happens with you (like you get swapped out).  In that case, the
    number will be low.
    
    -- Nestor
411.34PHD always availableWINERY::MILLERFri Mar 06 1987 21:475
    Also, the fixed portion of the PHD is never paged, and is only swapped
    when the whole process has been swapped out already.  The PHD's
    are in the Balance Slot part of system virtual address space.  E/V
    (examine/virtual) also works quite well on the console.
    
411.35SYRAH::THOMASThe Code WarriorMon Mar 09 1987 00:042
    Why do it the hard way?  D/V/W 80003D00 FFFF
    (See description of MAXSYSGROUP)
411.36PASTIS::MONAHANMon Mar 09 1987 18:5610
    re: .35    I like that one!  I hadn't thought of that.
    
    	I was going to try patching out one of the protection checks
    in XQP. (Its all shared code, so it shouldn't matter which process
    you hit). Now you have spoilt my fun by making it too easy.
    
    	Anyone still like to claim that their system is 90% safe if
    a hacker can get near the console    :-)
    
    		Dave
411.37What do you consider NEAR?CAFEIN::PFAUYou can't get there from hereTue Mar 10 1987 00:073
    Near?  No problem.
    
    tom_p
411.38Console with no keyboardGENRAL::RINESMITHWed Mar 11 1987 16:461
    On an 8200-8300 a DECprinter III makes a pretty secure console.
411.39PASTIS::MONAHANWed Mar 11 1987 18:536
    	Don't forget the Field Service hand-held terminals. If I can
    carry out an RD53 in a brief case, I can carry in a terminal in
    a coat pocket!
    
    	It depends to some extent on how much ingenuity, preparation,
    knowlege (and money) you are trying to protect against.
411.40you MUST protect the hardware!37934::ZARLENGABigger they are, Harder they hitWed Mar 11 1987 19:5010
    	EXACTLY! If you let someone "touch" the "system", there
    is a very good chance that that person, given the right
    knowledge and equipment, will be able to break in.  In many
    cases, undetected.
    
    	I believe this is independent of the computer and operating
    system.  Does anyone know of a "physically secure" computer (ie
    one that needs no additional barriers to be secure) ?? I don't.
    
    -mike
411.41Physical security costs money...VIKING::WASSERJohn A. WasserThu Mar 12 1987 15:0315
> Does anyone know of a "physically secure" computer (ie one that needs no 
> additional barriers to be secure) ??

	The IBM-PC/AT comes with a key switch that disables keyboard
	input.  Unfortunately you can take the top cover off the
	machine fairly easily.  If they had designed the sytem so that
	the top cover was locked when the keyboard was disabled, they
	would have a much more physically secure system.

	You can build a physically secure system easily enough... you
	just have to find someone willing to pay for the security.
	Since most mainframes are kept behind locked doors, most
	customers wouldn't want to pay extra for a system with its
	own physical security.

411.42VIDEO::LEICHTERJJerry LeichterSat Mar 14 1987 14:3514
411.43the name for 8003d00 is exe$gl_SYSUICSNO78A::BRAHAMPete BrahamMon Mar 16 1987 21:533
    Re .35 (D/V/W 8003D00 FFFF) 8003D00 is EXE$GL_SYSUIC of course in
    SYS.MAP 
    
411.44CASEE::COWANKen CowanSun Mar 22 1987 14:5410
    I don't expect to be to secure my system without resorting to
    physical security.  All of the security holes mentioned so
    far rely on failed physical security.
    
    BTW, I remember hearing stories that the best way to 'break in'
    to a system was to observe the patterns of the humans in the 
    system.  People were always the weakest link.
    
    	KC
411.45why use offsets ? Hit it straight !PILOU::BONGARTZHappy HackerMon Mar 23 1987 11:2633
     
    
    	Why make it complicated ? using a simple loop in dcl, you get
    	a reasonable good chance that your non-privileged process is
        the current one, thus you can just come along and poke a  -1
        to ctl$gq_procpriv ... provided you're on the console...
    
    $ examine/hex/long 7ffeff10:7ffeff14    ! check your current privs
    7FFEFF10: 00108000 00000000             ! (just to have the value)
    $ cre x.com                             ! create a dcl loop
    $loop:
    $ goto loop
    ^Z
    $ @x                                    ! kick it off...
    ^P                                      ! get to the kernel
    >>> H
    >>> E/V/L 7FFEFF10                      ! check our privs,
            P xxxxxxxx 00108000             ! if not same do a
    >>> E                                   ! few Cont/Halt 'till
            P xxxxxxxx 00000000             ! we hit them
    >>> E P
              00000009                      ! check current PSL
    >>> D P 41F0000                         ! kernel mode,IPL 31
    >>> D/V/L 7FFEFF10 FFFFFFFF             ! (so we can write to
    >>> D/V/L 7FFEFF14 FFFFFFFF             ! ctl$gq_procpriv)
    >>> D P 00000009                        ! restore psl (!!)
    >>> C                                   ! and continue...
    ^Y                                      ! bail out of command file
    $                                       ! and enjoy your privs ...
                                                                      
    
                                                          
    
411.46problem making sure it's youVIDEO::OSMANEric, dtn 223-6664, weight 146Mon Mar 23 1987 16:4113
re: That little bit about "see if privs match, otherwise do a few
CONTINUE/HALTs until they do".

	This seems like a very inaccurate way to make sure you're
	the current process.  Probably your privs are the same as
	most other people, so you'll often see the right privs even
	though you might not really have the correct process yet,
	right ?

	Perhaps better to check some cell that contains your pid
	or your terminal name.

/Eric
411.47PASTIS::MONAHANMon Mar 23 1987 19:5135
   	If you are compute bound (and most other users are not) then
    there is a high probability that you will get your own process.
    If you do not, then just try again. If you are really a hacker,
    you probably do not care how many processes you make privileged
    before you get your own - the other users will never notice, and
    even if they do, so what??  "Its a VMS bug, my process suddenly
    became privileged".
    
    	It may be inaccurate, but who the hacker cares?
    
    	What is rather more interesting is what to do when you do not
    have control of any process. In this case, there is no process you
    own for which you can elevate the privileges. I would suggest a
    technique like the following :-
    
    1) All halts must be short so you do not hit a time out in a LAVc,
    so first find a LRP and detach it from its list. Then continue.
    
    2) A little at a time, deposit into this LRP the code to create
    a process that is fully privileged, and with its SYS$COMMAND the
    console terminal. Detaching the LRP must be done as a single operation
    within the time-out periods, but now you need only do a single deposit
    at a time if you wish between restarting the processor.
    
    3) Finally patch a jump to your code into the swapper process, and
    wait for the console terminal to become "live".
    
    
    	I would be interested to know if any hacker has actually done
    this. It sounds tedious, but should only take a couple of minutes
    if well prepared. The technique, of course, is what VMS uses to
    create the initial STARTUP process, so it is probably even supported
    :-)   :-)
    
    		Dave
411.48VIDEO::OSMANEric, dtn 223-6664, weight 146Tue Mar 24 1987 17:1427
Re:>    If you are compute bound (and most other users are not) then
>    there is a high probability that you will get your own process.
>    If you do not, then just try again. If you are really a hacker,
>    you probably do not care how many processes you make privileged
>    before you get your own - the other users will never notice, and

   My point is, you certainly care whether or not you've managed
    to make your own process privileged, so checking the privilege
    word to see if its yours seems like a bad way to do that, since
    most processes will have the same privs as yours.
    
    As far as "high probability", no, your're wrong.  If at least
    one other person is running a compute-bound job, you'll have
    a good chance of hitting their job, not yours.
    
    However, I like your basic method, and I've squirreled it away.
    Every once in a while I run into a really frustrating situation
    where I know EXACTLY how to change what I need on a system, but
    its the middle of the night, and I don't have privileges, and
    the system manager is home sleeping.  I just KNOW that he'd
    gladly grant my request if he were here.
    
    He's not, so what do I do ?  Your method might be handy in
    such a case.  (but I would suggest refining the synchronization
    procedure as I mentioned)
    
    /Eric
411.49VIDEO::LEICHTERJJerry LeichterWed Mar 25 1987 02:0411
Rather than turning on ALL the privilege bits, turn on just SETPRV.  The
only way a user you "accidentally" gave tht too would notice is if he
did a SHOW PROC/PRIV, since it has no direct effect on your ability to
do anything.

Even better:  Set SETPRV in the process's AUTHPRIV, but not in its CURRPRIV
values.  Then it won't show up even on a SHOW PROC/PRIV.  However, unlike
other privileges, SETPRV is special-cased:  If it's in AUTHPRV, you can set
any privilege you want even if it's not "currently enabled".

							-- Jerry
411.50Ring on privVIKING::WASSERJohn A. WasserWed Mar 25 1987 11:2810
> there is a high probability that you will get your own process.
> the other users will never notice
    
	I agree.  It would, however, be nice to know when you hit the
	right job.  How about writing a little program (in whatever 
	language) to be compute bound for a while and then check to see 
	if the appropriate privs have been granted.  It could ring
	the bell or something.  Run the program on one terminal and
	do the trick at the console until the bell starts ringing!
	
411.51The FATA Morgana of SECURITYMKTUP1::EIBENWed Mar 25 1987 21:459
    Aaah - the last couple of replies are FULLY in the 'spirit' of this
    notes-file. Just don't let them out to the NSA-people, who got
    brainwashed to give VMS a 'security-rating'.
    
    Rgds,
    Bernie [following RMS'es {Richard Stallman - author of EMACS/GNU}
    motto : "Would You put anything of personal value onto a computer
    system ??" ].