Conference noted::hackers_v1

    	For an outside hacker to make use of any VMS security bug I
    have ever heard of, or most of the nasty things we have been discussing
    in connection with physical access, requires that he first gets
    control of some process. So very high on the list of priorities
    has to be :-
    
    1) Make sure any captive accounts are really captive. This really
    needs a checklist on its own, and there is one in the Securpack
    documentation that we could take as a start.
    
    2) A default DECnet account that allows things like TELL.COM to
    be used is just as useful to a hacker with a good security bug.
    
    3) Rather less under the control of a system manager (unless he
    has users who will accept being forced to use generated passwords)
    is any account with a poor choice of password. The best thing here
    is education, but it can be difficult to find the time.
    
    4) Both routinely, and especially after a product installation,
    check for world writeable files. A couple of layered products have
    left these after an installation, and an external hacker can patch
    one over DECnet, and then just wait for it to be used by a privileged
    user.
    
    	Given the above, your system should be fairly safe against a
    hacker who does not have authorised access, and does not have access
    to the machine or console terminal?????
    
    	Forgetting the problems if physical access is possible, since
    there is already a note for that here, maybe we need a separate
    note for protection against misuse by hackers with legitimate
    authorised access, since I am sure there will be more to say for
    the case where the hacker has neither.
    
    		Dave

    In the spirit of this note.... MKTUP1 currently makes Public Domain
    Software for CPM / MSDOS and VMS available. I believe, I have been
    already 'educated' to change some things - but aside from 'physical
    access' -- I would like to invite 'hackers' to 'come over the net'
    and tell me what they found needs help.
    
    Rgds,
    Bernie - knowing that 'safety will be a MAJOR ARGUMENT soon'.
    

    
    Given the currently wide-open nature of the unencrypted ethernet,
    and the (literally) 1000's of passwords that pass along it each
    and every day, and combine that with the large numbers of proxy
    logins to privileged a/c's; securing the little machine in your
    office, or the large machine in the machine room has GOT to be
    regarded as a joke - why bother locking the windows when the
    front door is wide open?
    
    /Bevin

(flame-on)

re: .-1
>
> ...securing the little machine in your office, or the large machine in the
> machine room has GOT to be regarded as a joke - why bother locking the windows
> when the front door is wide open? 
> 

If we all considered it a joke, we never would get anywhere!  Perhaps if we ALL
did attempt to secure the "little machine..." in our office, then the whole
system would be considerably more secure than it currently is.  Besides,
Wouldn't locking the windows be a start anyhow? 

My reason for starting this particular note was so everyone that had an
idea for advancing the security of their own system can be shared with everyone
else that is interested.  Perhaps if enough ideas can be accumulated more of
the currently open windows can be closed. 

Please keep the remainder of this note dedicated to new ideas, if you want
to argue about the current security of the net or others, we can open another
discussion...


(flame off)


