I would like to expand on Hal's suggestion that remailer operators post their policies on a)keeping logs and b) divulging same.
The anonymous mailing system at pax has the following policy: - A log of activities of the remailing software is maintained when debugging is in progress (often) which could be used to correlate real identities with aliases - this is no more or less information than is available in the alias database which is not visible to anyone except the root user. Message-id's are NOT stored in this log, and the contents of messages and posts are NOT stored anywhere, nor are they scrutinized by me or anyone else. I don't care and I don't want to know. If someone does something unreasonable and I get complaints then I could lock out a particular source of mail if I didn't get a good explanation, but I am not going to go reading other peoples mail in order to censor it ! - Under no circumstance short of being arrested and/or the equipment commandeered by someone else will the alias database be divulged or the contents or routes of messages deliberately intercepted. david
The anonymous mailing system at pax has the following policy:
- A log of activities of the remailing software is maintained when debugging is in progress (often) which could be used to correlate real identities with aliases - this is no more or less information than is available in the alias database which is not visible to anyone except the root user. Message-id's are NOT stored in this log, and the contents of messages and posts are NOT stored anywhere, nor are they scrutinized by me or anyone else. I don't care and I don't want to know. If someone does something unreasonable and I get complaints then I could lock out a particular source of mail if I didn't get a good explanation, but I am not going to go reading other peoples mail in order to censor it !
I keep logs on content and origin on my three remailers. I do read the logs. However, I would not censor any transmissions. I would stop accepting mail from a site given enough reasonable complaints.
- Under no circumstance short of being arrested and/or the equipment commandeered by someone else will the alias database be divulged or the contents or routes of messages deliberately intercepted.
Dido for me. I would make an attempt to destroy all of my data if an attempt were made to take the equipment or access the data by a government or other agency. e
logs. However, I would not censor any transmissions. I would stop accepting mail from a site given enough reasonable complaints.
That would not help in the least. The person can still send mail through your system, they would just not use you as the first hop.
Dido for me. I would make an attempt to destroy all of my data if an attempt were made to take the equipment or access the data by a government
Make sure you don't think 'rm -rf /remailer-logs' actually destroys data. It merely de-allocates the i-nodes. You need to know which physical device the filesystem is on, (let's call id /hdxxx) and then do 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data on that partition. For that reason it may be preferable to keep all such information opn a filesystem of their own, so you don't have to destroy much other data along with it. If you use swapping or paging, you need to clear out those devices too, and then turn the machine off to remove all data in RAM. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819
Make sure you don't think 'rm -rf /remailer-logs' actually destroys data. It merely de-allocates the i-nodes. You need to know which physical device the filesystem is on, (let's call id /hdxxx) and then do 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data on that partition.
not quite. you need something like dd if=/dev/null of=/dev/xxx bs=verybig conv=sync this will zero out every block on the disk. but this is overkill -- why not just apply this technique to the individual logs, zeroing out their data blocks? peter ps: is it certain that zeroing out the data blocks thoroughly destroys the data? i've heard that a "shadow" of some sort may remain.
Make sure you don't think 'rm -rf /remailer-logs' actually destroys data. It merely de-allocates the i-nodes. You need to know which physical device the filesystem is on, (let's call id /hdxxx) and then do 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data on that partition.
not quite. you need something like
dd if=/dev/null of=/dev/xxx bs=verybig conv=sync
Unix weenies of old will recall "clri" to clear an inode. If paranoia is in effect, try something like the following: ls -li remailer-log or whatever to get the i-node number, then clri /dev/sdxx #_of_i-node Of course, care should be taken to then unlink the file immediately, as if the i-node number is reused on that filesystem, the old entry would still point to that i-node, and removing the old file would remove the new one (an inadvertent hard link). Clri is in /usr/etc, and it's use is obviously subjected to your permission of the device file (and the file itself), though that's understood if you were going to use 'dd'. Not everyone running a remailer will have permission (usually root) to write directly to filesystem /dev files, so why not just write a little C program to open the logfile and overwrite it to the end with NULL's? Simple.
not quite. you need something like
dd if=/dev/null of=/dev/xxx bs=verybig conv=sync
Unix weenies of old will recall "clri" to clear an inode. If paranoia is in effect, try something like the following:
ls -li remailer-log or whatever to get the i-node number, then clri /dev/sdxx #_of_i-node
this will zero out the inode it also does NOT clear the data blocks just the inode pointers to the data blocks. infact if you do this. (this you *will* need to umnount and fsck your system [or reboot if you did this to you root partition]). in fact if you do this with out deleteing the file first you run a good chance of crashing the system. normaly I would say "do not try this at home" but then I would rather you shot yourself in the foot at home (as opposed to shooting yourself and who ever is on a public system) I will post some C/Perl code that will work as a /bin/rm replacement in a few days. -Pete
Unix weenies of old will recall "clri" to clear an inode. ...
clri destroys the file "handle" (the inode, thus the owner, mode, length, pointers to data blocks, etc.) but not the contents of the data blocks. stringing them together is another story, but not impossible if you know what you're looking for.
-- so why not just write a little C program to open the logfile and overwrite it to the end with NULL's?
u.w.o.o. often go to great lengths to avoid writing a few lines of c, which, i suppose, is not so bad. but i agree with hkhenson that the best way to secure the remailer logs is to encrypt them. which raises a sticky point, since i don't see an easy way to do that on a machine that you can't secure physically. i'm familiar with the andrew environment (e.g., afs or the andrew toolkit), which is more or less a kerberos environment, wherein secure service providers run on physically secure machines. this lets sysadmins store cleartext passwords (in essence) on their local disks to support reauthentication daemons (to refresh tokens for long-lived jobs, since kerberos tickets time out). this clearly would not achieve the objectives here. the only option i see is to enter a password at boot time (or when the remailer is started). ick. peter
that the best way to secure the remailer logs is to encrypt them.
which raises a sticky point, since i don't see an easy way to do that [...] see is to enter a password at boot time (or when the remailer is started).
There is an easier way. Just generate a public/private key pair. Store the public key on the machine, and have the remailer encrypt its logs with the public key. Someone seizing the machine could not find anything, since they do not have the private key. Store the private key on another machine, or on a floppy. When there's a problem, you can transfer the encrypted log to the machine with the private key, and then you can decrypt the log to see what went wrong. Generate a new key pair weekly, and destroy the old private key. You should never need logs older than a week for troubleshooting. p.s.
Unix weenies of old will recall "clri" to clear an inode. ...
-- so why not just write a little C program ...
u.w.o.o. often go to great lengths to avoid writing a few lines of c,
So how about a few lines of perl? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819
participants (6)
-
dclunie＠pax.tpa.com.AU -
Eric Hollander -
peter honeyman -
Peter Shipley -
Phiber Optik -
yanek＠novavax.nova.edu