Never forget that your system running Samba is a file server, likely containing confidential information. As such, it is imperative that you put in appropriate controls to limit access to files and directives. If your server is only a fle server and does not grant any shell access, then your job is relatively easy: Almost all of the work can be done using Samba security controls. If the server also grants shell access (via Telnet, SSH, etc.) then your job becomes much more difficult.
The process recommended by both the book and myself. It begins with the Rings of Security model at the file system level, and will work with any POSIX compliant file system (ext2, ext3, XFS, reiserfs, JFS, etc.).
The default behavior for most UNIX systems is to place users in User Private Groups (see UNIX02/User Accounts And Groups) from UNIX02). This can be fine for systems which have a small number of users, however may not be such a good idea for larger systems. Sometimes it is more desirable to assign every user on the system some common group (such as 'user') or to perform some subdivision amongst the users (such as groups for 'pr', 'sales', 'lab', etc).
File and Directory Masks for Shares
When setting up paths for the shares via Samba, remember to never share the root directory. If you do, you are just asking for trouble. Additionally, you may wish to have whatever sub-directory houses your Samba shares to be on a seperate partition such that, if it fills up, the system will still function.
There are two general types of Samba shares. In one type, you want to allow everyone access; in the other you want to limit access. We will go through this excercise working with two shares called "public" and "private". The techniques discussed here can be tailored to your specific need. Let's place these shares in the /home/samba directory:
Now, we change the mode on the public directory to 2775, and change the mode on the private directory to be 2770. We change the ownership on the public directory to be group "users" and to group "private" for the private directory (making sure these groups exist first).
Now, all access to these directories will be via group permissions. Since we plan to have a guest account, the public directory will be read-only to the guest user, and the private directory will be inaccessable.
The sticky-bit (which we covered last time) has been set on both directories to more closely mimic the default behavior of a Windows NT server. When a user creates a file, his UID and primary GID are used to assign rights. If you are using User Private Groups, then new files created will be inaccessable to others within that directory tree. Note here that the umask settings which we discussed last time will not be honored by the Samba server (this is incorrect in the book) as Samba will not load anything from the user's setup scripts. Instead, we must enforse a mask using the create mask settings discussed in the previous course (See UNIX02/SAMBA Configuration in UNIX02).
See also page 219 of the book for an example smb.conf section implimenting this setup
Shared Read and Write Lists
As was mentionned in the previous course, one of Posix's shortcomings with respect to some other OSes (such as MS Windows) is that you lack some of the finer access control found on the other systems. Using Samba, you can actually recreate this access control to a fine degree. If used correctly, and when limitting shell access on a Samba server, you can actually use Samba to increase the security on a given system. Because of this, there is actually the argument to use Samba even when there are no Windows machines around.
One of the ways used to create pseudo access control lists (ACLs) is to use the write list and read list directives
write list = bob, larry
read list = mark, dave
Real ACLs are possible on Linux, you just have to be willing to get off the beaten track a bit. There is an effort to standardize Posix ACLs such that all Posix systems can impliment them without breaking standards. There are a number of competing methods available for achieving the goal of real ACLs. One is a kernel patch available from http://acl.bestbits.at/ that works with ext2, ext3, reiserfs, JFS and XFS. However, the other is simply to use SGI's XFS, whcih supports ACLs right out of the box. Each has advantages:
Bestbits Advantage : If you already have a functioning Samba server on a standard file system, then you can add real ACLs by simply recomipling your kernel. You do not need to change the file system (a non-trivial task) and you can keep all your files, users, etc intact.
XFS Advantage : If you are setting up a new Samba server, XFS will likely be the easier solution. Most kernels these days ship with the XFS patch already enabled, thus XFS is supported right out of the box.
With either of these solutions, you will have to ensure that Samba has been compuled with the with-acl-support option. Chances are that it will have been (recent Red Hat and Debian installs support this option) but if it has not, then check with the HOWTOs on the Samba site (http://www.samba.org/) to find out the best way to compile it with this option.
The one caveat with both of these methods is that many common backup utilities will not backup these ACL properties. In order to successfully back them up, you will have to do some research to find an appropriate tool. XFS does come with a utility called xfsdump which acts very much like the standard UNIX dump application except that it retains ACL information. If you can find a backup tool that is built around dump (and many are), then it is a simple matter to replace the UNIX dump with xfsdump if you are using XFS to accomplish ACLs.
