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.)

Creating a World-Readable File Share

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.

A Note on Figures 1 and 2

The screenshots in Figures 1 and 2 show Ubuntu's default values for
the various settings in Swat. They, therefore, do not provide,
all by themselves, a model of how to configure Samba securely! Read the
accompanying text for my recommended (secure) settings.

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.

upon closer inspection, when trying to force a Bad User with "totallyfakeusername", I do not get an "Anonymous login successful" message, and alss the domain is different,
Domain=[MYSERVER] instead of Domain=[MYWORKGROUP]. I still get a "tree connect failed: NT_STATUS_ACCESS_DENIED" error.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.