[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[school-discuss] Re: sociopaths and security and software (was: Lines of code) (long)
I've copied this message to the SchoolForge and ALLIES lists in case any
of their denizens want to cut and past (in which case, feel free and
don't worry about attribution).
This started short, simple and to the point, then spontaneously broke
out the soapbox and grew "like Topsy". It doesn't feel finished, but I
have too much on my plate to turn it into a proper article and it may
be useful as it is anyway.
Here's an interesting bit of philosophy (a truism, I think) to ponder
upon before I dig in:
Those who sincerely desire truth will not be reluctant to lay
open their positions for investigation and criticism, and will
not be annoyed if their opinions and ideas are crossed.
If you disagree with what I say, tell me (off list if your mercury's
about to leave the bulb) so I can fix it.
On Sun, 28 Mar 2004 17:01, Ken Hopkins wrote:
> Perhaps all the sociopaths who write viruses prefer to use Windows,
> whereas those who use other operating systems are more well adjusted
> and not inherently sociopathic.
SECURITY AND MS-WINDOWS
My theory is that on MS Windows, all of the security was bolted on
afterwards - as part of the Long March from MS-DOS - whereas on UNIXy
systems a fundamental concept of security and partitioning of
responsibilities has always been there.
MS Windows NT *ought* to have been very secure, since it was at first
spelling-error compatible with a VMS 5 derivative called MICA, and VMS
came with top military-grade security features. What I think happened
is that in making it Windows-3-ish enough to look like and be called
"Windows", the fundamental security aspects got trampled in the rush
[see rant in footnote 1].
SECURITY AND UBIQUITY
Having said that, part of the reason that so much malware is targeted at
MS Windows is because that's what the malefactor has sitting in front
of him. Every little PC retailer in the world defaults to the system
which suffers the most abuse, which of course contributes to the
perpetuation of the abuse cycle.
Intelligent but bored and sociopathic teenagers (and IMESHO teenagers
are no more sociopathic than the rest of us, they're just more visible
and more often reported) are not typically sitting in front of the more
expensive Macintoshes or better secured Linux boxes in this world,
they've normally only got MS Windows.
Not hard to guess why MSWin is pushing towards 100,000 different viruses
so far, while the others have hardly got two trojans to rub together.
SECURITY AND LINUX
As Linux becomes more widely available, dangerous people will get in
front of it more often, but they face two major barriers, diversity and
security.
Because Linux *defaults* to better security than MS Windows, it's more
difficult for a casual user to install the compilers and such that they
need to do real cross-platform damage, and easier for an administrator
to detect and thwart any such attempts [see footnote 2].
Diversity means that if a user writes nastyware, it not only has to have
sixty gazillion different messages and forms to fool people into
opening it, it also has to work on at least a dozen different email
clients, on a handful of different platforms, and with no uniform way
to grab administrator rights or set up services on standard network
ports.
If a trojan can't achieve that, penetration will be very limited, and
the code to detect and operate in all of these various environments is
neither simple nor small. We've already seen attempts (like SadMind) at
this market, the worms have been huge and their impact has been small.
That problem leaves malefactors facing the ultimate goal of most
security systems: "It's just too hard, go somewhere else".
"Somewhere else" is a single email client on a single architecture
supported by four or five variants of a single operating system.
Outlook, x86, MS Windows (the dwindling 98, plus 2000, XP, 2003).
SECURITY AND DIVERSITY
This playground for nasties is a market which has begun shrinking. Like
an avalanche, the first movements are gradual, almost gentle, hardly
noticeable; like an avalanche, standing in the way is utterly futile.
This is a disaster from a malefactor's point of view, and Linux is also
the icebreaker for other operating systems (like the BSDs), which will
only make malefactors' diversity problem even bigger.
DIVERSITY AND APPLICATIONS
On the other hand - from a developer's point of view - unless the app
you're developing is an email client extension or similar the diversity
issue's pretty much invisible.
The upside of diversity is that you target your application at a library
like Qt or libSDL instead of a specific OS or platform, so your app
need never know or care what processor or version of Linux it's running
under. Or MacOS, BSD, MS Windows, VMS etc.
As far as the application is concerned, it doesn't need to know or care
whether it's running on a full GUI, on the face of a 3D object, as a
browser plugin, or in a frame buffer; locally or remotely; a
thousand-CPU SGI Altix or the Zaurus in my hand. That's the library's
problem.
Fixing a bug in the library fixes the same bug in every application
based on the library. One recompile and we're out of here. Interpretive
languages like Ruby, Python, Java or PERL don't even need that much.
Think about it in terms the programs you build for your classroom. Write
an app in VB for DirectX and you're limited to MS Windows, probably
even specific versions of some things, and anyone who wants to expand
on it is too. Use special application libraries, ActiveX controls or
whatever and your userbase is also blinkered.
But write the same app in Python for libSDL and it'll run on Mac and
Linux, as a bonus. The Mac-based music lab can use it as easily as the
Wintel-based business lab. Your poorer students can use it on their
ComputerAngels systems at home. Not only that, Fred Nerk on the other
side of the country might want to add to it, and he can - and you can
use Fred's extended version without complications.
SOCIAL AND POLITICAL SECURITY
This cross-pollination is the antithesis of Microsoft's locked-in
top-down monoculture, and it's a big collection of reasons why
targeting your educational or other application at a proprietary
platform isn't such a good idea. If you do that, it's not just bored
teenage crackers who get to muck around with your digital life.
A second big reason is also control related. If your sole supplier of
platform support goes broke, gets sued into the ground, gets bought and
closed down or "improved" off the map, winds up on the other side of a
war or trade embargo, or simply changes its mind about the viability of
that particular product, your application becomes an historical
footnote too.
For a system like Flash, that's not so bad as long as you stick to a
moderate common feature set rather than constantly surfing the bleeding
edge, since there are Open players and authoring tools around which you
could use to press on even if Macromedia imploded [see footnote 3].
For something based on VB and/or .NET and/or Win9X, Microsoft pulling
the Big Red Switch on it (or something else BRSing MS) would be pretty
catastrophic.
Something along these lines was done by Microsoft a little while ago to
a peer of mine, who had to spend a year without pay rewriting an
application to suit the changed conditions because his contract had
been written so that the client didn't wear any of the consequences of
Microsoft's actions. A year without pay is not an easy thing to do.
DIVERSITY AND OPEN SOURCE DEVELOPERS
The hard part of adopting a 100% laterally-oriented, Open approach for a
teacher is currently twofold: giving up some neato specialised toys
like game toolkits and having to deal with the absence of some of the
highly polished interfaces which a dedicated (but narrowly focussed)
closed-source application typically possesses.
The message in that for Open Source developers is: we've got enough text
editors, email programs, Tetris and Othello games now. Enough wheels
have been reinvented. Do you want to make yourself really useful in the
edu or home sectors? Pick a specialised app - a game toolkit, 3d
animator, music editor or whatever - and polish that up, round it off.
Or pick a non-FOSS education or edutainment app (like The Incredible
Machine or Dorling-Kindersley-like demi-products) and start writing an
Open version of it or toolkits to produce them [see footnote 4]. Or
talk to some teachers and see what would be "nice to be able to do"
that they currently can't.
You're not a programmer? Excellent! Open Source needs more like you!
We need people who can write stuff, you know, words and things. People
who can walk through programs, make screenshots and note down what's
happening. People who can draw stuff. People who can try stuff out.
People who can take a nifty application framework and start fleshing it
out with samples, tutorials and examples. People who can put real
course material into courseware. People who can haunt mailing lists and
nursemaid newbies, triaging misconceptions and bugs, documenting one
and prompting the newbie for enough information to solve the other. And
so on. The kind of stuff you do in and for your class every week, and
you're getting really quite proficient at by now. (-:
All of these things will help to bring more sociable software into your
classroom - or from the opposite perspective, help your favourite
software to escape from server rooms and wiring closets into everyday
life.
MAKE A PLAN
The last step before beginning is to decide how to do this thing. A good
general position to open with is to find and try out one Open Source
project a week. Read the help (start with a README or FAQ if there is
one), install it, see how you go. If you have trouble getting it going,
write to the author(s) and say so. If the documentation's not clear,
suggest a paragraph or two for the author to add to clarify things.
If you're a writer at heart, write a review of it. Collect these reviews
and put them on a website (maybe an appropriate wiki, or send them to a
site which will put them up for you).
If you find a project that you like, and whose author(s) is/are
responsive, stick with it for a while and see how much you can do. If
you like it but the author(s) aren't responsive or maybe can't even be
contacted, have a whack at adopting or forking (splitting off) the
project.
If you don't like it or it's too hard, quietly move on to the next one.
It might turn out that you never throw yourself deeply into a project,
but your nudge here, suggestion there, page of text somewhere else all
add up.
Every so often, maybe once a year, think about starting a project of
your own. Start small, think about what worked and did not work for you
with the projects you've toyed with. Whack together the bones of a
project and put it on the 'net. If you've nowhere to host it, try
SourceForge, Savannah, or any of the dozens of sites out there
established to do just that.
Where do you find the time for this? Employ those otherwise wasted hours
between midnight and dawn? No, just switch off the boob tube one night
a week. When anything important happens, your friends tell you.
Cheers; Leon
FOOTNOTE 1: WINDOWS NT VS UNIX SECURITY RANT
The Registry, for a shining example, is a honking great security hole on
wheels and should've been done as a file/directory tree and later - if
it was ever really necessary - written into a database instead of the
files. That way, the filesystem security could be applied orthogonally
to registry entries instead of being reinvented. One well-established
set of tools, one set of security holes, one way of writing programs
instead of two asymmetrical ways, one of them brand new and completely
ignorant of security. The internal structure of MS Exchange looks and
feels broken in pretty much the same way.
The UNIX approach is to read configuration from a system directory
(typically /etc/programname.conf or /etc/servicename/programname.conf
on Linux, IRIX, many others) and then adjust it - if permitted - from a
file in the user's home directory (typically .programname). If the user
wants to change something, they can write it into their file, which
they own. They don't need write access to a whole registry.
Because that method is based on the filesystem, a whole sheaf of mature
filesystem-related tools are available to administrators for managing
it, and to pull fancy tricks at will. If they break anything, the
damage is typically limited to one service, or one user. To achieve the
same level of flexibility in MS Windows would require modifying and
recompiling the operating system code, and a mistake here will
typically kill the whole operating environment.
FOOTNOTE 2: DETECTING AND THWARTING CRACKERS
It is trivial to make any place that a user can write stuff be
non-executable. This means that crackers can download, unpack and
compile stuff, but it won't run. Boring users storing their
wordprocessor documents, spreadsheets, pictures and music on your
server won't ever know or notice.
Using SELinux, you can even give crackers the administrator (root)
password and they're still helpless to do anything you don't let them
do. Try it: http://www.coker.com.au/selinux/play.html
FOOTNOTE 3: THE IMPLOSION OF MACROMEDIA
I don't expect them to implode. They are moving to address the Linux
market, which means that they'll have a meal ticket regardless of the
corporate fortunes of Microsoft and Apple.
Look for a rush of other software suppliers hedging their futures this
year and next.
The SCO Group, though, I do expect to implode. Shares down around eight
US dollars and generally falling. Unix business down the toilet and
blackmail business not looking good either, with their first genuine
customer publicly repudiating their licence.
FOOTNOTE 4: EXAMPLE "VERTICAL" APPLICATION
I can think of one example application straight away. Many educational
and edutainment systems have a navigation system which is a variant of
"click on the alligator to find out more about reptiles, click on the
toucan to find out more about birds...". It is dead simple to lay out
these screens in The GIMP and mark up the active objects either as
separate layers or with the imagemap plugin.
(Alternatively, you can also prototype such a system in OpenOffice
Impress, linking the alligator image to a page on reptiles, the toucan
image to a page on birds etc with the "Interaction" settings. The
result can also be portably if messily presented as an HTML slideshow)
It would take very little effort to extend this to produce a GIMP plugin
which allowed you to build an application's entire navigational system
from one interface, and spit out the result in many formats including
as a set of portable web pages navigable by any modern browser. You
don't even need javascript to produce a reasonably pleasant end-user
experience.
For fancy stuff, you could also or alternatively write a framework based
on a portable graphics library into which _any_ teacher can drop
information - text, pictures, video clips and sounds - to produce a
self-contained "deliverable" CD, a student-paced teaching tool.
Eliminating the repetitive work in setting up the navigation and other
infrastructure leaves the teacher free to think about the information
itself, what's needed and how to arrange it.
A dozen or so carefully chosen utilities like this to bridge the gaps
between what we have now and what teachers want to be able to do
without programming would be a massive enabler for the teachers, much
more useful than the perfect AIM client - especially if it could be
obtained without red tape and installed on whatever working computers
were handy - and it would be an unbeatable "marketing" tool for people
producing or delivering FOSS-based systems.
--
http://cyberknights.com.au/ Modern tools; traditional dedication
http://plug.linux.org.au/ Vice President, Perth Linux User Group
http://slpwa.asn.au/ Committee Member, Linux Professionals WA
http://linux.org.au/ Past Committee Member, Linux Australia
http://osia.opensource.org.au/ Member, Open Source Industry Association