Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #212148 > unrolled thread

Early mainframe security

Back to article view | Back to alt.folklore.computers

Contents

  Early mainframe security antispam@math.uni.wroc.pl - 2020-06-29 20:40 +0000
    Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 13:49 -0700
    Re: Early mainframe security Dan Espen <dan1espen@gmail.com> - 2020-06-29 16:53 -0400
      Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-29 23:59 +0000
        Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 17:24 -0700
          Re: Early mainframe security Thomas Koenig <tkoenig@netcologne.de> - 2020-06-30 07:57 +0000
          Re: Early mainframe security "Kerr-Mudd,John" <notsaying@invalid.org> - 2020-06-30 08:21 +0000
    Re: Early mainframe security Douglas Miller <durgadas311@gmail.com> - 2020-06-29 13:55 -0700
      Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-29 17:40 -0400
      Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-06-30 00:08 +0000
        Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 07:38 -0700
          Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-01 15:14 +0000
            Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 13:03 -0700
              Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-02 00:52 +0000
                Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-11 18:04 -0700
                  Re: Early mainframe security Grant Taylor <gtaylor@tnetconsulting.net> - 2020-07-11 19:10 -0600
                  Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-07-12 02:50 +0000
                    Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-13 14:26 -0700
    Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-29 23:00 +0100
      Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-30 00:27 +0000
        Re: Early mainframe security and channel programs John Levine <johnl@taugh.com> - 2020-06-30 02:58 +0000
        Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 11:34 +0100
        Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-30 06:15 -0700
          Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-30 14:01 +0000
            Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 22:39 +0100
        Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-06-30 19:37 -0500
    Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-06-29 22:18 +0000
      Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 15:49 -0700
      Re: Early mainframe security Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-29 18:28 -0600
        Re: Early mainframe security Quadibloc <jsavard@ecn.ab.ca> - 2020-06-29 21:11 -0700
        Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 11:35 +0100
          Re: Early mainframe security Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-06-30 22:18 +0000
            Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-01 15:08 +0000
      Re: Early mainframe security Thomas Koenig <tkoenig@netcologne.de> - 2020-06-30 07:51 +0000
        Re: Early mainframe security Bob Eager <news0073@eager.cx> - 2020-06-30 08:49 +0000
    Re: Early mainframe security Ahem A Rivet's Shot <steveo@eircom.net> - 2020-06-30 09:43 +0100
    Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-06-30 19:23 -0500
      Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-30 18:03 -0700
        Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-30 22:32 -0400
          Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-07-01 03:21 +0000
            Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-30 23:52 -0400
            Re: Early mainframe security Dan Espen <dan1espen@gmail.com> - 2020-06-30 23:56 -0400
        Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-07-01 22:21 -0500
    Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 07:33 -0700
    Re: Early mainframe security Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-03 12:25 -1000
      Re: Early mainframe security Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-03 12:58 -1000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#212161 — Re: Early mainframe security and channel programs

In article <rde0tn$n2b$1@z-news.wcss.wroc.pl>,
 <antispam@math.uni.wroc.pl> wrote:
>That is part I want to understand.  It seems that access macros set
>up control blocks in user space.  So user could tamper those control
>blocks in arbitrary way.  It is not entirely clear to me how system
>ensured that access method will do its job.  IIUC access method
>run outside of resident part of nucleus and it seems that it used
>SVC to communicate with nucleus. 

Yup. The access method wrote its own channel programs and passed them
to the supervisor to run. Of if you wanted, your application could do
an EXCP itself to run any channel program it wanted. Sounds pretty
dangerous, huh?  Nope.

It wrote a litttle channel program of its own that did a "set file
mask" command and then jumped (TIC for transfer in channel) to your
program. The set file mask tells the channel what your channel program
is allowed to do, confining it to a particular cylinder or track. To
prevent stomping other programs, every 2K storage block had a four-bit
storage key, and each running program and each channel program also
had a storage key which had to match the key for any data it wrote
(and depending on settings, maybe also any data it read.)


-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#212168

