RE: Programmer DFU access

John, if you've got a "conniving sort" that would go *that* length, you'd
better turn on journaling and write a program that scans the receivers for
your programmers making changes to production data.

- Dan Bale

> -----Original Message-----
> From: John Earl [SMTP:johnearl@400security.com]
> Sent: Friday, June 16, 2000 1:28 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Programmer DFU access
> 
> Albert,
> 
> "York, Albert" wrote:
> 
> > John Earl wrote:
> >
> > >I put together something similar once, and discovered a big problem
> with
> > it.  The
> > >spool file can always be manipulated/changed/deleted by the person who
> > reated it
> > >(even if it's in an outq they have *EXCLUDE authority to :(  ).
> >
> > >Our solution was to have an automatic SNDNETSPLF ship the spool file to
> > another
> > >system, into an outq that was *PUBLIC *EXCLUDE.  The new spool file
> ended
> > up
> > >being owned by  the owner of the SNDNETSPLF job, so it was slightly
> more
> > secure.
> >
> > You can also attach a data queue to the output queue. Any time a spool
> file
> > is added to the output queue an entry is added to the data queue. You
> then
> > have a program running in the background which processes the spool file,
> > adding it to a log file or whatever.
> 
> That's what we did.  Nice, but not bullet proof.   The data queue only
> triggers
> when a splf is dropped into the outq in a "ready" status.  A conniving
> sort could
> engineer a number of ways to keep the splf from ever getting to "ready"
> status so
> that he could delete it before it got sent.
> 
> Theoretically of course.
> 
> jte
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---