Section 11.3. Implementation

11.3. Implementation

The following procedures outline the implementation of the security measures discussed so far.

11.3.1. Share Access Controls

Access control entries placed on the share itself act as a filter at the time a when CIFS/SMB client (such as Windows XP Pro) attempts to make a connection to the Samba server.

CREATE/EDIT/DELETE SHARE ACLS

1.	From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator account (on Samba domains, this is usually the account called root).
2.	Click Start 3.	In the left panel, [Right mouse menu item] Computer Management (Local) OK Computer Management (Local) should now reflect the change made. For example, if the server you are administering is called FRODO, the Computer Management entry should now say Computer Management (FRODO).
4.	In the left panel, click Computer Management (FRODO) 5.	In the right panel, double-click on the share on which you wish to set/edit ACLs. This will bring up the Properties panel. Click the Share Permissions tab.
6.	You may now edit/add/remove access control settings. Be very careful. Many problems have been created by people who decided that everyone should be rejected but one particular group should have full control. This is a catch-22 situation because members of that particular group also belong to the group Everyone, which therefore overrules any permissions set for the permitted group.
7.	When you are done with editing, close all panels by clicking through the OK buttons.

11.3.2. Share Definition Controls

Share-definition-based access controls can be used like a checkpoint or like a pile-driver. Just as a checkpoint can be used to require someone who wants to get through to meet certain requirements, so it is possible to require the user (or group the user belongs to) to meet specified credential-related objectives. It can be likened to a pile-driver by overriding default controls in that having met the credential-related objectives, the user can be granted powers and privileges that would not normally be available under default settings.

It must be emphasized that the controls discussed here can act as a filter or give rights of passage that act as a superstructure over normal directory and file access controls. However, share-level ACLs act at a higher level than do share definition controls because the user must filter through the share-level controls to get to the share-definition controls. The proper hierarchy of controls implemented by Samba and Windows networking consists of:

1. Share-level ACLs

2. Share-definition controls

3. Directory and file permissions

4. Directory and file POSIX ACLs

11.3.2.1 Checkpoint Controls

Consider the following extract from a smb.conf file defining the share called Apps:

[Apps]    comment = Application Share    path = /data/apps    read only = Yes    valid users = @Employees 

This definition permits only those who are members of the group called Employees to access the share.

Note

On domain member servers and clients, even when the winbind use default domain has been specified, the use of domain accounts in security controls requires fully qualified domain specification, for example, valid users = @"MEGANET\Northern Engineers". Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a delimiter.

If there is an ACL on the share itself to permit read/write access for all Employees as well as read/write for the group Doctors, both groups are permitted through to the share. However, at the moment an attempt is made to set up a connection to the share, a member of the group Doctors, who is not also a member of the group Employees, would immediately fail to validate.

Consider another example. In this case, you want to permit all members of the group Employees except the user patrickj to access the Apps share. This can be easily achieved by setting a share-level ACL permitting only Employees to access the share, and then in the share definition controls excluding just patrickj. Here is how that might be done:

[Apps]         comment = Application Share         path = /data/apps         read only = Yes         invalid users = patrickj 

Let us assume that you want to permit the user gbshaw to manage any file in the UNIX/Linux file system directory /data/apps, but you do not want to grant any write permissions beyond that directory tree. Here is one way this can be done:

[Apps]         comment = Application Share         path = /data/apps         read only = Yes         invalid users = patrickj         admin users = gbshaw 

Now we have a set of controls that permits only Employees who are also members of the group Doctors, excluding the user patrickj, to have read-only privilege, but the user gbshaw is granted administrative rights. The administrative rights conferred upon the user gbshaw permit operation as if that user has logged in as the user root on the UNIX/Linux system and thus, for access to the directory tree that has been shared (exported), permit the user to override controls that apply to all other users on that resource.

There are additional checkpoint controls that may be used. For example, if for the same share we now want to provide the user peters with the ability to write to one directory to which he has write privilege in the UNIX file system, you can specifically permit that with the following settings:

[Apps]         comment = Application Share         path = /data/apps         read only = Yes         invalid users = patrickj         admin users = gbshaw         write list = peters 

This is a particularly complex example at this point, but it begins to demonstrate the possibilities. You should refer to the online manual page for the smb.conf file for more information regarding the checkpoint controls that Samba implements.

11.3.2.2 Override Controls

Override controls implemented by Samba permit actions like the adoption of a different identity during file system operations, the forced overwriting of normal file and directory permissions, and so on. You should refer to the online manual page for the smb.conf file for more information regarding the override controls that Samba implements.

