[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.


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].


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.


As Linux becomes more widely available, dangerous people will get in 
front of it more often, but they face two major barriers, diversity and 

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 

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).


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.


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 

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.


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 

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.


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 


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 

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


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.


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


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.


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 

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