John

    
    If you have a MicroVMS system, be sure to change the passwords on
    (or delete...) the USER and USERP accounts. USERP is obviously
    especially dangerous.
    
    To make you system less susceptible to attack over the network,
    get rid of the EXEC NONPRIVILEGED and PRIVILEGED accounts, and use
    DEF OBJECT xxx PASSWORD yyyy USER zzzz on all objects that you want
    to be able to use. This should make sure that TELL can't be used
    on your system.
    
    Trev

    When somebody like Bevin makes a statement like that, it just has
    to be taken seriously. Getting excited about it isn't too productive.
    
    What is wrong with the "window-closing" philosophy is that it lulls
    users, and worse, security managers into a false sense of security.
    How many breakins, I wonder, result from incorrect application of
    an inappropriately high level of security?
    
    For example, captive accounts are a particularly thorny problem.
    I've seen captive accounts believed secure by their creators which 
    only required a ^Y to break out of! Any difficulties that might
    ensue in this case come from underestimation of the problem, not from 
    operating system weaknesses.
    
    The "front door" mentioned won't go away just by looking at the
    windows instead. It's inherent in the way the Ethernet works.
    The only reason it doesn't _seem_ to be causing problems at the moment
    is that it requires a certain amount of technical know-how. (I don't know 
    how to do it at the moment, and I don't expect to have the need to 
    find out, but I do know that I _could_ find out).
    
    How to advance the security of your own system? I would answer this
    in one word.  EDUCATION. And this should include self-education. It
    also should include educating the user community to potential
    problems, so that they don't have blind faith in the security of
    the system.
        
    Discussing how to increase security is a good idea, despite the 
    occasional screams of "RTFM" -- but it should be coupled with a
    discussion of the human problems involved in security management.

    It's not just a technical solution.
    
    -Nigel-

    Right on, .6!
    
    I remember this discussion happening before regarding captive command
    procedures. The DCL command procedures conference was an excellent
    source of ideas about securing captive command procedures as was,
    not surprisingly, the SECURPAK manual. For instance, just changing
    your INQUIRE statements to READ/PROMPT/etc SYS$COMMAND removes all
    those nasty little DCL side effects like 'F$PID(LOGOUT). Letting
    hackers loose on your code before you let it out for general use
    is a great suggestion; I have been doing that for awhile, if the
    hackers are on your side it helps a LOT.
    
    As for securing all of our little systems: Clearly this is not 100%
    bombproof. However a good security manager understands that 100%
    security is not realistically possible and that given the criteria
    and the fact that DEC is NOT the Pentagon, our focus should address
    accountability as well as prevention. If I have a successful login
    OR an unsuccessful login attempt over the network, if my accounting
    is enabled I get the account name that attempted the login. If I
    have ACL's enabled I find out who deleted a file from a CMS library
    without using CMS to do it. If I have the obvious account/password
    combinations removed (SYSTEM/MANAGER, come on!) and set a minimum
    password length, it makes guesses more difficult.
    
    Even failing that, I get the soft equivalent of a "paper trail"
    so I can spend a little time to find what I'm looking for. If everyone
    on the E-net did that it would be difficult to hide yourself. Of
    course, there are limitations. Your uVAX-I might not like image
    accounting enabled on an RD-52 system disk for long. However you
    don't need image accounting to do good accounting.
    
    /pjh

    Until operating systems and layered products/applications have no
    bugs or design errors which allow authorized users to perform
    unauthorized activities, the only hope for security is to secure
    the perimeter. Once an intrusion occurs (unauthorized user gains
    access masking as an authorized user) by definition the system has
    been compromised. You must trust your authorized users to not perform
    any unauthorized activities, given the current state of affairs.
    
    You can apply all the protection you want to objects; they are useless
    if a means exists to get past them. You can audit every action; being
    informed that the bank has been robbed doesn't make it secure, and
    the smart burglar either won't set off any alarms, or will get in
    and out before they can be apprehended. 
    
    Dave

    re .-1 - sounds a little bit 'inconsistent' to me ..
    
    On one side we're proud of 'networks' and communications [even as
    'cheap' as incoming phone-lines] - on the other side, You talk
    about a [pretty aged] 'perimeter'! What is that one in todays
    world ?? ALL of DEC's [or the customers] buildings incase he has
    no incoming phone-lines ?? - WE ARE IN NEED of betterments.
    SECURPACK was a good marketing-job - it didn't however change
    much of the reality that SECURITY is EITHER INHERENT {i.e. 'designed
    in' from the beginning into the OS} or non-existant {LAYERED PRODUCTS
    HAVE NO DEALINGS reguarding SECURITY , they can be 'buggy as hell'
    as long as 'security' is at the OS-base !!}
    
    Rgds,
    Bernie [ let's get the 'unwanted features' out into the open - so
    that guys valuing their 'data' can take needed actions].
    

    Compromise of security comes in one of two forms
    
    1) monitoring the operation of the system, a passive and non-directed
    	activity (ie tapping the communications line or receiving RF,
    	hoping to hear something interesting)
    2) active penetration towards a specific goal (login or otherwise
    	cause specific code to be executed to obtain desired information)
    
    This indirectly defines the perimeter of which I speak. If I can't
    successfully perform either action, then the system is secure.
    Point (1) is being addressed today by such means as copper-clad
    computer rooms, encryted communications, TEMPEST specifications,
    physical plant security, such that the activities of authorized
    users can't be monitored. Point (2) can only be addressed be proper
    management of the passwords and accounts which allow entry to the
    system. ONCE I AM IN (ie once I successfully pretend I'm an authorized
    user) the system has been compromised. 
    
    If I enter as user X, his files and anything he has access to is mine. 
    If user X is privileged, or can cause code to execute in a privileged
    context, nothing on the system is safe. The operating system and
    applications on the system can attempt to prevent me from 'causing
    code to execute in a privileged context', but bugs and design errors
    DO occur. And if I successfully masquerade as a privileged user,
    things are even simpler. The point is, that once I'm past the
    perimeter, it becomes enourmously more difficult, if not impossible,
    to protect information on the system.
    
    Dave

    Just how much security do you need or want?
    
    If we're talking about "absolute" security then you can't have it
    with Ethernet, T1 lines, or anything short of a radiation-hardened
    computer room under a mountain with a single terminal hard-wired
    in the same room as the computer, disks, and tape(s), as well as
    physical identity checking of the user (or users) with a
    classification rating, etc, etc. I believe that's what they call
    "Class A" security? 
    
    You speak about the perimeter, but the perimeter in the DEC world
    is generally VERY easy to crack, nor is it realistically possible
    given those constraints to make the environment class-A secure.
    If you have two machines and they are connected by a wire and that
    wire is "unattended" at any point in the path, you are not secure.
    
    The software is another story altogether. Privileged functions should
    know their caller. Installed sections cannot have traceback; this
    supposedly makes it more difficult to figure out how to run them
    outside of their intended context, right? 
    
    I remember reading that DOD rated VMS V4 as a class C secure operating
    system; I am not certain about what constitutes a class C security
    rating but I believe the reference monitor has something to do with
    it. 
    
    The point is the pieces are there; using them, or even wanting to
    use them, is totally up to the user/customer. All of these safeguards
    take effort, and there is an appreciably large amount of effort
    which needs to be expended to make them work. Many system managers
    do not have the time to constantly monitor their system for intrusions.
    Letting SECURPAK tell you that someone tried to break in yesterday
    sometime is little comfort, since they could have been successful
    between then and now. I understand there are books on this subject,
    DEC even has a "Guide to VAX/VMS Security" (even read it!)... A
    system manager or the people who run the system have to make a
    conscious decision about how much security is enough security. I
    firmly believe that absolute security is impossible, to believe
    so is to fool yourself. To baby-sit a system looking for that burglar
    to hit is pretty boring, especially if they don't know you're there.
    Plus it's a waste of money to pay someone to do that. That's what
    the reference monitor is for. 
    
    There has GOT to be a balance between security and productivity.
    My workstation cannot be insulated from the rest of the corporation
    without a large cost to me, I pay by losing the ability to do things
    like this :-) but really, this has been said in the last 30 or so
    replies in the last two major topics - physical and "logical" security
    are two completely different topics and (it seems) should have a
    different focus.
    
    /pjh

    Suggestion (re: User and UserP on �Vax)
    
    	Don't delete them - use /FLAGS=DISUSER in AUTHORIZE.  That way
    you get that the attempt was made on those accounts, not just "no
    such user" from the security alarm.
    
    	I have also modified the netserver login not to purge Netserver.Log
    and I read ***every one*** on the 2 �Vaxen I manage.
    
    					--Doug