On 30/06/2020 01:27, antispam@math.uni.wroc.pl wrote:
> David Wade <g4ugm@dave.invalid> wrote:
>> On 29/06/2020 21:40, antispam@math.uni.wroc.pl wrote:
>>> I wonder how much security was provided on early IBM mainframes.
>>> IIUC 360 series had distinction between supervisor and user (poblem
>>> state) mode and used key memory protection.  This in principle
>>> allows good security.  OTOH key protection was optional on
>>> low end models, so it seems that security there has based
>>> on honesty of personel.  Looking at MVS documentation it
>>> is mentioned that program may have right to access to whole
>>> disc, but apparently there were no way to restrict access
>>> to part of disc.  More generaly, IIUC access methods passed
>>> channel program to nucleus and I see no place where access
>>> was checked.  So, could badly behaving program write on the
>>> whole disc, or there were some safeguard that I missed?
>>>
>>
>> Well lets start at the beginning. It was a totally different world.
>> A world where all data was double keyed to check its accuracy.
>> A world where there would be a strict schedule on which jobs ran.
>> A time when "the Operators" were gods and to whom you grovelled and
>> offered sacrifices when you wanted to test a program change...
>> ... but on April 1st you attempted to get revenge by changing the device
>> names round....
>>
>> A world where on a small machine you only ran one or two jobs at once.
>> Where there were no fixed disks. A typical pack was less than 20Mb.
>> So when running a job only needed tapes and disks were on the machine.
>>
>> So if a disk was corrupted it was instantly obvious which program had
>> done it, and as each program had a single keeper you were pretty sure
>> who was to blame.
>>
>> Could you overwrite a whole disk?  Generally it was hard.
>> The JCL specified files names and maximum file sizes.
>> If you have protection the access methods run in supervisor state so
>> can't be tampered with by a program. The program passes logical requests
>> read/write records or blocks to the access method, so the program can
>> only access the files allocated in the JCL. Once the space allocated is
>> filled the program abends.
> 
> That is part I want to understand.  It seems that access macros set
> up control blocks in user space.  So user could tamper those control
> blocks in arbitrary way.  It is not entirely clear to me how system
> ensured that access method will do its job.  IIUC access method
> run outside of resident part of nucleus and it seems that it used
> SVC to communicate with nucleus.  

 From what I remember Access Methods run in privileged mode outside user 
space. Not in the nucleus but part of the supervisor. That way you can 
add access methods.

The MVS file system was extremely complex for its time and supported 
file sharing etc.

The DCB in user space is used to communicate with the Access Method. It 
does not contain all the information needed to access the file, some of 
that is maintained in supervisor space in supervisor control blocks.

In fact there is no physical information in a DCB. So when you issue an 
"open" the access method creates


> IBM documentation writes a lot
> about variouos options and their effects and about general rights but
> seem to be quite careful to _not_ disclose the actual details where
> checks are done and what is checked.

Its all in the Program Logic Manuals.

> 
>>
>> Yes you could allocate a whole disk in JCL, but the JCL was generally
>> securely managed and change controlled.
> 
> Hmm, IIUC to compile or assemble program one needs to submit
> proper JCL.  In fact, to do anything in batch jobs seem to
> require JCL.  So anybody with right to submit jobs (like
> student doing programming exercises) may submit JCL.  OTOH
> is seems that not all JCL is equal, some has more rights...
>

Most universities did not use MVS for student jobs. Once you get to 
running student jobs you would have user names and passwords.

User names with rights to mount packs would have their passwords kept 
secure.


Dave

[toc] | [prev] | [next] | [standalone]

#212170

<antispam@math.uni.wroc.pl> wrote:
> 
> That is part I want to understand.  It seems that access macros set
> up control blocks in user space.  So user could tamper those control
> blocks in arbitrary way.  

No, the DEBs were in an area with the system key.

> It is not entirely clear to me how system
> ensured that access method will do its job.  

As I said, the supervisor ensured that any user I/O operation was limited
to one cylinder at a time, verified and enforced by the hardware.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#212171

Peter Flass <peter_flass@yahoo.com> wrote:
> <antispam@math.uni.wroc.pl> wrote:
> > 
> > That is part I want to understand.  It seems that access macros set
> > up control blocks in user space.  So user could tamper those control
> > blocks in arbitrary way.  
> 
> No, the DEBs were in an area with the system key.
> 
> > It is not entirely clear to me how system
> > ensured that access method will do its job.  
> 
> As I said, the supervisor ensured that any user I/O operation was limited
> to one cylinder at a time, verified and enforced by the hardware.

