Domain: pbm.com
Stories and comments across the archive that link to pbm.com.
Comments · 104
-
Real Programmers
For some reason, it feels right to post this.
-
The Story Of Mel
For all of those who haven't read it, or want to again, this is a good story about cool code, and a cool coder.
This is the Google search I found it with.
The real Eight Star misses Technocrat. -
Things that make Linux harder/easier to attackThings that make Linux harder to attack:
- There are an enormous number of slightly different compiles of the kernel and various commonly used programs out there. Because everyone can get the source, every distribution and many users compile it for themselves. This is going to mean that a virus that attacks a binary is likely to simply break it on at least some subset of systems, making detection relatively easy.
- The Linux security model is different from that of Windows. If you aren't running as root or another account with access to various things, such as bin, there are a lot of files you just can't change.
- Different distributions structure their configurations differently. This makes targetting rc scripts harder, but not impossible.
- Because a large part of the configuration is found in scripts and text files, detecting the damage and determining what was done is potentially more straightforward. Joe Average User may not find it, but the local Users' Group can probably track the source of the problem for him.
- Because we all have documentation for the configuration of everything, building tools that detect subtle changes and keep archived copies of config files is something a good and thorough programmer on a tight budget can do.
- Because we have source, proving that you are a Real Programmer on an Open Source OS can be accomplished by a number of constructive avenues that are only available through Open Source. These may reduce the number of people seeking attention in negative ways
... maybe.
Some things that are going to make Linux easier to attack:
- J. Virus Writer has access to full documentation and source for the programs he wants to attack. Finding the existance of buffers that can be overrun and the consequences is not a trial and error effort.
- Text is easy to manipulate and most config files and start-up scripts are text. Thus, the virus can do its work by spawning sed, perl, awk, ed, emacs or several other tools. Those scripts are likely to be smaller and more portable across releases and distributions than the equivalent binaries. And they can be embedded in binaries.
- LILO. Somebody who can install a hacked version of LILO can do some damage. And the LILO config is easy enough to edit. See my previous point.
- Trusted binaries can be compromised in useful ways, as described by Ken Thompson in Reflections on Trusting Trust. I have some thoughts on how to make such a compromised binary nearly undetectable on the system on which it was built. I won't detail them here.
One of the things that I notice about Linux is that there is some overlap between these lists. It seems to point to the idea of tamper-evident packaging.
The bottom line is that there will be people who will do destructive things. There will be security holes that they will take advantage of. There is a need for security conscious people willing to patch them. A virus is just one way of taking advantage of security holes. -
I have to at least suggest TECOYes, TECO. To quote Real Programmers Don't Use Pascal:
Some of the concepts in these Xerox editors have been incorporated into editors running on more reasonably named operating systems-- EMACS and VI being two. The problem with these editors is that Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in Women. No, the Real Programmer wants a "you asked for it, you got it" text editor-- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.
It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text[4]. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse-- introduce subtle and mysterious bugs in a once working subroutine.