Has anyone considered using a CFS directory (or directories) for a remailer's files, spool, etc? Any thoughts about such security measures? -- Allan Bailey, allan@elvis.tamu.edu | "Freedom is not free." Infinite Diversity in Infinite Combinations | allan.bailey@tamu.edu Esperanto: MondLingvo, lingvo internacia.
On Wed, 17 Aug 94 10:22:19 -0500 Allan Bailey wrote: --------
Has anyone considered using a CFS directory (or directories) for a remailer's files, spool, etc?
Any thoughts about such security measures?
I considered it, for the remailer@rebma.mn.org. I'm already running CFS for personal entertainment & education, so it's a possibility. Here's my assumptions about how I'd operate it: 1) CFS file systems are mounted sometime after boot, manually, by me. The passphrase is entered at mount time. (Obviously, supplying the passphrase via an /etc/rc script defeats any security that CFS might add.) 2) The file systems remain mounted throughout the uptime of the system, since mail can come in at any arbitrary time, primarily while I sleep. 3) If someone comes knocking loudly at my door to do the raid thing, I'll have bigger things to worry about than unmounting the CFS file systems. My wife and daughter will be formost on my mind. I thought of two problems with it. 1) I'd not only have to put the home directory of the remailer user under CFS, but also the uucp and sendmail spool directories. (Rebma has a UUCP connection for getting mail.) Otherwise, security would be pointless, since the messages would be coming in the clear to the spool directories. Maybe this wouldn't be so bad, but it seems like I'd have to do a lot of tinkering before I'd trust that sendmail wasn't gonna drop my other mail on the floor. (I get some consulting-type mail on this machine. Potentially, I can miss out on financial opportunity if my mail is not dependable. Chalk my caution up to pure greed.) 2) I'd have to come up with some kludge to spool the incoming mail files in a directory if the CFS file systems weren't mounted. (For example, if power failed on the machine, or it crashed and otherwise rebooted, and I didn't notice and wasn't around to type the passphrase in to remount the CFS system.) Those two thoughts make me question what security I'm buying for my trouble. Seems to me what I'm getting is protection from a law enforcement type or other computer thief who unplugs my machine and takes it away. (If they want to make a backup before turning the machine off, with the CFS file systems mounted, they have to spend some time at it.) The people whose security would be helped are those who do a single hop or send unencrypted mail through the remailer. People who use the remailer properly already have encrypted their mail. I guess that I thought it was too much effort to do, given that the only people who would derive added security are those who were too stupid to use the remailer properly in the first place. Anyone see a flaw in my reasoning? I actually was considering doing it anyway, just for the fun of it, when I had free time. If there is some valid security reason, it might move up on my to-do list.
The people whose security would be helped are those who do a single hop or send unencrypted mail through the remailer. People who use the remailer properly already have encrypted their mail.
But they'd still be in your logs, unless you immediately delete or encrypt your logs. If you keep logs to help debug your system snoop-proofing those logs is a good idea. Also CFSing mail spools just for regular e-mail is a good idea, to help enforce the ECPA. I hope this becomes standard policy on the Internet. (Of course, don't forget SecureDrive available for DOS). Jim Hart hart@chaos.bsu.edu
On Wed, 17 Aug 1994 16:42:33 -0500 (EST) Jim Hart wrote: --------
The people whose security would be helped are those who do a single hop or send unencrypted mail through the remailer. People who use the remailer properly already have encrypted their mail.
But they'd still be in your logs, unless you immediately delete or encrypt your logs. If you keep logs to help debug your system snoop-proofing those logs is a good idea.
I skipped a step in giving my assumptions. By "people who use the remailer properly" I mean people who encrypt AND chain through multiple remailers. In that case, even if I were to keep logs, all that anyone would know from a message is that a particular user used a remailer, or that a particular cleartext message had a certain remailer as its jumpoff point. Not both. (Unless, of course, I'm in collusion with other remailer operators. But that's also a non-code issue.) I'm not interested/concerned with preserving the security of the people who don't chain and encrypt.
Also CFSing mail spools just for regular e-mail is a good idea, to help enforce the ECPA. I hope this becomes standard policy on the Internet.
That's an interesting and valid point. I can see some sense in an encrypted file system for mail spools, just to highlight a philosophical point or to help create a new net-wide philosophy for the handling of email. I'm not sure that security is improved, however. I half-expect Eric or Tim to jump in here to point out that this is one of those situations where you have to define who your enemy is, and to make sure that your efforts apply to the situation. My personal situation is, I run a remailer on a home Unix machine via a phone line UUCP feed. I am the only user of this machine, so I do not have to defend against users with local access. My efforts are intended to block the following foes: my service provider and any node upstream of it, thieves/misguided law enforcement types, and phone taps. Encrypting something that I receive in the clear over an insecure line isn't useful. Of course, this is very specific to my situation. I expect that there exists sites where running CFS for the spools makes sense. The fact that Matt Blaze has said he has put some effort into making that possible just reinforces that. This conversation is making me think that I should follow some other remailers and make the remailer at rebma only allow encrypted traffic, since I have such a low-opinion of unencrypted traffic. Now, when we're all running our mail traffic over something like swIPe, such that all connections are encrypted... And if I got an encrypted UUCP connection... That might change things. Then again, if you want security, encrypt it and chain remailers, regardless. Sorry. I'm rambling. I won't dignify it by calling it "brainstorming.".... -Bill
Bill O Hanlon:
In that case, even if I were to keep logs, all that anyone would know from a message is that a particular user used a remailer, or that a particular cleartext message had a certain remailer as its jumpoff point. Not both.
They'd learn both if they had snooped the entire remail chain (which is the equivalent of collusion). Going back and retrieving logs for all the the links, after the snoopers have discovered an important message they want to trace, is both an easier and a more likely attack than wiretapping all the links in real time in anticipation of an important message -- unless the remailer operators snoop-proof their logs. Also keep in mind that, given the lack of a good user interface, there is currently too little properly encrypted and nested remailer traffic to create anything approaching a true digital mix. Jim Hart hart@chaos.bsu.edu
"Bill O'Hanlon" <wmo@digibd.com> writes:
On Wed, 17 Aug 94 10:22:19 -0500 Allan Bailey wrote:
Has anyone considered using a CFS directory (or directories) for a remailer's files, spool, etc?
...
I thought of two problems with it.
1) I'd not only have to put the home directory of the remailer user under CFS, but also the uucp and sendmail spool directories. (Rebma has a UUCP connection for getting mail.) Otherwise, security would be pointless, sinc e the messages would be coming in the clear to the spool directories. Maybe this wouldn't be so bad, but it seems like I'd have to do a lot of tinkering before I'd trust that sendmail wasn't gonna drop my other mail on the floor. (I get some consulting-type mail on this machine. Potentially, I can miss out on financial opportunity if my mail is not dependable. Chalk my caution up to pure greed.)
2) I'd have to come up with some kludge to spool the incoming mail files in a directory if the CFS file systems weren't mounted. (For example, if power failed on the machine, or it crashed and otherwise rebooted, and I didn't notice and wasn't around to type the passphrase in to remount the CFS system.) ...
I'm working (with very low priority, unfortunately) on a sendmail hack that spools mail (instead of bouncing) if the mailbox write fails. This will be intended for a secure mail system that I'm working on that uses CFS for its storage. Stay tuned... Another potential problem with sendmail->cfs interaction is that CFS doesn't implement NFS file locking. This isn't much of an issue with a single host and a single instance of CFS, but could be a problem if the mailboxes are read and written by other machines or are remotely mounted by the machine running sendmail. By the way, another mode of operation you might consider is to use a "permanent" key (that you supply at boot time) for the spool directories and a temporary key (assigned randomly by the machine at boot time) for temp files that have only local significance but that may have sensitive data. /usr/tmp points to /crypt/tmp on my machine for this service (do a cmkdir and cattach at boot time. You also have to hack cfs to make /crypt/tmp be mode 777). -matt
participants (4)
-
allan＠elvis.tamu.edu -
Bill O'Hanlon -
Jim Hart -
Matt Blaze