>    	I have also modified the netserver login not to purge Netserver.Log
>    and I read ***every one*** on the 2 �Vaxen I manage.
    
    How many do you usually get a day? On our manufacturing systems
    and routers we get about 200-300 NETSERVER.LOGs depending on the
    traffic, day of week, etc. There are 77 various VAXen on the orange cable
    in our plant. Of those, 24 are managed by three (yes, three) people.
    The uVAX population is relatively small, too, and some of those 
    system managers are not full-time system managers, but people who
    just happen to be lucky enough to rate having a workstation. 
    
    Now, we DO have a retention on many of the DECNET accounts and we
    DO use securpack but it is simply not realistic to wade through
    two pages per system of password changing messages and JOBCTL deletion
    messages to find that one buried attempted breakin that may or may
    not have happened.
    
    This is not to say that what you are doing is not constructive,
    I keep saying this - occasionally this is not necessarily realistic
    in the context of a large scale distributed computer integrated
    manufacturing environment. There is a LOT of network traffic, and
    we simply can't be expected to manage systems and police the network
    too.

    /pjh

Re: .-1 {/pjh}
    
        I agree - not everyone can read all the netservers.  Both of
    our �Vax are very low DECNET traffic.  I don't read all of them
    on the 785 I manage.  I do have SECUREPACK, but have turned off
    the file access failure reports -- I couldn't possibly read all 
    the failures we get in a day.
    
    	It would certainly be possible to write something to weed out
    the MAIL and PHONE netserver logs and leave the more interesting
    ones...  Any volunteers?
    
    	One of the "features" of computers is the ability to produce
    more information than any person can absorb.  The small systems
    sometimes offer a more manageable information load.  I didn't mean
    to imply that everyone should read every netserver... Just what
    I do on 2/3 of my systems.  Sorry if that wasn't clear.
    
    					--Doug

    
    Re: Doug
    
    it's all right, you're forgiven :-)
    
    Seriously; I was thinking about this some more. There has got to
    be a way that we all can tell (or at least be more intelligent about)
    what information we *should* be investigating further. Maybe by
    *excluding* certain information which is normally put into logs.
    I suppose these ideas should be QARed to the SECURPAK people but
    I don't know if they have a place for that.
    
    Anyway, why not build in the capability (somewhere!) to EXCLUDE
    things like JOBCTL, certain network objects, etc. Maybe you should
    set up network objects off of object 0 and give them passwords.
    If you're really paranoid then shut your network off at night.
    
    It seems kind of silly to have to go through all this, especially
    once it starts interfering with "normal" operations, like
    across-the-world mail transfers, overnight file transfers, etc.
    
    Yes, if you have a small system which is not a router or shouldn't
    have a lot of traffic like a VSII or something then it's safe to
    say a "security alarm" is a big event. However on a major router
    for a plant which does very little but route DECNET traffic to and
    fro then it's another ball game.
    
    Perhaps this is a thing to "add to the checklist" (remember .0?)
    
    Know what you are going to use your machine for before you decide
    the level of security for it. Some kinds of security are not exactly
    appropriate for workstations but are definitely needed on machoVAXen.
    
    /Paul_J

    You may also wish to disable (/FLAG=DISUSER) some of the additional
    account which are not used frequently.
    
    These accounts include, SYSTEM, FIELD, SYSTEST...  If you need to
    use an account like SYSTEM, simply re-enable it, aand log in.  Note,
    the SYSTEM account has always been intended for just software
    installations and the like, and not for general use.  
    
    Should you need to have an account jsut like SYSTEM, COPY it to
    a different username, and use that.  
    
    My 2�,
    -- Nestor

