Asus Transformer Pad Infinity
CIFS on Android

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:

• I tried several mount points. This one doesn't have permission problems. However, to create it you need to (as root) remount /system read-write.

• You need to use the server's IP address rather than its name, because CIFSManager and/or the Android equivalent of mount.cifs is too lazy to translate an alphabetic hostname.

• This replicates the ownership and mode of a file on the removable SD card. Group 1015 is sdcard_rw; CIFSManager and/or the Android equivalent of mount.cifs is too lazy to translate an alphabetic group ID. The leading 0 on the modes is required if you want it to be interpreted as octal (otherwise it's decimal). The modes do not override permissions that the server sends if UNIX extensions are in effect. Therefore we have to suppress UNIX extensions, hiss, boo! One consequence is that the server follows symbolic links. It would be a good idea to edit the referent, not the link.

  The key design point here is to make the files appear in Android to be writable by group sdcard_rw. Each app runs as its own user, so setting ownership to a particular user accomplishes nothing. But all apps authorized to write on personal data have an intent (group membership) to that effect, and sdcard_rw seems to be the most useful of these. On the server, of course, the normal UNIX ownership and mode are used.

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:

• Valid users: it will accept the plain loginID or with the realm (workgroup) in front.

• Browseable: [Home] shares do not exist before being accessed, which is when you would want to browse for them.

• Readonly: The whole point is to use the home directory, so it must be read-write.

• Inherit ACLs, owner, permissions: These are for files created by Samba when UNIX extensions are not available. They would receive their various permission items copied from the containing directory, except minus the X bits for files. The default would be no ACL, owned by the connecting user (which in my case would give the correct result), and some lame DOS-oid mode like 777. Unfortunately, without UNIX extensions and with inherit permissions, it is not possible to create executable files.

• Map archive: The archive bit is emulated by the owner's X bit (0100) if UNIX extensions are turned off, so if the file has been modified since (sometime) it will have the mode 0744, which is very annoying. This behavior is on by default, and needs to be suppressed.

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.