Otter logo image
Valid HTML 4.01 Transitional

Asus Transformer Pad Infinity
CIFS on Android

Jim Carter, 2013-08-31

Security on the Wire

One of my requirements for network mounting from the wild side is that authentications and payload content should be encrypted on the wire, either intrinsically as with SSHFS or NFSv4, or via a tunnel. I have OpenVPN working on Android and I expect to have IPSec set up soon. However, I'm going to defer work on wire security until after basic mounting is working, relying on NTLM's dubious security for authentication, and allowing the NSA and other interested parties to see my content, in which sensitive information is separately encrypted.

Authentication

At Mathnet we need to export the UNIX home directories of hundreds of users to Windows workstations. As presently set up, the Samba server authenticates by PAM on UNIX. PAM does not know the Windows hashes of the users' passwords, and so it has to induce the client to send in plain text unencrypted on the wire. Hiss, boo!

Since Mathnet has a real Active Directory realm, it could (and probably should) be modified to trust the Windows PDC to authenticate users. Mathnet curates user accounts so the same loginID on UNIX and Windows always refers to the same user, and Samba will reject authentication in the rare case that the user is accepted by the PDC but has no UNIX account.

However, the Android client has no setting to allow sending the password in plain text, so PAM authentication is hopeless. However, at home the number of users is much less, like two, and it is feasible to put password hashes in /etc/samba/passdb.tdb. Also I have taken the opportunity to use a separate password for Samba: it gives the thief access to my home directory, which is bad, but my primary password has to be stolen from elsewhere.

With this change the Android client can mount the UNIX home directory.

In CIFS authentication, the server sends a challenge string to the client, which combines it with the password to produce a response that the server can compare against its stored password hash. It is generally believed that this mode of authentication, particularly NTLMv2, can resist some degree of brute force cracking and also replay attacks. But I don't know enough about it to make an independent judgment of these points. See this Wikipedia article about NTLMv2 giving the algorithms and pointing out exploits that are apparently currently fixed. The author refers to a Microsoft notice that deprecates the NTLM suite in favor of Kerberos. However, Kerberos authentication is not going to happen from an Android client.

Authorization and File Permissions

With Android's inside-out identity model this is going to be a real can of worms. The following hacks and kludges make the mounted CIFS filesystem useful.

On Android I use these options for CIFSManager (spaces added for readability):

Mount Point: /system/media/jimc (pre-created)
Share Path: 192.168.9.193\jimc
Options: workgroup=COUCHNET, uid=0, forceuid, gid=1015, forcegid, file_mode=0664, dir_mode=0775, nounix

Details on these settings:

On the server I use this Home section in /etc/samba/smb.conf:


[homes]
Valid users = %S, %D%w%S
Browseable = no
Readonly = no
Inherit ACLs = yes
Inherit owner = yes
Inherit permissions = yes
Map archive = no

The reasons for some of these settings are:

Samba and Oinkage

On UNIX, the smbclient program's dir subcommand reports the space occupied by the content (recursively) of the containing directory. This information may be easy to get in Windows, but in UNIX it takes research, particularly for a directory with lots of files like the Android SDK. When I opened files in my home directory, the first time after mounting, the editor's file browser appeared to hang and Android popped a force-close dialog. I let it wait two or three times and it eventually finished. Hiss, boo. I have also noticed occasional long delays in opening or saving files. I don't know if the problem is dropped packets but that's my guess.

To mitigate the long initial delay I reorganized my home directory, with only the active and small items in it. I made a separate, non-exported directory for big data such as music files, photos, Android development resources, and Android device image files. The music and photos have their own HTML delivery method, though some people report mounting CIFS shares just to play music on a player that can only handle local files. I've cut down the homedir to about 200Mb.

Otter logo image