Re: Remailer Policies

> 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