Yes, thanks.  What you (and David Wade) wrote explains this
part, without knowing about such limit it looked like a hole...

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#212172

On 30/06/2020 15:01, antispam@math.uni.wroc.pl wrote:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> <antispam@math.uni.wroc.pl> wrote:
>>>
>>> That is part I want to understand.  It seems that access macros set
>>> up control blocks in user space.  So user could tamper those control
>>> blocks in arbitrary way.
>>
>> No, the DEBs were in an area with the system key.
>>
>>> It is not entirely clear to me how system
>>> ensured that access method will do its job.
>>
>> As I said, the supervisor ensured that any user I/O operation was limited
>> to one cylinder at a time, verified and enforced by the hardware.
> 
> Yes, thanks.  What you (and David Wade) wrote explains this
> part, without knowing about such limit it looked like a hole...
> 
There were security holes, sometimes installed by the local site. So 
there might be "secret" SVCs that allowed you to issue arbitrary IOs to 
any device or do other privileged actions without checks,

Then I well remember having some what heated arguments because I changed 
the password from the default on the Customer Engineer account.

Sometimes I remember silly things. So I used to work on networking 
software for VM. The machines were connected to the UK university X25 
network so no fire walls, no address blocks. The software ran 
privileged. It did this so if users submitted transfers with invalid 
passwords it could reset the "bad password" count and it didn't killed.

Most sites just installed what I sent, so had I wished I could have 
popped a back door in the software that could have done anything on the 
system from my office.

However when things went wrong, they often refused to let me see the 
main console, in case I did anything I shouldn't.......

Dave

[toc] | [prev] | [next] | [standalone]

#212175

antispam@math.uni.wroc.pl wrote:


> 
> That is part I want to understand.  It seems that access macros set
> up control blocks in user space.  So user could tamper those control
> blocks in arbitrary way.  It is not entirely clear to me how system
> ensured that access method will do its job.
Anybody can write a channel program to do anything.  But, to get it EXECUTED 
by the channel, you have to call the Execute Channel Program Supervisor.  
The access method can do this for you, or you can call it directly.  The 
channel program checks for access to things you should not have before 
passing it on to be scheduled.

We had a tape recovery channel program that was hand-coded.  There were some 
sense switches on the mag tape control unit that were normally used for CE 
diagnostic purposes, but the channel could read them and make branches 
(Transfer In Channel) based on the switches.  So, you mounted two tapes, the 
OS gave you full access to the drives, and the channel program was started.  
It then looped, reading blocks from the source tape to the destination tape.  
When you saw it was retrying endlessly to read a block, you could flip one 
of the sense switches to tell it to either copy the block with the errors or 
to omit the block and continue.  The downside of this is it totally locked 
up not only the tape controller, but the entire channel the tape controller 
was on.  But, to recover a faulty tape, it was about the only quick and 
dirty way to do it.

Jon

[toc] | [prev] | [next] | [standalone]

#212154

In article <rddjkg$ffe$1@z-news.wcss.wroc.pl> you write:
>I wonder how much security was provided on early IBM mainframes.

Plenty, via a lock on the door to the computer room.

The user/supervisor security in OS/360 was intended to keep programs
from accidentally smashing the operating system or other programs, not
to keep determined intruders out. There was a well known two-line
Fortran program that would reliably crash OS/360 in the early 1970s,
and we all knew not to do that since it'd just make it take longer
until we got our printouts back.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#212155

John Levine <johnl@taugh.com> wrote:
> In article <rddjkg$ffe$1@z-news.wcss.wroc.pl> you write:
>> I wonder how much security was provided on early IBM mainframes.
> 
> Plenty, via a lock on the door to the computer room.
> 
> The user/supervisor security in OS/360 was intended to keep programs
> from accidentally smashing the operating system or other programs, not
> to keep determined intruders out. There was a well known two-line
> Fortran program that would reliably crash OS/360 in the early 1970s,
> and we all knew not to do that since it'd just make it take longer
> until we got our printouts back.
> 

Plus, they’d track you down and possibly expel you, or at least cancel your
account.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#212160