Re .15
>    I suppose these ideas should be QARed to the SECURPAK people but
>    I don't know if they have a place for that.

    If you have any suggestions on how to improve SECURPACK please mail
    then to me or post them in the SECURPACK conference on ANCHOR::.
    We will be looking at starting an update to the product.
    
    Ed

    The following .com file creates and/or disables accounts.
    It is the result of modifications to the VMS supplied
    adduser.com and suggestions from various people. 
    
    This procedure also ties network objects to accounts of
    the same name. 
    
    Please mail comments/suggestions for improvements directly.
    
    mike
    
    
$ !                           Copyright � 1986,1987 by
$ !                      Digital Equipment Corporation,
$ !                          Maynard, Massachusetts.
$ !                           All rights reserved.
$ !
$ !  This software is furnished under a license and may be used and copied
$ !  only in accordance with the terms of such license and with the inclusion
$ !  of the above copyright notice.  This software or any other copies
$ !  thereof may not be provided or otherwise made available to any other
$ !  person.  No title to and ownership of the software is hereby transferred.
$ !
$ !  The information in this software is subject to change without notice and
$ !  should not be construed as a commitment by Digital Equipment Corporation.
$ !
$ !  Digital assumes no responsibility for the use or reliability of its
$ !  software on equipment that is not supplied by Digital.
$ !
$ !
$ !  modified  MJT 18-MAR-1987 
$ !	Add/Modify a new user account to the system
$ !     Copied from adduser.com supplied with �VMS 4.4
$ !     also based on a memo written by Dave Knight
$ !     and SQM recommendations for server accounts
$ !
$ ! passed parameters:  P1 is the list of users
$ !--
$ !
$ ! verify in debug mode
$ !
$ Set noon
$ verify_context = 'f$verify(0)' 
$ secpack$debug = f$trnlnm("secpack$debug").or."''secpack$debug'"
$ if secpack$debug then $set verify
$ on controly then EXIT
$ !
$ ! check if user has required privileges to run this procedure
$ !
$ required_privileges = "SYSPRV"
$ prev_privs = f$setprv(required_privileges)
$ if .not. f$privilege(required_privileges) then goto no_privileges
$TYPE SYS$INPUT

                 Create accounts for applications procedure

    This procedure will define accounts for applications needing or
    typically using the DECnet account. You can define an account to 
    be disable to prevent access, but still get a login failure alarm.
    The intent is to provide better network security for your system. 

