Paranoid Penguin - Samba Security, Part III

This month, we continue our exercise in building a secure file server for our local LAN using Samba. In case you missed the first two installments, this is a non-Internet-accessible file server to which users of a LAN can mount virtual disk volumes.

The example scenario I'm using is a boarding house in which I need to provide a world-readable file share containing menus (SUPPER), a group-readable share containing schedules of chores (CHORES) and a private share containing copies of Web logs (BUZZ-OFF).

Last month, we used Samba's Swat tool to configure our Samba server's Global settings. We then created four user accounts: mick, knute, pepe and skippy. Mick, of course, is me. Knute, Pepe and Skippy are the three FBI agents who rent my rooms and who are interested in my daily menus and weekly schedules of chores, but with whom I'd rather not share my Web logs.

This month, we create a public share for menus called SUPPER and a nonpublic but group-readable share for chore lists called CHORES. (We'll save the private share, BUZZ-OFF, for next time.)

As we've seen, Swat is arguably the best tool for configuring smb.conf, Samba's primary configuration file. Other tasks, like creating new user accounts, are best done from a command line (last month, we used the standard commands useradd and passwd to set up our accounts under Linux, and then smbpasswd to create corresponding Samba accounts).

To create shares, however, we can return to Swat. Unsurprisingly, the navigation button you must click is labeled Shares. After you do that, type the name SUPPER in the box to the right of the Create Share button, and then click that button. You should see something like Figure 1.

Figure 1. Creating a New File Share

Under Base Options, I set comment to Mick's Menus. Then, I set path to /home/mick/supper. This will be our weekly menu folder.

The value of path has to correspond to a real directory on your server. Furthermore, the Linux permissions and ownership of this directory need to be set to allow the desired level of access you want to grant. In this example, the directory listing of /home/mick/supper looks like this:

drwxr-xr-x 2 mick users 4096 2008-09-12 01:44 supper/

As you can see, the user mick has read-write-execute permissions, but group and other have only read-execute permissions. Now isn't the time for a primer on filesystem security (actually I've already written one: “Linux Filesystem Security”, in the October and November 2004 issues of Linux Journal). Suffice it to say for now that the commands for creating directories, setting user and group ownership and setting permissions, respectively, are mkdir, chown, chgrp and chmod.

Let's set some security options shown in Figure 1. By default, at least on Ubuntu systems, Swat displays only four options under this section in its basic view, but that's a reasonable starting point.

The first of these is read only, which I leave at the Ubuntu default of yes, even though I want the user account mick to be able to publish new menus. (The setting write list, which I'll describe a little later in this article will override this setting.)

The second security setting shown in Figure 1 is guest ok, which I change to yes. (My guests, and those of my boarders, certainly will be keenly interested to know what side dishes will accompany Tuesday night's Coconut Tater-Tot Casserole.)

I should pause here for a quick review of how guest access works in Samba. Last month, when we configured Samba's global settings, we set the option map to guest to Bad User, which caused Samba to treat clients who log in with nonexistent user names as guests. We set the option guest account to nobody, which means that when people log on as a guest (either by providing a bad user name or by actually logging in as nobody), they will be logged in under the account nobody.

None of these global settings has any effect on a given share unless that share's guest ok option is set to yes. As we'll see shortly, that doesn't actually give guests any permissions on that share unless we do just a little more work.

First, there are two more security options to attend to in Figure 1: hosts allow and hosts deny can be used to define TCP Wrappers-like, network-level access controls on your share. You can learn everything you need to know about this from the hosts_access(5) man page.

In Figure 1, hosts allow will be set to 192.168.44., which means “allow access from clients whose source IP address' first three octets are 192.168.44”. In our example scenario, this corresponds to my local LAN address of 192.168.44.0/24. hosts deny is set to ALL, which means “deny access to all clients who do not match any value in hosts allow.”

In my opinion, there's no good reason not to use hosts allow and hosts deny with Samba unless your LAN is very complicated. It's not as important as making proper use of user and group accounts, enforcing the use of strong passwords and other things you should be doing, but it's nonetheless a useful layer in our defense onion.

At this point you may be wondering, how do we tell Samba who has write access and who has read-only access for this share? The four security options we've covered don't address that. The answer is, we've already established some default settings for this in the global section, and share-specific authorization controls can be set by switching from basic to advanced view in Swat, by clicking the Advanced button near the top of the screen. When you do that, you'll see something like Figure 2.

Figure 2. Share Security Options in Advanced View

But wait, what's this? Where did those values for valid users, read list and so forth come from, given my earlier sidebar note about these screenshots showing default settings?

As it happens, many of Samba's options can be declared both as global settings and as share-specific settings. When you set up a new share, Swat copies the values of any such options you set up under the global settings to the new share. So, Figure 2 represents Swat's settings after I've set up the global section but before I've fine-tuned the SUPPER share.

And, I do need to fine-tune it! On the one hand, invalid users is set to root as in the corresponding global option, which is a good value to propagate here; it's never a good idea to log in to much of anything directly as root.

But because I want this to be a public share, I'm going to remove all the users listed in valid users, which will have the effect of allowing clients to log in using any user name they provide. (Remember, though, anyone logging in with a user name outside the Samba user database or /etc/password will be logged on as nobody—that is, as a guest.)

Similarly, I'm going to empty read list as well, as read only is set to yes anyhow. (read list is sort of a blacklist: anyone whose user name is listed here will be granted only read access to this share regardless of any other setting in this share or under Globals.)

Another setting I'm going to empty is admin users. Like I said last month, this is a dangerous setting, and it's usually unnecessary. (I really shouldn't have set it to mick in the global section!) Not only will admin users operate with full Linux root privileges, all files they create will have a user owner of root, which can complicate both Samba and Linux filesystem permissions. Most of the time you might be tempted to set this option, it's probably sufficient instead simply to give that user write access.

And, you can do that with the option write list. In this case, we can leave the value of mick inherited from Globals.

The last security setting to change is create mask. This option determines the UNIX permissions that will be given to any files moved into or created in the share. Its value must be a chmod-style octal mode, as described in the chmod(1) man page.

The default value 0744, shown in Figure 2, translates to “owner read+write+execute, group read, other read”. However, because this share is going to contain text files, there's no reason for the group-execute bit to be set; 0644 (owner read+write, group read, other read) is a better choice.

To review, and for clarity's sake, Figure 3 shows the changed settings for these security options in Swat's advanced view.

Figure 3. New Share Security Settings

We're almost done configuring this share. There are just two more options to check, and now you can switch back to basic view to find them quickly. The Browse Option browseable is set to yes by default on Ubuntu systems, which is appropriate for a public share.

The EventLog Option available, on the other hand, which is used to enable or disable a share, has the rather sensible default value of no. I say sensible, because it's never a good idea to activate anything before you're finished configuring and securing it! But, we are in fact done securing this share, so we'll change available to yes.

The last step is to click the Commit Changes button near the top of the Swat page. On my system, any time I click this button, the view resets to what appear to be default settings for printer shares! If this happens on your system too, all you need to do is click the Choose Share button again to display the changes you just committed.

After you create, delete or reconfigure a share, the changes will be applied immediately to your running Samba dæmons; there's no need to restart any of them.