Published by Pat Riehecky on 30 Jan 2008
Cross platform filesharing
Suppose for a moment that I had a document that I wanted to share with you. I could email to you, but what if it changed. An endless string of emails could be sent, but isn’t that confusing? What if you only need to see it occasionally? You could pester me every time, but that hardly seems an improvement. Suppose you only need to see it when I am out. That is somewhat problematic.
This is the type of problem that can be solved with a file share. Unfortunately here is where the problem gets far more complex. Every major operating system has their preferred type of file share. Windows is designed for SMB. Mac OS is designed for AFP. Unix is designed for NFS. With some configuration and free software it is possible to make Mac OS and Unix speak SMB, but there aren’t any good free Windows drivers for either AFP or NFS (at least none that I can find). With that in mind the current university file sharing system uses a software product call Samba to speak SMB.
Samba is free software, which places it firmly within our budget, and it is a tested enterprise grade solution. Our implementation here, however, has not been as clean as I would like. This mostly has to do with leftovers from the previous file sharing solution. The previous solution was to build a Windows NT Domain and share the files over SMB inside of a domain container.
Domains are lock in technology. Basically all that means is, the system has been designed to be easy to setup and hard to take down. There are several insecure things that happen inside of a Domain based connection to a SMB share. There are also a few secure things that go on.
First the secure things that SMB does in a domain. It uses the system secret key (technically it is way more complex, but without a few hour lecture it isn’t worth explaining) to establish it is aloud to connect to the system the share is hosted on. This prevents unauthorized systems from doing much more than annoying the file sharing system. It can also utilize GSSAPI/SPNEGO based logins (for Active Directory sites only). GSSAPI is basically Kerberos V5. SPNEGO is a Microsoft protocol which does a lot of the same types of things.
SMB does some insecure things. It is not end-to-end encrypted. The login session controls access to the data stream, this is supposed to prevent hijacking. The login connection is itself not secure, but it is encrypted. The login session has non-dynamic encryption, the encrypted packets sent for login initially are the same packets that are sent two or even three years later if your password hasn’t changed. To promote single sign-on, any share you connect to is initially handed enough data to try and authenticate you seamlessly.
Microsoft recognizes this problem and since Windows 2000 GSSAPI/SPNEGO has been the first try connection for any share. Then it reverts to the old behavior. When escaping from a Domain this is particularly problematic. The GSSAPI/SPNEGO sent by the Domain member is encoded for the domain to use, a non-domain member will be unable to process these strong credentials. The login will fail. Then the system will revert to the old behavior, but these credentials are still not valid for the system. The Domain member will try these methods each several times before allowing a username and password to be entered. This timeout process can take up to a minute. Non-domain members experience a similar problem. Since this is SMB being spoken, and it was designed to be Domain driven vendor lock-in technology, the non-domain member system will try and determine the domain that the server belongs to for establishing something called “InterDomain Trust.” Even though neither system belongs to a domain. If both systems are workstations, the process fails almost instantly, but if one is a server, even a non-domain server to a non-domain client, the process must be attempted until it times out. This takes about a minute, during which GSSAPI/SPNEGO and old style authentication are also attempted.
Some people have claimed that Windows Server does not have these problems, I am not sure why they have said this. The protocol is the protocol, it doesn’t matter who implements it. It is what it is. And with the Windows Server solution we must pay a fee per user who connects to the system. The expense is a bit high for no real gain. Students often complain about a waste of tuition dollars, an identical free solution helps make these complaints a bit less justified.
What of AFP or NFS. NFS is a security nightmare. There simply isn’t a secure way to implement it. People have tried, but ultimately it just cannot work, it wasn’t designed that way. AFP is really only a Mac protocol. While much of campus is Mac based, 80% or so is still on Windows systems. AFP runs its security entirely through SSH, which is secure, but a very very high overhead for the service. As such, by default, AFP is unsecured. And adding SSH to the mix creates a whole separate security infrastructure which would need to be monitored in addition to AFP. It would also generate a great deal more network traffic making the connection much slower.
I hear about Xythos occasionally. While it looks curious, the main features it boasts of are less impressive when the high sticker price is compared to free alternatives. Xythos does everything through WebDAV which is as secure as the web server providing the data. It can be run through SSL which would provide strong end to end encryption. Their is even a driver available to allow Windows clients to make this appear a normal share.
My concerns about it are rather many fold. It uses a proprietary file system to store the user data. How then am I to recover data from it? The drive mapping is listed as a Windows feature, ignoring our 20% Mac population is just not acceptable for a campus wide solution. Reports from the Internet call Xythos, “Not great 1 star.” The big claim to fame is off-line editing, but this again is only a Windows feature. How then is this data to be shared to the servers? Long term we want to give all of you access to your server room storage space from an easy interface. Right now WinSCP or FuGu are the only options for Windows/Mac systems. It is assumed Linux users are happy enough with ssh. If I cannot share the Xythos data to the webserver, your webpage is gone. Nobody wants that.
Lastly, the beacon of hope is AFS. Implementing AFS outside of a Kerberos Realm is pointless. For the time being this halts this in its tracks. OpenAFS is a free implementation of AFS, they have a free Windows driver as well. Unix and MacOSX have had drivers for AFS for a long time. AFS supports end-to-end encryption via Kerberos and off-line editing. AFS also supports a kind of intelligent caching where writes occur locally and are then propagated up to the server in batch. This makes AFS a possible candidate for large scale network file manipulation, but I would have to see some numbers to know for sure.
On the whole, AFS is a very exciting and appealing way to go, but without Kerberos it will never make it to IWU. With that in mind we have selected Samba for SMB logins. It is as secure as we can make it without spending any money. There are some problems with it, but they are a part of the protocol. That we cannot fix. Kerberos is on my to-do list, but so are a hundred other things.
This entry was prompted by a discussion of starting the file sharing setup all over again. Here is a log of thoughts and ideas on it as a hope that whomever is inconvenienced will at least see that we are trying to do the best we can to find a safe and easy solution for making file shares happen the way users expect them to.