Sat Feb 8 11:28:10 GMT 2003

• Kasparov vs Deep Junior ends in a draw
• Security experts duped by Slammer 'jihad' rot
• Downing St copies US student's thesis

Thu Feb 6 18:39:50 GMT 2003

• Bram: first release of new project, Codeville

As I'm sure some people have noticed (except those on RSS feeds) I've trimmed the header of the site on the advice of Etienne because the top post ended up too far down. Thanks Etienne.

The scripts which generate this site really need updating too. One feature I would like to add is the ability to view all the blog content relating to a topic. This requires that I go and tag all my past entries, but there aren't too many of those.

In other news, the local LUG held their InstallFest yesterday which, by all accounts, went pretty well. Debian (3.0 with some sid stuff like KDE3.1) was the default install, though some people opted for SuSE 8.1 instead. I think we only trashed one hard drive with Partition Magic.

Building on an idea from one the CSG people I've half implemented an IMAP server which does caching of an mbox. Email here is all mbox format for a number of hard-to-change reasons and the current uw-crap server parses the whole thing every time. By keeping a cache of the structure you can speed things up a lot as the mboxes are over NFS. Fast deleting is a pain, but doable.

However, IMAP is evil (as documented below) and I can't really be bothered to finish the protocol implementation. The interesting bits are done and I might put a POP interface on it and stick it on IV.

The server is built in Twisted Python which is a really nice framework. I'll write something about this soon. (the mbox hackery is a C module, however)

In the meantime, I'm looking at securing NFS.

Mon Feb 3 17:14:14 GMT 2003

To the tune of 'If You're Happy And You Know It'
All together now.......

If you cannot find Osama, bomb Iraq.
If the markets are a drama, bomb Iraq.
If the terrorists are frisky,
Pakistan is looking shifty,
North Korea is too risky,
Bomb Iraq.

If we have no allies with us, bomb Iraq.
If we think that someone's dissed us, bomb Iraq.
So to hell with the inspections,
Let's look tough for the elections,
Close your mind and take directions,
Bomb Iraq.

It's pre-emptive non-aggression, bomb Iraq.
To prevent this mass destruction, bomb Iraq.
They've got weapons we can't see,
And that's all the proof we need,
If they're not there, they must be,
Bomb Iraq.

If you never were elected, bomb Iraq.
If your mood is quite dejected, bomb Iraq.
If you think Saddam's gone mad,
With the weapons that he had,
And he tried to kill your dad,
Bomb Iraq.

If corporate fraud is growin', bomb Iraq.
If your ties to it are showin', bomb Iraq.
If your politics are sleazy,
And hiding that ain't easy,
And your manhood's getting queasy,
Bomb Iraq.

Fall in line and follow orders, bomb Iraq.
For our might knows not our borders, bomb Iraq.
Disagree? We'll call it treason,
Let's make war not love this season,
Even if we have no reason,
Bomb Iraq.

Mon Feb 3 16:51:14 GMT 2003

Below is the text of an email I sent to the p2p-hackers list:

On Mon, Feb 03, 2003 at 12:04:34AM -0500, Seth Johnson wrote:
> Tell American Megatrends and Transmeta not to make chips
> that let others control your computer!

This is sensationalist and wrong. TCPA chips do not let other people `control
your computer', in fact the abilities of the TCPA chip are rather limited.
It would help if you read the spec for TCPA (http://www.trustedcomputing.org/)
before posting such stuff, but I will admit that the TCPA spec is a wonderful
example of exactly how not to write a spec. I'm sure much of the 
min-understanding of TCPA is due to the poor quality of this document.

Also see
http://www.research.ibm.com/gsal/tcpa/
for a wonderful work about TCPA which may alay some of your fears.

> Palladium and TCPA would hardwire your home computer so that
> these four entities and their partners would be able to run
> processes on your computer, entirely outside your control,
> indeed, without your knowledge.

If you are running Windows this pretty much happens already.

> The mechanics are as follows: only code that has been signed
> with a special Microsoft provided key will run. Microsoft
> will retain at all times the power to revoke any other
> entity's keys. In particular, no operating system will be
> able to boot without a key from Microsoft. So if Palladium
> is forced into every home computer, there will be no more
> free software. 

Total crap. It M$ wish to implement code signing in Windows they can do that
with or without TCPA .  TCPA allows you to seal data and only unseal it when
booted in the same configuration. It also allows you to `prove' to another
party that you are running a given configuration (with a number of assumptions)
"The TCPA chip doesn t execute anything. It accepts request data, and replies
with response data. The TCPA chip does not and cannot control execution!"
(IBM paper). *TCPA chips do not prevent free-software running on the computer*

