home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!wupost!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!imhw400
- From: imhw400@indyvax.iupui.edu
- Newsgroups: comp.os.vms
- Subject: Re: Accounting Info
- Message-ID: <1992Aug12.084526.147@indyvax.iupui.edu>
- Date: 12 Aug 92 08:45:26 -0500
- References: <01GNAZWCKZ4Y00004O@VAXF.COLORADO.EDU> <1992Aug10.015715.193@rlgsc.com>
- Distribution: world
- Lines: 27
-
- In article <1992Aug10.015715.193@rlgsc.com>, gezelter@rlgsc.com writes:
- [...]
- > There are three possibilities:
- >
- > 1) TASK Object Removed/Deleted/Full Disabled
- > 2) TASK Object only allowed to valid users
- > 3) TASK Object allowed to anonymous logins (default access)
- >
- > Of the three above cases, the real security hole is systems which
- > allow (3), namely, any Tom, Dick, or Harry to execute programs
- > using the TASK object.
- >
- > The use of (2) above, namely, that authorized system users may
- > make use of the task object is not generally a security hazard
- > (if it is, then you would also have to prevent your users from
- > running programs from their accounts, not normally a desireable
- > goal on many systems)
-
- Golly, I'm glad to find that somebody else has noticed this. It seems like
- whenever someone asks how to secure DECnet, every answer begins with "disable
- the TASK object". As Mr. Gezelter goes on to point out, this is fine in some
- situations and needlessly restrictive in others. You wouldn't want to do it on
- a system used for developing network applications, for instance.
- --
- Mark H. Wood, Lead Analyst/Programmer +1 317 274 0749 [@disclaimer@]
- Internet: IMHW400@INDYVAX.IUPUI.EDU BITNET: IMHW400@INDYVAX
- Celebrate freedom: read a banned newsgroup.
-