$ !
$ ! Default values
$ !
$ on controly then goto bad_message
$ on error then continue 
$ defuserdisk = "$DISK1:"		! Default disk for new users
$ userdisk = ""                         ! Default disk for new users
$ defgrp = "222"                        ! Default group number
$ defmem = "1"                          ! Default member number
$ defacc = ""                           ! Default account name
$ defpriv = "TMPMBX,NETMBX"             ! Default account privilages
$ no_privs = "NOALL"                    ! Take away Default privilages
$                                       ! Default account flags
$ defflags = "DISCTLY,DEFCLI,LOCKPWD,DISNEWMAIL,DISMAIL" 
$ disableflags= ",DISUSER,CAPTIVE"      ! disable the account flags
$ defaccess = "/NETWORK/NOINTERACTIVE/NOBATCH"   ! default access
$ ! Stop all access and resource use
$ no_access = "/NOACCESS/WSQUOTA=1/WSDEF=1/WSEXT=1/PGFLQUOTA=1/CPU=00:00:00.1" 
$ deflgicmd = "sys$manager:disabled_account_login.com" ! default login.com
$ defquo = 10                           ! Default disk quota
$ defovr = 10                           ! Default overdraft quota
$ grp = ""
$ 
$ uaf = "$authorize"
$ ncp = "$ncp"  ! network
$!
$ on warning then goto cleanup 
$ on error then goto cleanup 
$!
$! need to be in sys$system for access to uaf.dat
$ olddir = f$environment("DEFAULT")
$ set default sys$system
$ write sys$output ""
$ !
$ ! Get new user names
$ !
$    If P1 .eqs. "" then goto get_usernames 
$    user = P1     ! use the names passed 
$    goto ext_name 
$ !
$get_usernames:
$    inquire user "Username(s) - separate by commas"
$    if user .eqs. "" then  user := "MAIL,PHONE,DECNET" ! ,FAL,NML"
$ !
$ ! Extract one user name from list
$ !
$ext_name:
$    username = f$extract(0,f$locate(",",user),user)
$    user = user - username - ","
$    if username .eqs. "" then goto cleanup ! all done
$ ! 
$ !  check if account already exists (copied from securepack)
$ !
$    account_exists = 0 ! false
$    uaf_function = "ADD" 
$    On error then goto does_not_exist
$    Assign/user sys$scratch:show_account.tmp sys$output
$    Assign/user nl: sys$error
$    Uaf Show 'username'  /brief 
$ !
$ ! check existance by checking Number of blocks used
$    if F$file("sys$scratch:show_account.tmp","EOF").eq.0 then goto does_not_exist 
$ !
$ ! Check if guest account exists
$    Open/read sysuaf sys$scratch:show_account.tmp 
$ Check_exist:
$    Read/end_of_file=parse_for_uic sysuaf record
$    If f$locate("no user matched", record).eq.f$length(record) then -
        goto Check_exist  ! loop