> Microsoft will be able to spy on each and every keystroke,
> and mouse movement, and send encrypted messages from your
> machine to Microsoft headquarters. Microsoft will also be
> able to examine every file on your system.

As they can (and, by some accounts, do) currently.

> Your encryption
> programs will not work against Microsoft, or any other
> entities which have full power keys from Microsoft. 

Utter crap again. TCPA does not alter mathematical reality. Boot Linux
and encrypt all you like.

> There are two reasons most people will not be able to escape
> the All Seeing Eye and Invisible Hand of Palladium. 

You are mixing up Palladium and TCPA. And we don't even have details on
Palladium yet.

> Once Microsoft and Intel have forced Palladiated hardware
> into every personal computer, it will be impossible to run a
> free OS. 

Rubbish. See above.

Now, TCPA does allow some nasty things to happen. See
http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf
for an example of `content providers' using TCPA to only trust a computer
running a given OS. But, personally, I would like a TCPA system. That way I
can encrypt my filesystem and store the key in the TPM; which would only
decrypt it when my kernel was booted. As a crypto junkie that appeals quite a
lot.

Sun Feb 2 10:31:35 GMT 2003

• Sanity in the legal wilderness (e.g. copyright law).

I've had cause to read the IMAP RFC rather a lot recently and it's a pretty good example of what not to do when deigning a protocol.

For example, in the FETCH command:

ALL: Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

Do they really think that people are going to be using raw IMAP with a telnet client so often that these shortcuts are going to be useful? It's not exactly damaging, it's just stupid and a clear indication that the designers didn't understand protocol design

The point of protocol design it's to get all the required functionality in there. It's to do that with the minimum number of primitives

Now sometimes those primitives are pretty large and performance dictates that they shouldn't be broken down any further. But IMAP certainly cannot claim that it has hit that barrier.

Also, IMAP servers are supposed to parse MIME and present a breakdown to the client, the point being that the client doesn't have to fetch the whole message. Desirable functionality, but commands for fetching and substring searching in a byte range would allow clients to do that and not burden the server with the very-much-client-side-total-mess that is MIME. And this type of thing litters the IMAP protocol.

Fri Jan 31 19:22:48 GMT 2003

Now hosted on Imperial servers. Cheers CSG.

Thu Jan 30 23:35:30 GMT 2003

As of this weekend, metis.imperialviolet.org will cease to be. Physically it will remain, but behind a NAT, ticking away in quiet invisibility.

Specificed and built by myself it has been running pretty much flawlessly since inception. Downtime was generally not its fault:

• Powercuts (many of these)
• Upstream network failures
• Upstream's promises of a static IP address failing (many of these)
• PSU fan failure cause it to overhead an die every few hours (I guess you could call that its fault)
• Rats pissing in the PSU and shorting it out (I kid you not)

Goodbye, good server.

(this may well mean that imperialviolet as a website will be down over the weekend. Email will continue to work)

Mon Jan 27 17:04:34 GMT 2003

• A Conversation with Virtual Reality Pioneer Jaron Lanier, Part One
• The Scientist and Engineer's Guide to Digital Signal Processing
• More secure NFS
• Building a compiler

Note to self: Keep a GRUB boot disk about because the bootloader is never on the disk you think it is

Theo Hong is a fellow Freeneter whom I fist met at the first O'Reilly P2P conference. He was also nice enough to show me round Imperial last year when I was considering universities. I thought he had headed off to Boston at the beginning of the academic year but someone remarked today that he was still here. And indeed he is!. Woo!

Sun Jan 26 19:55:02 GMT 2003

I was a technical reviewer for UNIX Power Tools (3rd Ed) and, while cleaning out an old drive today, I found the sketch I did for the security chapter. For those who own the book, I thought that chapter 48 needed serious work and did a sketch to show what I would have liked in it's place. Anyway, the editor disagreed so I might as well post that sketch here.

* Attack Models

Any discussion of security must first at least give a passing nod to the idea
of who your attacker is. The decisions you make concerning security
will largely be based on how well funded, motivated and powerful your
attacker is. The security needs of government computers are very
different to the Amstrad that someone occasionally uses to type a
letter.

For a computer connected to the Internet the profile of your average
attacker will be a mostly unmotivated, largely unskilled individual
(unless you have special reason to think you are a high profile
target). Unfortunately there are many attackers on the Internet using
automated tools which exploit vulnerable software automatically. For
this reason all networked computers should be secured against this
kind of threat and prepared in the event of a breach.

* Least-Privilege

The principle of least-privilege states that something should have the
ability to carry out its task and no more. This seems like a simple
idea and easily obtainable but in practice is often violated.

All processes run with a UID, GID and are members of certain
groups. For example when you (say, UID=1000) run /bin/ls a process is
created which inherits your UID, GID and groups and the image of
/bin/ls is loaded and executed. The ls process may then do anything
which you could do. This is an example of a violation of least
privilege as there is no need, for example, for ls to be able to
alter any files.

No security model is perfect and we have to live with the limitations of
the UNIX security model on UNIX based systems. 

* Physical Security

A comprehensive coverage of this topic is outside the scope of this book, but
if you cannot secure the physical computer then no amount of clever software
is going to help. Ideally the computer will be in a locked room with
dedicated power and air conditioning but, unless you are cohosting,
this is very unlikely. Most physical situations are far from ideal and
you should always keep this in the back of your mind.

You may wish to read Security Engineering by R. Anderson for an interesting
and detailed coverage of physical security (among other topics).

** Booting Security

The first vulnerable point is before the operating system has even
loaded. Most computers will boot from a floppy disk first, by
default. It requires physical access, but if an attacker can boot off
their own kernel they have free reign over the system. At the very
least you should change the booting options to only boot from the hard disk
and set a BIOS password. Remember that a BIOS password can usually be
cleared by shorting a jumper on the motherboard, however.

The next stage to be concerned with is the boot loader which actually
loads a kernel from the disk and runs it. At this point an attack may
be able alter the boot sequence and bypass normal protections. For
example, passing the option "init=/bin/sh" to a Linux kernel will
cause it to drop to a root shell after the kernel has loaded.

Boot loaders vary with the flavour of UNIX, investigate the man-page
for yours to find what security features it has.

* Unneeded services

Many default installs are guilty of running far too many unneeded
services by default. These generally remain unused and serve no
purpose except to provide more possible entry points for an attacker.

The first place to look is in /etc/inetd.conf. As a general rule of
thumb you should comment out every service which you don't know that
you require. Once you have done this (and every time you edit
inetd.conf) you should send a SIGHUP to the inetd process.

Often inetd will not be running any services in which case you can
disable it.

You should also check for other services with `ps auxw`,
`netstat -l` and `lsof -i`. These services will have been started by
your init scripts and you should consult the documentation for your
system for disabling them.

* Securing needed services

Most systems will have a number of services which need to be running
in order to function. Given that they are a necessity we must now
turn to making them as secure as possible.

The first question is which software are you going to use to perform
the required tasks. Many services have a de-facto daemon that is
usually installed to provide them. However, these de-facto choices
often are not the most secure and you may wish to investigate others.

For example, sendmail is the de-facto daemon to provide email
services. However, it has a long history of security problems and a
fundamentally bad design which violates least-privilege. If you need
some advanced mail handing capability it might be that only sendmail
will do. However, in nearly all cases packages such as qmail and
postfix will do the job and these have been designed from the ground up with
security in mind.

** Dropping root

Many daemons will give you the option of switching to a non-root user
once they have started up (setuid). This gives it the ability to perform some root
tasks at startup and then prevent itself from issuing any more. If the
server is compromised in operation the attacker gains control of a
process running as a dummy user - much less damaging than a root compromise.
For example a daemon may bind to a low numbered port (which requires
root privileges) and then switch to a non-root user while retaining
the socket in its file descriptor table.

When offered you should always use a setuid option. You should,
however, create a different user for each service. Many systems have
an account called nobody that services often run under. But if nobody
owns processes (and possibly files) then nobody is somebody! By
confining each process to its own user you contain the service.

* Chroot and jails

The chroot system call changes the root directory for a
process. Normally the root directory for a process is the systems root
directory with the path "/". However by chrooting a process you can
confine a process's view of the file-system so a given subdirectory.

Note: After a chroot the current directory of a process may still be
outside the new root file-system.

** Example chrooting Apache

There are 2 stages to chrooting a daemon. The first is to reconfigure
the daemon for the new paths. The second is to setup a minimal
environment for the daemon to run in.

For this example I'll be configuring apache in a temporary directory
in my home. For a real server you'll want to put it a different
directory (I use /jail).

This example uses the chroot system call. Your system may provide
other, similar calls such as jail. See the man pages for these calls.

*** Building Apache

Download an apache tarball from your favourite mirror and expand
it. I'm using version 1.3.26 here.

% cd ~/src
% tar xzf apache_1.3.26.tar.gz
% cd apache_1.3.26
% ./configure --prefix=/home/agl/tmp/apache
% make
% make install

You may wish to add other options to the configure command line to
enable your favourite mod_foo.

Now we reconfigure apache to expect the different path names. Since
/home/agl/tmp/apache is going to be the new root apache will see paths
like /htdocs.

Apache's startup script is a shell script so we are going to need a
shell in our root to run it. Since this is a Linux box I'm going to be
using bash. If you have a real Bourne shell you may wish to use that instead.

% cd ~/tmp/apache
% vim /bin/apachectl

We need to change 3 lines in this file and add one. Change the shebang
line to expect a shell in the root directory and a couple of the
paths. We also add a -f option to httpd to tell it where its config
file is.

#!/bin/sh -> #!/bash
PIDFILE=/home/agl/tmp/apache/logs/httpd.pid -> PIDFILE=/logs/httpd.pid
HTTPD=/home/agl/tmp/apache/bin/httpd -> HTTPD="/bin/httpd -f /conf/httpd.conf"

Now, just before the line which reads "ERROR=0" insert a line reading
"cd /". This sets the current directory to be inside the jail.

We we need to remove the string "/home/agl/tmp/apache" every time it
appears in conf/httpd.conf. Use your favourite text editor, or do

% vim conf/httpd.conf
:%s!/home/agl/tmp/apache!!

You also need to find the User and Group directives in this file and
change them to read

User apache
Group apache

Now we come to the second part of setting up a chroot jail - creating
the environment. Foremost in our mind are the user and group names we
just told apache to use. It needs to be able to turn these into real
UIDs and GIDs. For this it needs an /etc/passwd and /etc/group in the
jail. However, I recommend that you also setup a user and group in the
main passwd and group files with a sensible name so processes outside
the jail can make sense of the httpd processes inside (for example, ps).

In etc/passwd put

apache:x:65534:65534:nobody:/home:/bin/sh

and in etc/group put

apache:x:65534:

Now set the permissions

% chmod 664 etc/passwd etc/group

All modern systems support some kind of runtime linking of
libraries. In order to run apache and bash we need to copy the
libraries they require. These requirements vary greatly but the ldd
command will generally reveal all the requirements.

% ldd ../bin/httpd
	libm.so.6 => /lib/libm.so.6 (0x00136000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0x00158000)
	libc.so.6 => /lib/libc.so.6 (0x00185000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000)
% mkdir lib
% cd lib
% cp /lib/ld-linux.so.2 .
% cp /lib/libc.so.6 .
% cp /lib/libcrypt.so.1 .
% cp /lib/libm.so.6 .
% ldd /bin/bash
	libncurses.so.5 => /lib/libncurses.so.5 (0x00136000)
	libdl.so.2 => /lib/libdl.so.2 (0x00174000)
	libc.so.6 => /lib/libc.so.6 (0x00178000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000)
% cp /lib/libncurses.so.5 .
% cp /lib/libdl.so.2 .
% cp /lib/libnss_files.so.2 .
% cd ..

The last library isn't mentioned by any ldd listing, but glibc loads
it on the fly to read /etc/passwd and /etc/group. Now we copy bash and
cat into the jail (apachectl uses cat) and create /dev/null.

% cp /bin/bash .
% cp /bin/cat bin
% mkdir dev
% su
# cp -a /dev/null dev

That's the environment completed. Apache can be run by

# chroot . ./bin/apachectl start

* Limits

Resource limits are required on any secure system - especially
multi-user systems. Without them (and they are often disabled by
default) users may use up so many resources that critical systems are
unable to function and service is denied to others.

A simple example is a fork bomb. The following line of C code will
bring systems without resource limits to their needs - sometimes
requiring a power cycle to recover.

	  for (;;) fork ();

There are two many types of resource limit - quota and limits.conf

** Limits.conf

This file describes the limits placed on users for resources such as
the process table and memory. The number of rules in this file should
be kept to a minimum. Limits should be set on whole groups to keep the
file manageable.

** Quota

Quota controls the amount of disk space that users and groups may
use. Quota systems vary widely between UNIXes and you may have to
consult the documentation for your system for the specific commands
required.

Generally quota systems allow the restriction of blocks and
inodes. Blocks are 512 or 1024 byte chunks and limiting this number
limits the actual amount of data that a user may own. Inodes are
structures that describe files and many file-systems have hard limits
on the number available. Unless you limit them a user may be able to
fill the inode table and prevent new files being created.

* Security at more abstract levels

There are many social aspects of security that also need to be considered
by a poor-overworked sys admin. Much of this area of outside the scope of
a book such as this.

Much as been written about the security of
passwords, or rather the lack of, but still insecure passwords remain.  
Unless your users are security-savvy you can be sure that most of their
passwords will be simple to guess.

Several options present themselves from seeking to educate users, setting up
cracklib or providing a version of passwd which only gives out random
passwords.

Social Engineering is another method for attackers to gain access to a 
system and is very hard to defend against. It generally involves tricking
users into revealing passwords or running Trojan programs. There are no good
technical measures against this family of attacks. They require user
education and strict guidelines.

Sat Jan 25 17:38:18 GMT 2003

Well, it seems that my previous comments about TCPA not being able to secure boot were true, but this work from IBM suggests that it can provide a primitive that says "only decrypt this on a given boot config".

Now, a boot config (my name) is defined loosely in the TCPA specs (site seems to be down right now, maybe MsSQL worm) and I would wish to see exactly what it is hashing before I use it. But I can see many useful applications of this. For one, encrypt the hard drive and store the decryption key in the TCPA chip. That way you get seemless boots, but you cannot root the box with a floppy disk. I can think of a number times that function would have been nice. So I think I would be quite happy to have a TCPA motherboard and I want to see lots of neat uses of them.

Wed Jan 22 23:42:22 GMT 2003

(Stephen Baxter, 0-061-05044-x (Hardback), 0-061-05903-x (Softback))

Well, Edinburgh, geology and Sci-Fi. Ian (Clarke) and Matt (Key) eat your hearts out. Baxter always wrote pretty hard sci-fi but that generally means physics. This is the first time I've read a book where the science was mainly geology, but at no cost to the book. This book is novel, well written and engrossing (which is measured by the number of times I put the book down during a lecture).

(Rick Booth, 0-201-47960-5)

This book deals with eeking out every last cycle from Intel processors. It's looking a bit dated now (only covers upto MMX, and even then it only covers that by documentation), however many of the tricks still hold true. The author covers each chip in turn (486-PPro) and then practical applications, including random number generators and JPEG codecs.

Generally not very useful unless you do this sort of thing often, but if you can get it from a library then it's worth a flick through.

Wed Jan 22 19:06:41 GMT 2003

• Understanding The Linux Virtual Memory Manager. Also see the code commentary

Ok, after talking with one of the maths people here about this, it boils down to this: proof by contractions works only if you accept A∨¬A. That's called the law of the excluded middle.

Now, if you look that up (e.g. on MathWorld) you'll find at it says something like "this means that A is either true or false". But it doesn't. A∨¬A means that either A or ¬A is a theorm (i.e. can be reached on our axiom tree). So it really says either A or ¬A is provable; but Gödel has shown otherwise.

And in my logic notes the following proof of A∨¬A was given:

(Box proofs are a pain to typeset in HTML)

That means that the basis of proof by contradiction is proven using proof by contradiction. (it also has a ¬¬ elimination, but that's not the subject of this post)

Thankfully, a google shows that I'm not the only person to ever think this way. (Which makes me a little more confident that someone like Ralph or Bram isn't going to stomp me with a devistating counter argument). Intuitionistic Logic seems be (at least) a similar school of thought. A few more links that I haven't fully digested yet:

• K5: Alternative Logics
• The Law of the Excluded Middle
• The Continuum Hypothesis

Mon Jan 20 21:42:07 GMT 2003

IV KeyVerify is working again. Now on Imperial servers.

Mon Jan 20 18:43:35 GMT 2003

Google is being a little useless, but I have it on decent authority that one can prove, by contradiction, that there exists a well ordered relation for ℜ. In other words; that there is a minimal real number. That about that for a second.

(context switch) You can look at something like metamath and find a axiom system, on top of which a sizeable amount of maths is built. Generally, all maths should be done this way but it's too tedious, so generally people don't bother being that precise in proofs, but the general idea is that they could, if they wished.

Now you can think of the axiom system as a tree with n roots (one for each axiom). You can move from any point in a number of different ways by using a rule of inference the make a new theorem. (Ian and Will can stop shouting GEB at this point). This axiom tree branches into the space of all possible theorems.

Now, we all hope like hell that our axiom tree only ever hits true statements. But we know that it doesn't hit all true statements (by Gödel). But when people prove by contradiction they start from a theorum and reach ⊥ (false). Since we assume that, starting from a point on the tree, we cannot reach a false statement like ⊥, they then assume that the original statement is false. Which is rubbish. What they have showed is that it isn't on the tree, and thus that it's not-provable (using that system).

Sun Jan 19 18:00:12 GMT 2003

From /.

I think the key problem is ISPs that do not block egress traffic on port 25. If you need to send mail through a different SMTP server than provided by your ISP, the admin of that server ought to provide you with a means of using it with authentication on a port other than 25

At least it was on slashdot so people know it's moronic, but good god what a prat. Because the email system is open to abuse, we should split the world in two (those deemed 'good enough' to send email and those who aren't)? Of course, the difference between those two classes would be that the former have more money. I just don't want to start on what a bad idea that is.

(Incidently, that does the same thing that blacklists now do, but at the other end and I think those blacklists are equally moronic.)

Someone from CyberLocator contacted me. It seems they do the location based authentication that I was talking about (and have a pretty neat way of doing it).

Wed Jan 15 20:38:38 GMT 2003

Well, I spent the afternoon trying to get Bochs to work. Unfortunately, the networking is just broken in both packet socket and tuntap mode. The problem is someplace odd in the code and I don't feel active enough to hunt it down - I found an easy bug, but that wasn't enough.

So, kissing the feet of the statue of RMS that I keep in the corner and asking for forgiveness, I install VMWare. And what did the wonders of commercial software manage? "Cannot allocate memory" (VM is setup for 32 megs and I have > 350M free).

I'll see if I can dig up an old box tomorrow.

Tue Jan 14 13:07:05 GMT 2003

So here's your interesting fact for the day (and example of evolution in action). Viruses have an evolutionary pressure to have a small genome which means they have to pack as much information in per base pair. Here's a base breakdown for a randomly picked virus genome:

A: 28.9% G: 23.8% T: 22.2% C: 25.1%

And for human insulin:

A: 17.0% G: 35.2% T: 16.7% C: 31.1%

So we have baggy genomes and don't bother packing as much information into our coding sequences.

In extreme cases, some viruses have proteins encoded in all 3 frames. But if you don't understand that I don't have the space to explain it here.

Mon Jan 13 13:53:14 GMT 2003

Will pointed me to this page for all my weird-glyphs-in-HTML needs. A quick Python script produces this useful table from that data. Your browser may not render all of these.

Fri Jan 10 23:57:13 GMT 2003

• IPv6 Meeting in London
• Elite: Frontier binary for Linux. Doesn't work here, I think my glibc is too recent/broken for it. Maybe you will have better luck.
• STAND on anti-ID cards. If the govt can't state their argument more briefly than this they deserve to loose this debate by default.

So, AMI has released the first TCPA enabled BIOS. At first I was quite pleased at it occurred to me that it might be able to secure boot GRUB. Of course, it has all the nasty TCPA stuff too, but I'm not going to use that. If it has a write-enable jumper on the motherboard that I can bridge to write an SHA1 checksum, I would be quite happy. However, having read some of the (dry and frankly confusing) specs it doesn't even seem able to do that. So it really is utter worthless crap.

(Technical note: I know the BIOS only loads a bootsector into memory and checksumming that wouldn't be enough to secure it, but the boot process could be modified so that the BIOS loads the whole lot. Given what changes the TCPA are trying to inflict they wouldn't even blink at that.)

Thu Jan 9 17:23:11 GMT 2003

RTSP is the protocol used by RealPlayer to stream its stuff. Now RealPlayer is pretty evil, but RTSP looks slightly open. At least Real provides a proxy server for it.

We'll see how it works tomorrow, but for the moment the essential agl patch; chroot and setuidgid.

--- rtspproxy.cpp	Fri Feb  9 23:38:53 2001
+++ rtspproxy.cpp	Thu Jan  9 17:10:32 2003
@@ -12,6 +12,9 @@
 #include <string.h>
 #include <signal.h>
 #include <stdarg.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <grp.h>
 
 #include "app.h"
 #include "rtspproxy.h"
@@ -1277,6 +1280,8 @@
     printf( "    -v              Print version information.\n");
     printf( "    -h              Display this help message.\n");
     printf( "    -d              Enable useful debug messages.\n");
+    printf( "    -u <uid> <gid>  Set UID and GID.\n");
+    printf( "    -c <path>       Chroot to path.\n");
 }
 
 int main( int argc, char** argv )
@@ -1328,6 +1333,31 @@
         {
             g_DebugFlagTurnedOn = true;
         }
+	else if ( strcasecmp (argv[i], "-c" ) == 0 ) {
+		if (i + 1 >= argc) { Usage (argv[0]); exit(1); }
+		i++;
+		if (chroot (argv[i]) == -1) { perror ("Failed to chroot"); exit(1); }
+		if (chdir ("/") == -1) { perror ("Failed to chdir after chroot"); exit (1); }
+	}
+	else if ( strcasecmp (argv[i], "-u" ) == 0 ) {
+		if (i + 1 >= argc) { Usage (argv[0]); exit(1); }
+		i++;
+		INT16 uid = atoi ( argv[i] );
+		if (uid == 0) { printf ("Bad uid\n"); exit (1); }
+		if (i + 1 >= argc) { Usage (argv[0]); exit(1); }
+		i++;
+		gid_t gid = atoi ( argv[i] );
+		if (gid == 0) { printf ("Bad uid\n"); exit (1); }
+		
+		if (setgroups (1, &gid) == -1) {
+			perror ("failed to set groups");
+			exit (1);
+		}
+		if (setuid (uid) == -1) {
+			perror ("failed to set uid");
+			exit (1);
+		}
+	}
     }
 
     app.Run();