[NCLUG] Re: Who uses SUDO on production machines?

[John L. Bass]

Hi Mike!!!

Awesome security perspective from the trenches :)

	And always verify your backups.

Boy that is something that really needs to be said, and often.
And if you expect your backups to be archival, verify them
regularly.

I've done computer security work since I first became a systems programmer
nearly 40 years ago, from both sides of the fence. Probably the best fun
was a year of faculty sponsored security research (as CS400 Independent
Study) into the ongoing security problems of the Colorado State University
network which spanned all 19 campuses. The team I assembled (Charlie, Ken,
and Mark) had the shield of the CS department head, against the loud and
frequent protests of the state data center. We got formed, after our campus
had been framed by two other underground groups of hackers/crackers on
other campuses, so we started out as the "known guilty party" from the
data centers persepctive, and it didn't get much better from there. We
were all employees of the campus data center or various departments, so
we had better access to the campus facilities than your typical student.

It took us a couple months of digging underground to locate the guilty
teams, and after long discussions with our faculty, decided to shield
them from exposure, and play the game out. We established a friendly
relationship with both teams, bartering information, documentation,
exploits, and other experiences, which quietly feeding the exploits
to the systems vendor as a series of bug reports and later outright
source fixes as we became more skilled. We disassembled the entire OS
and Utilities in about 6 months, after finding the public domain
sources that were the foundation for the original operating system
(the Xerox XDS940 timesharing system done as a DARPA and NSF contract).
After a year, we finally had both other teams completely locked out,
and had discovered a critical design flaw the vendor was unable to
correct without a major rewrite ... a shared interrupt stack between
the kernel and the application process, that allowed taking direct
control of the machine by hooking the OS's interrupt returns.

We were handed a UNIX V6 distribution tape, and a PDP11/35 graphics
system, and I became a UNIX systems programmer instead, writing UNIX
drivers for the various graphics devices as we moved the applications
from RSX/11 to UNIX. I continued working as an IBM360/370 systems
programmer for several more years in various Los Angeles shops to
put me thru school, and managed the school UNIX system, till I finally
landed a commercial UNIX kernel systems programmer job in 1976, which
I did in various forms for another 20 years.

In teaching teams to be security aware, frequently the hardest thing
is getting them to start thinking from the attackers perspective. As
techies we all know where we've put our energies to make the system
robust and secure, it's harder to get that same team to start thinking
in terms of locating faults, weaknesses, and especially unexpected
uses/attacks on that same system.

A very useful training tool is to brainstorm how to take the company
out, or how to steal the crown jewels, and get away with it. It generally
takes a few months before the ideas start getting really creative, and
serious flaws start to appear. Weekend beer parties help too :)

Have fun!
John