$ !
$ ! Parse for uic
$ !
$ Parse_for_uic:
$    Close sysuaf
$ ! Reopen the scratch file and read the user's uaf record
$
$ Open/read uaf sys$scratch:show_account.tmp 
$ 
$ Loop:
$
$ Read uaf record
$ Left_position = f$locate("[", record) 
$ If left_position.eq.f$length(record) then goto loop
$
$ ! Get group uic and member uic of guest account
$
$ Comma_position = f$locate(",", record)
$ Group_uic_length = comma_position - left_position - 1
$ Left_position = left_position + 1
$ Group_uic = f$extract(left_position, group_uic_length, record)
$ 
$ Right_position = f$locate("]", record)
$ Member_uic_length = right_position - comma_position - 1
$ Comma_position = comma_position + 1
$ Member_uic = f$extract(comma_position, member_uic_length, record)
$ Close uaf
$ ! make the existing uic the default uic
$    account_exists = 1 ! true
$    uaf_function = "Modify" 
$    defgrp = group_uic
$    defmem = member_uic
$ 
$ Does_not_exist:   ! cleanup the tmp file
$    Delete sys$scratch:show_account.tmp.* 
$ !
$ restart_account:  ! come back if an error was made creating account
$ On error then goto cleanup
$ !
$ ! check if should create any account
$ ! then see if it should be a disabled account
$ !
$    inquire ok " ''uaf_function' the account ''username' [YES]"
$    if ok .eqs. "" then ok = "YES"
$    if ok .nes. "YES" then goto ext_name
$ !
$    no_account = 1 ! default is to disable the account
$    inquire ok " Disable the account ''username' [YES]"
$    if ok .eqs. "" then ok = "YES"
$    if ok .nes. "YES" then no_account = 0 ! do not disable the account
$ !
$ ! Process extracted name, get full name and password
$ !
$full_name:
$ write sys$output ""
$ write sys$output " *** Processing ",username,"'s account ***"
$ write sys$output ""
$ inquire full_name "Full name for ''username' [''username']"
$ if full_name .eqs. "" then full_name = username
$!
$ get_password:
$    set term/noecho
$    inquire password "Password (password is not echoed to terminal) "
$    set term/echo
$    if password .eqs. "" then goto invalid_password
$    if password .eqs. "''username'" then goto invalid_password
$    goto get_uic
$ !
$ invalid_password:
$    write sys$output ""
$    write sys$output "Password is required. "
$    write sys$output "Password can not be the same as the account. "
$    write sys$output ""
$    goto get_password
$ !
$ ! List containing all accounts.  Use list to acquire an unspecified
$ ! UIC group and member number to give to the new user.
$ !
$ display_UIC_list:
$    write sys$output ""
$    uaf show [*,*]/brief
$    write sys$output ""
$    goto get_uic
$!
$display_UIC_members:
$    write sys$output ""
$    uaf show ['defgrp',*]/brief
$    write sys$output ""
$    goto get_member
$ !
$ ! Get group and member numbers
$ !
$get_uic:
$    write sys$output ""
$    write sys$output username," should be placed in a unique group. "
$    inquire grp "UIC Group number (enter ? to list all UIC's) [''defgrp']"
$    if grp .eqs. "?" then goto display_UIC_list
$    if grp .eqs. "" then grp = defgrp
$    defgrp = grp
$get_member:
$    inquire uic -
     "UIC Member number (enter ? to list UIC ''defmem' members) [''defmem']"
$    if uic .eqs. "?" then goto display_UIC_members
$    write sys$output ""
$    if (uic .eqs. "") .and. (defmem .eqs. "") then goto get_member
$    if uic .eqs. "" then uic = defmem
$    defmem = uic
$ !
$ ! Combine group and member numbers to create complete UIC
$ ! in the form - [group,member]
$ !
$create_uic:
$    if f$loc("[",uic) .eq. f$len(uic) .and. -
	f$loc("<",uic) .eq. f$len(uic) then uic = "[" + grp + "," + uic + "]"
