Paranoid Penguin - Samba Security, Part IV
For the past four months in this column, we've been building a secured Samba server for our local LAN, using Swat. To spare those of you who have been following this series a fourth summary of the usage scenario, let's suffice it to say, we're creating a series of file shares with varying user permissions.
This month, I wrap up the series by showing how to create a restricted, “owner-only” share and how to use mount.cifs to make persistent Samba mounts on your client systems.
Last month, we created a public share, SUPPER, and a nonpublic and group-readable share called CHORES. Prior to that, we had set up some global variables that are inherited by all shares. Those global variables were:
workgroup = FED-CENTRAL security = user client schannel = yes server schannel = yes map to guest = Bad User guest account = nobody unix password sync = yes valid users = mick, knute, pepe, skippy, nobody read list = knute, pepe, skippy write list = mick
Attentive readers of Part II of this series [December 2008] may notice that I omitted “admin users” here, even though in Part II, I had set that to mick. This was an embarrassing mistake. On Ubuntu systems at least, this wreaks havoc with how Samba interacts with Linux file permissions.
You'll recall that setting “admin users” causes listed users to be logged on to Samba as root after successfully authenticating as themselves. In other words, if “admin users” is set to mick, any time mick successfully logs on to any share, he'll actually be logged on as root. The expected result is that mick, therefore, will have superuser privileges and won't be restricted from doing anything at all. In practice, the results tend to be much less predictable than that.
For example, on my Ubuntu 8.04 system, suppose I set “admin users” to mick, create a directory on the underlying Linux filesystem that's owned by mick and has permissions of -rwx------ (or 0700), and then I create a Samba share mapped to that directory that has no guest access or read access (that is, a share like the one I'm about to show you how to set up).
If I then try to connect to this share with this command:
bash-$ smbclient //CASA_DE_MICK/BUZZ-OFF -U mick
and enter the correct password when prompted, sure enough, silently and behind the scenes, I'll actually be logged on as root. But the result of this login will be:
Domain=[CASA_DE_MICK] OS=[Unix] Server=[Samba 3.0.28a] tree connect failed: NT_STATUS_ACCESS_DENIED
What? How can this be? Access shouldn't be denied to anything, for root, should it? But denied it will be, if the share in question maps to a directory not owned by root. This may or may not happen on non-Ubuntu systems. My point is that using the “admin users” parameter may result in unpredictable interactions between Samba and Linux filesystems.
As I said last month, letting people use Samba shares with root privileges is dangerous anyhow. Samba client software isn't the correct tool for Samba system administration, Swat is. So now we have two good reasons always to leave “admin users” empty!
Now, let's move on to our share-specific settings. The smb.conf variables that configured SUPPER, as set via the Swat tool, looked like this:
path = /home/mick/supper read only = yes guest ok = yes invalid user = root valid users = read list = write list = mick admin users = hosts allow = 192.168.44 hosts deny = ALL create mask = 0644 browseable = yes available = yes
These variables are set nearly the same for CHORES, except:
path = /home/mick/chores guest ok = no valid users = +users
What do all these variables mean? I explained them in gory detail in the last three issues of LJ, and definitive descriptions can be found for all in the smb.conf(5) man page. Some of these will come into play this month too, as we create that restricted share.
You'll recall that our Samba server has four user accounts: pepe, skippy, knute and mick, which correspond to my three roommates and me. These are UNIX user accounts on my Samba server's underlying OS, with corresponding but separate entries in the Samba server's separate user database. (I explained how to create and synchronize Samba user accounts in Part II of this series, in the December 2008 issue.)
For our restricted share, BUZZ-OFF, only mick should have read access or write access. No other user should have any rights at all on this share. Accordingly, when we create the directory to which this share will point, we'll be sure it's owned by mick and has a permissions mask of 0700 (u+rwx,g-rwx,o-rwx), like this:
drwx------ 2 mick users 4096 2008-11-04 00:00 buzz-off
Figure 1 shows the first round of parameters we'll set upon creating this share in Swat's Basic View.
After setting the path, we set read only to no—I'll be creating new files in this share—and guest ok to no as well, because we don't want to allow any anonymous access. We'll set hosts allow and hosts deny the same as our other shares—to permit access only from the local LAN (your network address is, obviously, probably different).
We'll set browseable to no, so this share won't turn up in people's Network Neighborhood or in smbtree listings. To connect to this share, therefore, we'll need to specify its path when mapping it to a drive or connecting to it with smbclient.
And, we'll leave available set at no until we've clicked the Commit Changes button, clicked the Change View to Advanced button and changed some things in the Advanced View (Figure 2).
As you can see, we're going to blank out the list of valid users except for mick and completely empty the contents of read list. The write list, however, correctly contains the single value of mick.
The only other setting we need to change is create mask, which we'll set to 0600. This is different from the 0700 mask we used when creating the directory itself; the directory's execute bit needs to be set so the directory can be used, but the contents of this directory, which is what the share represents, do not.
Now we can change available to yes and click the Commit Changes button. Our restricted share is ready for use!
To test this, let's first make sure the share doesn't turn up in the local Samba browse list. We can perform this test using smbtree, like so:
bash-$ smbtree -N -b FED-CENTRAL \\CASA_DE_MICK iwazaru-ubuntu server (Samba, Ubuntu) \\CASA_DE_MICK\print$ Printer Drivers \\CASA_DE_MICK\SUPPER Mick's menus \\CASA_DE_MICK\CHORES Chore lists \\CASA_DE_MICK\IPC$ IPC Service (iwazaru-ubuntu server ↪(Samba, Ubuntu))
Sure enough, the new share BUZZ-OFF doesn't appear in the browse list. But, is it nonetheless usable by mick, its owner? Let's find out with smbclient:
bash-$ smbclient //CASA_DE_MICK/BUZZ-OFF -U mick Password: ******** Domain=[CASA_DE_MICK] OS=[Unix] Server=[Samba 3.0.28a] smb: \>
It worked. I've got a Samba prompt! There's no reason not to try a quick directory listing before exiting:
smb: \> dir . D 0 Tue Nov 4 23:17:34 2008 .. D 0 Tue Nov 4 23:17:34 2008 access-log_10312008.txt 665 Tue Nov 4 23:17:34 2008 52008 blocks of size 262144. 13229 blocks available smb: \> exit
Everything worked as expected. One last test—just to be sure, I want to try logging in to the share as a guest user. Remember that our Samba server is set up to treat any login involving a nonexistent user name as a guest login:
bash-$ smbclient //CASA_DE_MICK/BUZZ-OFF -U totallyfakeuser Password: ******** Domain=[CASA_DE_MICK] OS=[Unix] Server=[Samba 3.0.28a] tree connect failed: NT_STATUS_ACCESS_DENIED
It failed, in the expected and appropriate way. Our restricted share is accessible, insofar as we want it to be.