In the following example, you want to create a Windows networking share that any user can access. However, you want all read and write operations to be performed as if the user billc and member of the group Mentors read/write the files. Here is one way this can be done:

[someshare]    comment = Some Files Everyone May Overwrite    path = /data/somestuff    read only = No    force user = billc    force group = Mentors 

That is all there is to it. Well, it is almost that simple. The downside of this method is that users are logged onto the Windows client as themselves, and then immediately before accessing the file, Samba makes system calls to change the effective user and group to the forced settings specified, completes the file transaction, and then reverts to the actually logged-on identity. This imposes significant overhead on Samba. The alternative way to effectively achieve the same result (but with lower system CPU overheads) is described next.

The use of the force user or the force group may also have a severe impact on system (particularly on Windows client) performance. If opportunistic locking is enabled on the share (the default), it causes an oplock break to be sent to the client even if the client has not opened the file. On networks that have high traffic density, or on links that are routed to a remote network segment, oplock breaks can be lost. This results in possible retransmission of the request, or the client may time-out while waiting for the file system transaction (read or write) to complete. The result can be a profound apparent performance degradation as the client continually attempts to reconnect to overcome the effect of the lost oplock break, or time-out.

11.3.3. Share Point Directory and File Permissions

Samba has been designed and implemented so that it respects as far as is feasible the security and user privilege controls that are built into the UNIX/Linux operating system. Samba does nothing with respect to file system access that violates file system permission settings, unless it is explicitly instructed to do otherwise through share definition controls. Given that Samba obeys UNIX file system controls, this chapter does not document simple information that can be obtained from a basic UNIX training guide. Instead, one common example of a typical problem is used to demonstrate the most effective solution referred to in the immediately preceding paragraph.

One of the common issues that repeatedly pops up on the Samba mailing lists involves the saving of Microsoft Office files (Word and Excel) to a network drive. Here is the typical sequence:

1.	A user opens a Work document from a network drive. The file was owned by user janetp and [users], and was set read/write-enabled for everyone.
2.	File changes and edits are made.
3.	The file is saved, and MS Word is closed.
4.	The file is now owned by the user billc and group doctors, and is set read/write by billc, read-only by doctors, and no access by everyone.
5.	The original owner cannot now access her own file and is "justifiably" upset.

There have been many postings over the years that report the same basic problem. Frequently Samba users want to know when this "bug" will be fixed. The fact is, this is not a bug in Samba at all. Here is the real sequence of what happens in this case.

When the user saves a file, MS Word creates a new (temporary) file. This file is naturally owned by the user who creates the file (billc) and has the permissions that follow that user's default settings within the operating system (UNIX/Linux). When MS Word has finished writing the file to disk, it then renames the new (temporary) file to the name of the old one. MS Word does not change the ownership or permissions to what they were on the original file. The file is thus a totally new file, and the old one has been deleted in the process.

Samba received a request to create a new file, and then to rename the file to a new name. The old file that has the same name is now automatically deleted. Samba has no way of knowing that the new file should perhaps have the same ownership and permissions as the old file. To Samba, these are entirely independent operations.

The question is, "How can we solve the problem?"

The solution is simple. Use UNIX file system permissions and controls to your advantage. Follow these simple steps to create a share in which all files will consistently be owned by the same user and the same group:

USING DIRECTORY PERMISSIONS TO FORCE FILE USER AND GROUP OWNERSHIP

1.	Change your share definition so that it matches this pattern: [finance] path = /usr/data/finance browseable = Yes read only = No
2.	Set consistent user and group permissions recursively down the directory tree as shown here: root# chown -R janetp.users /usr/data/finance
3.	Set the files and directory permissions to be read/write for owner and group, and not accessible to others (everyone), using the following command: root# chmod ug+rwx,o-rwx /usr/data/finance
4.	Set the SGID (supergroup) bit on all directories from the top down. This means all files can be created with the permissions of the group set on the directory. It means all users who are members of the group finance can read and write all files in the directory. The directory is not readable or writable by anyone who is not in the finance group. Simply follow this example: root# find /usr/data/finance -type d -exec chmod ug+s {}\;
5.	Make sure all users that must have read/write access to the directory have finance group membership as their primary group, for example, the group they belong to in /etc/passwd.

11.3.4. Managing Windows 200x ACLs

Samba must translate Windows 2000 ACLs to UNIX POSIX ACLs. This has some interesting side effects because there is not a one-to-one equivalence between them. The as-close-as-possible ACLs match means that some transactions are not possible from MS Windows clients. One of these is to reset the ownership of directories and files. If you want to reset ownership, this must be done from a UNIX/Linux login.