$ !
$ ! check if unique
$ !
$ !
$ ! Get account name and privileges
$ !
$get_accpriv:
$    defacc = username
$    inquire account "Account name [''defacc']"
$    if account .eqs. "" .and defacc .eqs. "" then goto get_accpriv
$    if account .eqs. "" then account = defacc
$    defacc = account
$!
$!   get privs unless the account is to be disabled
$!
$    if no_account then goto noprivs
$    inquire privs "Privileges [''defpriv']"
$    write sys$output ""
$    if privs .nes. "" then privs = "/PRIV=(" + privs + ")"
$    userdir = username
$    goto get_login
$ noprivs:
$    privs = "/DEFPRIV=(" + no_privs + ")/PRIV=(" + no_privs + ")"
$    
$ !
$ ! Get login directory and device
$ !
$get_login:
$    userdir = username
$get_login_again:
$    inquire tmp "Login directory [''userdir']"
$    if tmp .nes. "" then userdir = tmp
$get_device:
$    if userdisk .eqs. "" then userdisk = defuserdisk
$    inquire tmp "Login device [''userdisk']"
$    write sys$output ""
$    if tmp .nes. "" then userdisk = tmp
$ !
$ ! Check if disk really exists
$ !
$    exists_test = f$getdvi("''userdisk'","EXISTS" )
$    if "''exists_test'" .EQS. "TRUE" then goto get_quotas
$    write sys$output "''userdisk' does not exists, try another device. "
$    userdisk = "" ! current value is no good
$    goto get_device
$ !
$ ! Get disk quota and overdraft quota
$ !
$get_quotas:
$    dquota = 0
$    if f$search("''userdisk'[0,0]QUOTA.SYS") .eqs. "" then goto setup_flags
$    dquota = 1
$    inquire quota "Disk quota [''defquo']
$    if quota .eqs. "" then quota = defquo
$    inquire overdraft "Overdraft quota [''defovr']"
$    write sys$output ""
$    if overdraft .eqs. "" then overdraft = defovr
$    defquo = quota
$    defovr = overdraft
$    open/write file sys$scratch:addquota.tmp
$    write file "$ SET DEFAULT ''userdisk' "
$    write file "$ RUN SYS$SYSTEM:DISKQUOTA
$    write file "ADD ",uic,"/PERM=",quota,"/OVERDRAFT=",overdraft
$    write file "$ SET DEFAULT SYS$SYSTEM"
$    close file
$    @sys$scratch:addquota.tmp
$    delete sys$scratch:addquota.tmp;*/nolog
$ !
$ ! Check the flags and access 
$ !
$ setup_flags:
$    flags = "/FLAGS=(" + defflags 
$    if no_account then flags = flags + disableflags 
$    flags = flags + ")"
$!
$    access = defaccess ! only network access
$    if no_account then access = no_access + "/LGICMD=" + deflgicmd  
$ !
$ ! Create new user directory. Create new account.
$ !
$create_account:
$    open/write file sys$scratch:adduaf.tmp
$    write file "$ RUN SYS$SYSTEM:AUTHORIZE"
$ !  if the account already exists then really doing a modify
$ !  when the account is to be disabled then the input string is too long
$ !  need to do in two operations do critical stuff first
$    write file uaf_function," ",username,"/UIC=",uic,-
        privs,"/PASSW=",password,flags,access
