Slashdot Mirror

I use saft, the simple asynchronous file transfer system. I don't know if it has a windows implementation, but it's great for sharing files with someone else directly.

Far far better is SFS, the self-certifying filesystem. It's more trouble to setup (unless you use Debian) but it allows you to create a secure NFS mount that can safely be mounted and used across the internet.
I've used it in the past to give read-only anonymous access to a directory, and I could still fly around the world and securely mount the SFS share somewhere else. You probably don't want to mount an SFS share on insecure hardware that might have a keylogger, but it's a great way to have access to all your source code (and research papers in my case) from a friends house in another country.

I proposed this solution about 4 years ago to one of the gnome-vfs guys at a Helixcode party in San Francisco "back in the day".

So, did he answer "been there, done that" or "that's dumb"? Or did he just nod politely and suddenly act like he was being hailed from across the room? Only about a thousand people have had variants of the same idea; the two closest would be Farsite or SFS, but there are many others. One thing that's unique to your proposal, though, is the idea of sending every block to every node - creating a system that cannot possibly scale beyond a trivial number of nodes.

There's nothing wrong with blue-sky thinking, but when the sky is already crowded with planes and helicopters and blimps you should take some time to study them before repeating the mistakes their designers made ten years ago. It's also good to get the basics working or at least decently thought out before you start speculating about what extra buzzword-compliant ideas you can throw into versions two through ten. We already have Freenet to show us what can happen when people don't heed either of those lessons.

SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere. Anyone can set up an SFS server, and any user can access any server from any client. SFS lets you share files across administrative realms without involving administrators or certification authorities.

My parents (both in their mid-sixtees) have a Debian Woody-based workstation (with KDE 3.0, OO 1.0 and Firefox) and a laptop that came with WinXP. I made it very clear that Windows is unsupported, end of discussion.

I've also spent hours explaining to them why free as in speech is important, and how morally corrupt MS is. They understand that they just can't ask me to support MS.

They are pretty happy with it. My mother likes it very much, she has few problems. Not only is she surfing, reading e-mail and stuff, she also uses Amaya to create web pages for her class. She use SFS to get them onto my machine. Dad's not quite so happy, because he has bought into that "I shouldn't have to learn anything to use a computer" crap. But I am getting him to realize how wrong that is (after all, he is a civil engineer), so things are improving.

I recently got Debian onto moms laptop, as I needed to borrow it. As far as I know, they are not booting WinXP a lot anymore, they are mostly Debian users.

Really, I would recommend that approach to everyone: Make them use the OS you think is good, and try to make that OS work well for them. You can do most administration tasks remotely by SSH.

All other "encrypting remote filesystems" encrypt only the filetransfer, not the filestorage (AFS or - if i understood the FAQ correctly - SFS). So the fileserver admin (or an intruder or trojan) is able to read served files cleartext.

What's required is a remote filesystem where the clients do not need to trust the service nodes for data integrity and privacy. If i did not miss something (please tell me!), the only option nowadays is stacking a local crypting fs on top of a remote fs, e.g. NCryptfs on top of NFS or AFS.

/graf0z.

The self-certifying filesystem or the cooperative filesystem might do what you want, though I believe they only run on unix platforms. The code is considered to be in the alpha stage, but apparently the maintainers have been using it for a while without losing files. On some platforms SFS (on which CFS is based) has the nasty habit of deadlocking the kernel from time to time. You might want to read their documentation, since this might not be a problem for what you're running on.

SFS

CFS

Haven't there already been other projects with similar design goals, like the Self-certifying file system? The authors of SHFS say it's a hack, which has a few drawbacks -- e.g., in generic write operations on non-Linux machines, a separate write() system call is used for each byte! Can anyone comment on the relative merits/demerits of the alternatives?

Not sure what you mean by ``distributed''. you should be a little more specific about what you want. However, SFS (self-certifying file system) is a good replacement for NFS, featuring privacy and authentication. Works on Linux, *BSD, MacOS X....

see http://www.fs.net

• "SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere. Anyone can set up an SFS server, and any user can access any server from any client. SFS lets you share files across administrative realms without involving administrators or certification authorities."

• Several of the SFS authors use SFS for their home directories without any problems. SFS has been in use for several years and we have never lost a file. That said, SFS should still be considered alpha software."

I would use SFS, the Self Certifying File System. Assuming all the systems you are using are supported, it offers global, secure access to anything you care to export.

Take a look at http://www.fs.net ... There was an article in the ;login Dec 2002 issue

"SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere."

SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere. Anyone can set up an SFS server, and any user can access any server from any client. SFS lets you share files across administrative realms without involving administrators or certification authorities.

By the way, he got the URL wrong too - www.fs.net (SFS), not www.sf.net (sourceforge)

Why does the repository need to be public? In an era of very powerful client machines, why must we have a centralized database

Why do you assume that public implies centralized? The article author certainly didn't; that was actually one of the questions s/he was asking? If you look at systems like OceanStore or SFS, or even Microsoft's own Farsite, you'll quickly realize that your assumption is false.

It is being sponsored by DARPA.

Cool stuff. They built it with security in mind and it runs under:
Linux, OpenBSD, FreeBSD and Solaris.

NFS has a long history of insecurities.(Link takes a little while to load...)
Also in the article he claims: "You can reboot a server and the client won't crash." Maybe not crash but at least with Solaris (in my experience) you hang the entire system during the reboot. Sometimes it comes back and sometimes it doesn't.
For a secure alternative that runs on *BSD/Solaris/Linux w/(2.4 Kernels) try out:
Self-Certifying Filesystem.
The authors do warn that it is in alpha stage but also claim they have never lost a file. VERY cool project.

And of course as the OpenBSD Journal has noted, SysAdmin Mag is running an article on Tunneling NFS over SSH.

Second, if you export NFS to the world, you're insane and deserve what you get. If you want remote filesystem access, use a secure protocol like the Self-Certifing Filesystem (SFS). SFS also avoids completely the problem of having a shared UID space.

Finally, his advice to mount your filesystems intr is good. But insufficient - also mount them soft, so that filesystem calls will eventually timeout if the server goes poof.

If you perhaps do not trust the client machines, though, which you might not if they are Windows boxes, you would not want to use just public key crypto. You would also want to use a passphrase based system, and then you are back to having to have secrets on the servers, which need to be very carefully republished when they change. And you might not trust some of the servers. OpenSSH (and especially OpenSSH with the SRP patch) can do this, and it'll authenticate both the client *and* the server, so that both parties know they are connected with the entity they think they are connected to.

You might also want to look at SFS (a secure distributed filesystem based on NFS but with SRP authentication). Note that there are several projects all called SFS -- I'm thinking of the self-certifiying one. Then you can have central administration of server-side secrets. Probably some of the other projects called SFS would be good too, but I'm less familiar with them.

Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.

Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.

I also don't understand what the purpose of keeping an OS project secret would be in an academic enviroment. Remember publish or perish?

http://www.fs.net

Try SFS the self-certifying filesystem. Here's a link. Its definately better than AFS.

For the latest Linux NFS patches, (to support V3), you'll want to go to nfs.sourceforge.net

An interesting solution to this problem was just recently released: sfs, which allows separating the pki out from the connection protocol.