On 6/29/20 4:18 PM, John Levine wrote:
> There was a well known two-line Fortran program that would reliably 
> crash OS/360 in the early 1970s,

Is it wrong that I'd like to try that on MVS 3.8j running in Hercules 
emulator?



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#212162

On Monday, June 29, 2020 at 6:27:50 PM UTC-6, Grant Taylor wrote:
> On 6/29/20 4:18 PM, John Levine wrote:
> > There was a well known two-line Fortran program that would reliably 
> > crash OS/360 in the early 1970s,

> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules 
> emulator?

But by the time IBM got to MVS, they probably would have fixed the bug.

John Savard

[toc] | [prev] | [next] | [standalone]

#212169

On 30/06/2020 01:28, Grant Taylor wrote:
> On 6/29/20 4:18 PM, John Levine wrote:
>> There was a well known two-line Fortran program that would reliably 
>> crash OS/360 in the early 1970s,
> 
> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules 
> emulator?
> 
> 
> 
You can crash most early operating systems by filling the spool or temp 
space.

Dave

[toc] | [prev] | [next] | [standalone]

#212173

On 2020-06-30, David Wade <g4ugm@dave.invalid> wrote:

> On 30/06/2020 01:28, Grant Taylor wrote:
>
>> On 6/29/20 4:18 PM, John Levine wrote:
>>
>>> There was a well known two-line Fortran program that would reliably 
>>> crash OS/360 in the early 1970s,
>> 
>> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules 
>> emulator?
> 
> You can crash most early operating systems by filling the spool or temp 
> space.

An early version of Univac's OS/3 had a unique way of reacting to a
filled spool file: it would wrap around, losing everything in the process.

They fixed that bug fairly quickly.

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

#212184

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>On 2020-06-30, David Wade <g4ugm@dave.invalid> wrote:
>
>> On 30/06/2020 01:28, Grant Taylor wrote:
>>
>>> On 6/29/20 4:18 PM, John Levine wrote:
>>>
>>>> There was a well known two-line Fortran program that would reliably 
>>>> crash OS/360 in the early 1970s,
>>> 
>>> Is it wrong that I'd like to try that on MVS 3.8j running in Hercules 
>>> emulator?
>> 
>> You can crash most early operating systems by filling the spool or temp 
>> space.
>
>An early version of Univac's OS/3 had a unique way of reacting to a
>filled spool file: it would wrap around, losing everything in the process.

Burroughs systems would handle resource shortages by placing the job
in a wait state until the operator resolved the issue.   A resource
shortage would  never crash the MCP.

[toc] | [prev] | [next] | [standalone]

#212163

[x-post, followup back to a.f.c.]

John Levine <johnl@taugh.com> schrieb:
> There was a well known two-line
> Fortran program that would reliably crash OS/360 in the early 1970s,
> and we all knew not to do that since it'd just make it take longer
> until we got our printouts back.

Do you still have the source? :-)

[toc] | [prev] | [next] | [standalone]

#212166

On Tue, 30 Jun 2020 07:51:28 +0000, Thomas Koenig wrote:

> [x-post, followup back to a.f.c.]
> 
> John Levine <johnl@taugh.com> schrieb:
>> There was a well known two-line Fortran program that would reliably
>> crash OS/360 in the early 1970s,
>> and we all knew not to do that since it'd just make it take longer
>> until we got our printouts back.
> 
> Do you still have the source? :-)

There was a very short FORTRAN program in the early 1980s that would 
reliably crash our ICL 2960.

No matter what operating system it was running.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#212167

On Mon, 29 Jun 2020 20:40:48 +0000 (UTC)
antispam@math.uni.wroc.pl wrote:

> I wonder how much security was provided on early IBM mainframes.
> IIUC 360 series had distinction between supervisor and user (poblem
> state) mode and used key memory protection.  This in principle

	I have no details but at Cambridge the Titan was considered secure
and students were encouraged to attempt to break it - success was (we were
told) often rewarded with a job that involved closing the hole you used.

	The Titan was replaced by a 370 (165 IIRC) after which students
were no longer encouraged to attempt to break it and were instead advised
that it was far to easy to be a challenge and was instead a nuisance that
would get your access revoked. I was told that the shortest known program
that would crash it was half a word long - I never verified that claim.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