$    write file "MOD ",username,"/OWN=""",full_name,"""/ACCO=",account,-
        "/DEV=",userdisk,"/DIR=[",userdir,"]
$    close file
$    type sys$scratch:adduaf.tmp;* ! not needed but nice to see for debugging
$    @sys$scratch:adduaf.tmp
$    delete sys$scratch:adduaf.tmp;*/nolog
$!
$    create/dir/owner='uic'/prot=(s=rwe,o=rwe,g,w) 'userdisk'['userdir'] /LOG
$    on controly then goto good_message
$    if no_account .eq. 0 then goto show_account
$ !
$ !  if the account is disabled then check if deflgicmd exists
$ !     if not then create it to logout
$ !
$    if f$search("''deflgicmd'") .nes. "" then goto show_account
$    open/write file 'deflgicmd
$    write file "$ logout "
$    close file
$    set file /prot=(s=rwe,o=re,g,w:r) 'deflgicmd /LOG
$ !
$ ! Show newly created account to check for possible errors
$ !
$show_account:
$    write sys$output ""
$    write sys$output "Check newly created account:"
$    write sys$output ""
$    open/write file sys$scratch:shouaf.tmp
$    write file "$ RUN SYS$SYSTEM:AUTHORIZE"
$    write file "SHOW ",username,""
$    close file
$    @sys$scratch:shouaf.tmp
$    delete sys$scratch:shouaf.tmp;*/nolog
$ !
$ ! If an error in account then remove account.
$ ! If no error then process network object
$ !
$    write sys$output ""
$    inquire ok "Is everything satisfactory with the account [YES]"
$    if ok .eqs. "" then ok = "yes"
$    if .not. ok then goto remove_uaf
$ !
$ !  Create Network object 
$ !
$ create_network:
$ ! If an error then remove network object
$ ! If no error then process next user name, create next account.
$ ! ncp is defined up front
$ !
$    inquire ok " Create the network object ''username' [YES]"
$    if ok .eqs. "" then ok = "YES"
$    if ok .nes. "YES" then goto done_network
$ !
$    if no_account then password = "invalidpassword"
$ ! create or modify the object in the permanent database
$    NCP define object 'username user 'username account 'username password 'password
$ ! create or modify the object in the volatile database
$    NCP set object 'username user 'username account 'username password 'password
$ !
$    NCP show known object  
$    write sys$output ""
$    inquire ok "Is everything satisfactory with the network object [YES]"
$    if ok .eqs. "" then ok = "YES"
$    if ok .nes. "YES" then goto remove_network
$ !
$ done_network:
$    if user .nes. "" then goto ext_name
$!
$cleanup:
$    set term /echo
$    prev_privs = f$setpriv(prev_privs)
$    set default 'olddir'
$    exit
$ !
$ ! Remove account, then return and process same account again
$ !
$remove_uaf:
$    if account_exists then goto do_not_remove_uaf
$    write sys$output ""
$    write sys$output "Removing newly created account"
$    write sys$output ""
$    open/write file sys$scratch:remuaf.tmp
$    write file "$ RUN SYS$SYSTEM:AUTHORIZE"
$    write file "REMOVE ",username,""
$    write file "$ DELETE ",userdisk,"[000000]",userdir,".DIR;1/LOG"
$!
$    if f$search("''userdisk'[0,0]QUOTA.SYS") .eqs. "" -
        then goto close_remove_file
$    write file "$ SET DEFAULT ''userdisk' "
$    write file "$ RUN SYS$SYSTEM:DISKQUOTA
$    write file "REMOVE ",uic
$    write file "$ SET DEFAULT SYS$SYSTEM"
$close_remove_file:
$    close file
$    @sys$scratch:remuaf.tmp
$    del sys$scratch:remuaf.tmp;*/nolog
$    on controly then goto good_message
$    write sys$output ""
$    goto restart_account ! go process same account
$ !
$ ! Can not remove account because it existed before we started
$ !
$ do_not_remove_uaf:
$    write sys$output ""
$    write sys$output "Account already existed."
$    write sys$output "Will not remove Account ",username,"."
$    write sys$output ""
$    goto restart_account ! go process same account
$ !
$ ! Remove network object, then ???
$ !
$remove_network:
$    write sys$output ""
$    write sys$output "Removing newly created network object "
$    write sys$output ""
$    write sys$output "Opps, I do not know how "
$ ! purge the object in the permanent database
$    NCP purge object 'username user account password 
$ ! clear or modify the object in the volatile database
$    NCP clear object 'username user account password 
$ !
$    NCP show known object  
$    write sys$output ""
$    goto create_network ! go process same network object
$!
$! What to say when user hits ^Y
$!
$good_message:
$    write sys$output ""
$    write sys$output " Program halted by control_y, "
$    write sys$output " account has already been created."
$    write sys$output ""
$    goto cleanup
$bad_message:
$    write sys$output ""
$    write sys$output " Program halted by control_y, "
$    write sys$output " account has not yet been created."
$    write sys$output ""
$    goto cleanup
$!
$no_privileges:
$ write sys$output "You need SETPRV or SYSPRV privilege to run this procedure"
$ goto cleanup