There are two possible ways to set ACLs on UNIX/Linux file systems from a Windows network workstation, either via File Manager or via the Microsoft Management Console (MMC) Computer Management interface.

11.3.4.1 Using the MMC Computer Management Interface

1.	From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator account (on Samba domains, this is usually the account called root).
2.	Click Start 3.	In the left panel, [Right mouse menu item] Computer Management (Local) OK Computer Management (Local) should now reflect the change made. For example, if the server you are administering is called FRODO, the Computer Management entry should now say: Computer Management (FRODO).
4.	In the left panel, click Computer Management (FRODO) 5.	In the right panel, double-click on the share on which you wish to set/edit ACLs. This brings up the Properties panel. Click the Security tab. It is best to edit ACLs using the Advanced editing features. Click the Advanced button. This opens a panel that has four tabs. Only the functionality under the Permissions tab can be utilized with respect to a Samba domain server.
6.	You may now edit/add/remove access control settings. Be very careful. Many problems have been created by people who decided that everyone should be rejected but one particular group should have full control. This is a catch-22 situation because members of that particular group also belong to the group Everyone, which therefore overrules any permissions set for the permitted group.
7.	When you are done with editing, close all panels by clicking through the OK buttons until the last panel closes.

11.3.4.2 Using MS Windows Explorer (File Manager)

The following alternative method may be used from a Windows workstation. In this example we work with a domain called MEGANET, a server called MASSIVE, and a share called Apps. The underlying UNIX/Linux share point for this share is /data/apps.

1.	Click Start 2.	You may now edit/add/remove access control settings. Be very careful. Many problems have been created by people who decided that everyone should be rejected but one particular group should have full control. This is a catch-22 situation because members of that particular group also belong to the group Everyone, which therefore overrules any permissions set for the permitted group.
3.	When you are done with editing, close all panels by clicking through the OK buttons until the last panel closes.

11.3.4.3 Setting Posix ACLs in UNIX/Linux

Yet another alternative method for setting desired security settings on the shared resource files and directories can be achieved by logging into UNIX/Linux and setting POSIX ACLs directly using command-line tools. Here is an example session on the same resource as in the immediately preceding example on a SUSE 9 Linux system:

1.	Log into the Linux system as the user root.
2.	Change directory to the location of the exported (shared) Windows file share (Apps), which is in the directory /data. Execute the following: root# cd /data Retrieve the existing POSIX ACLs entry by executing: root# getfacl apps # file: apps # owner: root # group: root user::rwx group::rwx other::r-x
3.	You want to add permission for AppsMgrs to enable them to manage the applications (apps) share. It is important to set the ACL recursively so that the AppsMgrs have this capability throughout the directory tree that is being shared. This is done using the -R option as shown. Execute the following: root# setfacl -m -R group:AppsMgrs:rwx /data/apps Because setting an ACL does not provide a response, you immediately validate the command executed as follows: root# getfacl /data/apps # file: apps # owner: root # group: root user::rwx group::rwx group:AppsMgrs:rwx mask::rwx other::r-x This confirms that the change of POSIX ACL permissions has been effective.
4.	It is highly recommended that you read the online manual page for the setfacl and getfacl commands. This provides information regarding how to set/read the default ACLs and how that may be propagated through the directory tree. In Windows ACLs terms, this is the equivalent of setting inheritance properties.

11.3.5. Key Points Learned

The mish-mash of issues were thrown together into one chapter because it seemed like a good idea. Looking back, this chapter could be broken into two, but it's too late now. It has been done. The highlights covered are as follows:

• Winbind honors and does not override account controls set in Active Directory. This means that password change, logon hours, and so on, are (or soon will be) enforced by Samba winbind. At this time, an out-of-hours login is denied and password change is enforced. At this time, if logon hours expire, the user is not forcibly logged off. That may be implemented at some later date.

• Sign'n'seal (plus schannel support) has been implemented in Samba-3. Beware of potential problems acknowledged by Microsoft as having been fixed but reported by some as still possibly an open issue.

• The combination of Kerberos 5, plus OpenLDAP, plus Samba, cannot replace Microsoft Active Directory. The possibility to do this is not planned in the current Samba-3 roadmap. Samba-3 does aim to provide further improvements in interoperability so that UNIX/Linux systems may be fully integrated into Active Directory domains.

• This chapter reviewed mechanisms by which Samba servers may be kept secure. Each of the four key methodologies was reviewed with specific reference to example deployment techniques.