[toc] | [prev] | [next] | [standalone]

#212174

antispam@math.uni.wroc.pl wrote:

> I wonder how much security was provided on early IBM mainframes.
> IIUC 360 series had distinction between supervisor and user (poblem
> state) mode and used key memory protection. 

Yes, the hardware had the ability to enforce some security.  But the OS had 
massive holes.  The biggest one was the system for enabling a callback on a 
program exception.  There was a system call SPIE (Specifiy Program Interrupt 
Exit), and if an exception occurred, your specified exception handler got 
control with the PSW passed.  You could then change the PSW and return.  The 
default OS 360/MFT and /MVT supervisor calls for this allowed you to clear 
the P bit (problem state, meaning user program) and return, putting your 
program into supervisor mode!  AMAZING!  But, nobody at IBM ever thought of 
computer hackers.

Jon

[toc] | [prev] | [next] | [standalone]

#212176

Jon Elson <elson@pico-systems.com> wrote:
> antispam@math.uni.wroc.pl wrote:
> 
>> I wonder how much security was provided on early IBM mainframes.
>> IIUC 360 series had distinction between supervisor and user (poblem
>> state) mode and used key memory protection. 
> 
> Yes, the hardware had the ability to enforce some security.  But the OS had 
> massive holes.  The biggest one was the system for enabling a callback on a 
> program exception.  There was a system call SPIE (Specifiy Program Interrupt 
> Exit), and if an exception occurred, your specified exception handler got 
> control with the PSW passed.  You could then change the PSW and return.  The 
> default OS 360/MFT and /MVT supervisor calls for this allowed you to clear 
> the P bit (problem state, meaning user program) and return, putting your 
> program into supervisor mode!  AMAZING!  But, nobody at IBM ever thought of 
> computer hackers.

How much of a problem was this when the system was designed? Work on the
360 goes back to the start of the 60s, if not back to the 50s. In those
days computers were locked away and only staff had access, so I don’t think
there were hackers. by 64 it was more of a problem.

> 
> Jon
> 



-- 
Pete

[toc] | [prev] | [next] | [standalone]

#212177

On Tue, 30 Jun 2020 18:03:54 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

>Jon Elson <elson@pico-systems.com> wrote:
>> antispam@math.uni.wroc.pl wrote:
>> 
>>> I wonder how much security was provided on early IBM mainframes.
>>> IIUC 360 series had distinction between supervisor and user (poblem
>>> state) mode and used key memory protection. 
>> 
>> Yes, the hardware had the ability to enforce some security.  But the OS had 
>> massive holes.  The biggest one was the system for enabling a callback on a 
>> program exception.  There was a system call SPIE (Specifiy Program Interrupt 
>> Exit), and if an exception occurred, your specified exception handler got 
>> control with the PSW passed.  You could then change the PSW and return.  The 
>> default OS 360/MFT and /MVT supervisor calls for this allowed you to clear 
>> the P bit (problem state, meaning user program) and return, putting your 
>> program into supervisor mode!  AMAZING!  But, nobody at IBM ever thought of 
>> computer hackers.
>
>How much of a problem was this when the system was designed? Work on the
>360 goes back to the start of the 60s, if not back to the 50s. In those
>days computers were locked away and only staff had access, so I don’t think
>there were hackers. by 64 it was more of a problem.

For certain values.  A crooked employee would still be a problem, just
easier to catch and less likely to get away with it.

[toc] | [prev] | [next] | [standalone]

#212178

In article <hbtnfflqu2nqedirnhhs30vh9ouu9ioa5k@4ax.com>,
J. Clarke  <jclarke.873638@gmail.com> wrote:
>>How much of a problem was this when the system was designed? Work on the
>>360 goes back to the start of the 60s, if not back to the 50s. In those
>>days computers were locked away and only staff had access, so I don’t think
>>there were hackers. by 64 it was more of a problem.
>
>For certain values.  A crooked employee would still be a problem, just
>easier to catch and less likely to get away with it.

A crooked employee didn't need operating system security bugs. I'd
think they'd do things like drop a few fake cards into the nightly
accounting update run.


-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web