Paranoid Penguin - Samba Security, Part III

Now that the SUPPER share is configured and available, it should start showing up in the Network Neighborhood (or other Windows network browser) of users connected to the LAN. Your Samba server, which we've configured to be a Browse Master for its workgroup, achieves this by sending out broadcasts.

However, in my experience, network browsers are often unreliable—it can take a while for your new workgroup, servers and shares to show up, and sometimes things disappear for no apparent reason. (Even for Windows clients, using the Map Network Drive feature to specify your share's path is both faster and more reliable than using the Network Neighborhood browser.)

So although you might get decent results testing your new share by simply firing up a network browser, I recommend using Samba's command-line tools instead, namely, smbclient and smbtree, which are included in Debian and Ubuntu's smbclient package, and in Red Hat and SUSE's samba-client package. I'll leave it to you to explore the smbtree(1) and smbclient(1) man pages, but I will give you a couple usage examples.

smbtree is a text-based Windows network browser that sometimes performs better than GUI-based browsers. To view all available workgroups, servers and public shares on your local LAN, use this command:

bash-$ smbtree -N -b

smbclient is a much more versatile command that can be used both to view and use Samba shares. To use smbclient to connect to our new share as the user nobody (guest), you can type:

bash-$ smbclient //CASA_DE_MICK/SUPPER -U nobody

Note the share-name syntax: //<servername>/<sharename>. You can use an IP address instead of the actual server name; this can result in a quicker login, because it allows smbclient to skip the name-resolution step. (Have I mentioned lately how inefficient the SMB/CIFS protocol is?)

Note also that to test the Bad User (guest-failover) behavior I described earlier, this command should be functionally equivalent to the previous one:

bash-$ smbclient //CASA_DE_MICK/SUPPER -U totallyfakeusername

You'll be prompted for a password. Simply press Enter without typing one (your nobody account shouldn't have a password!). If everything is working, you should see something like this:

Anonymous login successful
Domain=[FED-CENTRAL] OS=[Unix] Server=[Samba 3.0.28a]
smb: \> 

At this point, you now have the Samba equivalent of an FTP shell—in fact, this environment is designed to be similar to FTP clients. To see a list of all available commands, you can enter ? or help. For now, we'll just do a quick directory by entering dir:

smb: \> dir
  .                            D     0  Tue Oct  7 13:22:28 2008
  ..                           D     0  Tue Oct  7 13:21:16 2008
  0-mon_filetmingon.txt             51  Mon Oct  6 21:05:34 2008
  1-tues_gruel.txt                  47  Tue Oct  7 13:05:54 2008
  2-wed_beefmushcasserole.txt        5  Tue Oct  7 13:06:32 2008

         52008 blocks of size 262144. 13782 blocks available

I'll leave it to you to figure out how to test copying files in both directions (put should work only for the user mick, but everyone else, including guests, should be able to list, get and read files).

On the strength of our SUPPER-creating experience, you'll find it fast and easy to create the group-readable share CHORES (which will contain lists of household tasks my boarders can perform in exchange for a rent discount). This share will be very similar to SUPPER: mick will have read and write access; pepe, skippy and knute will have read access only. However, unlike SUPPER, guest access will not be permitted.

Accordingly, after typing a new share name (CHORES) into the Create Share field and then clicking the Create Share button, we'll need to be sure to leave guest ok set to its default value of no. We'll set comment and path to Chore lists and /home/mick/chores, respectively (having first created this directory in a terminal window, and setting its ownership and permissions to be the same as for /home/mick/supper).

hosts allow and hosts deny can be the same as for SUPPER. browseable can be left at yes, but available should be left at no for now.

Figure 4 shows these settings (except available) for our new CHORES share.

Figure 4. Basic View Settings (Customized) for CHORES

Now, we'll switch to Swat's advanced view for this share (if you aren't there already) by clicking the Advanced button. As with SUPPER, we'll blank out admin users, because we're paranoid, and also read users, as read only already is set to yes.

As you can see in Figure 5, however, I'm employing a bit of useful laziness in the valid users field for CHORES.

Figure 5. Advanced Security Settings (Customized) for CHORES

In the valid users field in Figure 5, the + in front of users instructs Samba to look up the name users in /etc/group, and then replace this entire value with a list of all members of the group users. Because on this server that group consists of mick, knute, pepe and skippy, Samba ultimately will set the value of valid users to mick, knute, pepe, skippy.

Needless to say, be careful with group names in this context. Before using one in Swat (or directly in smb.conf), be sure you know for certain exactly which user accounts belong to that group.

The quickest way to do this is to look up the group name in /etc/group and note its numeric value, noting also any secondary group members it has. Then, see which users in /etc/passwd have that group's number listed as its primary group.

Here's how this looks when enumerating the group users on my Ubuntu system:

mick@ubuntu@:~$ grep users /etc/group

users:x:100:

mick@ubuntu:~$ grep :100: /etc/passwd

dhcp:x:100:101::/nonexistent:/bin/false
mick:x:1003:100:Mick Bauer:/home/mick:/bin/sh
knute:x:1004:100:Knute:/home/knute:/bin/sh
pepe:x:1005:100:Pepe:/home/pepe:/bin/sh
skippy:x:1006:100:Skippy:/home/skippy:/bin/sh

As you can see, there are no secondary users listed at the end of the user's entry in /etc/group. My second grep command turned up five users, not the four I was expecting, but dhcp matched only because its numeric user ID (not its group ID) is 100.

The other settings we should change are create mask, which we'll again set to 0644, and then browseable, which we now can safely change to yes. Finally, we can click the Commit Changes button, and CHORES is ready to go. Preferably using another system, test it to make sure it works the way you expect.