Conference vaxaxp::vmsnotes

re .0
    
>    If a user has full privileges, he can submit a batch job under other
>    user's UIC.  In such a case, can the audit utility or some other system
>    utility be able to detect that the job is actually submitted by that
>    user.
    
    That should be "submit a batch job under other user's name".
    
    I don't think that auditting can do what you ask viz. attribute the
    audit events to the real submitter.
    
    To submit a batch job under another user's name requires CMKRNL
    privilege which is in the "all" category and effectively means that any
    auditting could be circumvented e.g. one could simply turn off
    auditting around whatever nefarious activity one was involved in.
    
>    Also, is there any cost effective way to monitor work done by system
>    programmer, who possesses full privileges?   
    
    If you can't trust a person to whom full privs have been granted then
    don't grant them. This might involve assessing what real activities the
    staff had to perform and creating an environment that allowed them to
    perform those activities without having unrestricted use of privs if
    any are needed. There are various third party products that may help.

    Re: .0
>    user's UIC.  In such a case, can the audit utility or some other system
>    utility be able to detect that the job is actually submitted by that
>    user.
    
    Yes, the Security Auditing facility can be configured to record sufficient
    detail to provide the evidence in an analysis.. (i.e. correlation)
    
    
    Re: .1
|    auditting could be circumvented e.g. one could simply turn off
|    auditting around whatever nefarious activity one was involved in.
    
    Though, Nefarious J. Hacker would have to prevent any Security Auditing
    _changes_ from being audited (or otherwise evident), too.. (temporarily
    sinking audit events, perhaps?) ;)
    
    John.

  There are ways to track even privileged users - for instance keystrokes
  can be logged on another system to which the user has no access (this
  requires the hardware to be configured so that the use can only access the
  target system through the logging system).

  As Derek points out, a fully privileged user can, in theory, always bypass
  any security system, there is software that can make it very tricky to do
  so. For example, PSID can be configure to automatically reset auditing and
  report changes off-node. It would take a very determined cracker to beat it.

  Just a simple example - I was once called out of hours to help another
  specialist who was already logged into a customer system as FIELD. He wanted
  me to log in as well. Since the password he used to login was no longer
  valid, he tried to use AUTHORIZE to change it so I could login. PSID
  noticed he was messing with the UAF and promptly killed his process. Similar
  booby-traps can be set on other privileged operations.

						John Gillings, Sydney CSC

    re .2
    
>    Yes, the Security Auditing facility can be configured to record sufficient
>    detail to provide the evidence in an analysis.. (i.e. correlation)
    
    At a quick look, I couldn't see how one could make the association. In
    any case, I interpretted the base noter to be requesting the auditting
    facility itself to deal with it.
    
    re .3
    
    If we are talking about legitimately authorised all-privileged users then
    they may well have very detailed knowledge of the site and be quite
    able to bypass all the traps.
    
    Auditting to WORM could be challenging to handle without leaving *any*
    trace...
    
    
    I still maintain that removing the need for uncontrolled access to
    privs is a better course of action (if you can't trust the users).

    Even a software worm disk isn't that hard to build...I believe
    mine has been on sigtapes via DECUS. It must reside on an encrypting
    virt. disk to ensure that the driver is used, but acts like a
    WORM in that it disallows delete, overwrite etc. at driver 
    level. If someone is priv'd but does NOT have the one piece
    of info, namely the encrypt key, it's pretty tough to mess
    up w/o leaving traces.
    
    There are plenty of situations where folks get privs but where
    auditing is still appropriate out there in the Real World ;-).
    

    Thanks for all the ideas and advice.
    
     -- Keith.