S 4.332 Secure configuration of the access controls for a Samba server

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Samba leaves control access in the file system to the kernel of the operating system. For this reason, both a Windows user account and a Unix user account must be available for every user on the Samba server. This means that every domain user must exist in the Unix operating system together with all their group memberships.

Access control is complex when using Samba for two reasons. One reason for this complexity is that Samba cannot map the Windows rights model directly to the Unix model and another reason is that Samba evaluates the following layers when accessing the file system:

Unix file authorisations

If a user wants to access a share of a Samba server, the user must log in to the Samba service first. Samba then checks whether or not the user who logged in has the rights needed for access in the Unix file system.

Samba maps the Windows rights model in the following manner to the Unix file system: an NT ACL with three elements is formed from the standard Unix triplet "user" / "group" / "others". The Unix right bits are mapped in this case to the NT authorisations as shown in the following table. The right bits for "others" are mapped by Samba to the "Everyone" group. ACL entries for denying a user certain NT authorisations cannot be specified.

NT authorisation File attributes flag
Full Control #
Search Folder / Execute File x
List Folder / Read Data r
Read Attributes r
Read Extended Attributes r
Create Files / Write Data w
Create Folders / Append Data w
Write Attributes w
Write Extended Attributes w
Delete Subfolders and Files w
Delete #
Read Authorisations See text
Change Authorisations #
Take Ownership #

Table: Mapping the rights model to Unix file systems

The "#" character means that this authorisation is only set for a file or a directory under two conditions: either when a Windows administrator enables the "Full Control" authorisation or when the user or his/her group are authorised to "read", "write", and "execute" this file in the Unix file system. The NT "Read Authorisations" authorisation is always granted to a user as soon as the user has been granted at least one additional NT authorisation.

If Windows NT4 authorisations that are not listed in this table are set, these authorisations will be ignored by Samba. Any Portable Operating System Interface (POSIX) ACL entries existing will be implemented in the same manner by Samba in the NT rights model. POSIX ACLs are only used by Samba to specify the authorisations for users and groups when these are not the owner of the file or of the directory.

Samba can map the DOS attributes in several different ways. These attributes are file properties that do not exist in this form in Unix. Many applications that access network drives require the existence of properly functioning DOS attributes, however. There are a total of four different DOS attributes that can be assigned to files:

Samba maps DOS attributes by default to Unix bits:

Attribute Unix right Mask Parameter Default value
Read-Only w owner 200 map read only yes
Archive x owner 100 map archive yes
System x group 010 map system no
Hidden x others 001 map hidden no

Table: Mapping the DOS attributes to the Unix file system

Since the "execute" right does not exist in DOS, the corresponding bit can be used to map the DOS attributes to the Unix file system permissions. The read-only bit in DOS has a counterpart in the write privilege granted to the owner of the file in Unix, which offers almost the same functionality.

Samba needs to create the appropriate attributes for the files from the Unix rights for the Properties dialogue in Windows. Furthermore, Samba also needs to assign Unix rights to the new files created. When a new file is created, the client passes the desired DOS attributes to the server. Using these attributes from the client, Samba forms a set of Unix access rights. These rights are then restricted using the "create mask" parameter. The default mask for "create mask" is 744, which corresponds to the mask rwxr--r--. The owner of the file has read and write privileges and everyone else only has read privilege.

Samba restricts the rights by logically ANDing the desired set of rights with the create mask. Only the rights that are set in the "create mask" can be assigned to the new file created. In an additional step, Samba explicitly sets the desired access rights based on the "force create mode" parameter, whose default value is set to 000. This is done by ORing the rights with this value.

If only the file owner and the group should have read permission for the new files created and everyone else should not be allowed to read the files, set the create mask to 740. This masks out the read privilege for the rest of the world. If the owner's group should also be granted a write privilege, this can be achieved by setting "force create mode = 020". The table below illustrates this process:

Group is provided with a write privilege      
Task to be performed     rw-r--r--
Create mask 740 AND rw-r-----
      rw-r-----
Force create mode 020 OR ----w----
Result     rw-rw----

If "map read only = yes" is specified in the smb.conf configuration file, Samba responds in the following manner: If the DOS attribute "read-only" is set, Samba sets the "w" bits of the owner / group / others of the file system object to "0". The "w" bits in ACLs are ignored by Samba. In contrast, if the DOS attribute "read-only" is not set, Samba only sets the "w" bit of the owner of the file system object to "1". The "w" bits for group / others are left set to "0". In addition, there is also the "map read only = Permissions" parameter. Information on this parameter can be found in the man page for smb.conf.

It must be noted that the "create mask" and "directory mask" parameters in Samba can prevent the Unix right bits from being set, in which case the DOS attributes will not be mapped. The "mask" column specifies the minimal values for the "create mask" and "directory mask" parameters that are required so that Samba can set all Unix right bits needed.

Under certain conditions, conflicts may arise between the Unix authorisations derived from the DOS attributes and the Unix authorisations derived from a Windows ACL.

The parameters below, which are used by Samba by default to map DOS attributes to the Unix file system, should not be used. Instead, Samba should be configured in such a way that it saves DOS attributes in "extended attributes". The following settings must be specified in the configuration file smb.conf for this purpose:

store dos attributes = yes

map archive = no

map read only = no

Samba share definitions

The administrator can influence the control of access to shares and the response when users interact with the share using a number of configuration parameters available in the configuration file smb.conf.

The user-based and group-based configuration parameters overwrite the access authorisations for users or groups that are valid in the Unix file system. The following configuration parameters are available:

The following configuration parameters control the response of shares to operations on files and folders. The man page for the smb.conf configuration file should be considered before changing any of these parameters:

Furthermore, there are also various settings that affect the response of shares in different ways. The man page for the smb.conf configuration file should be considered before changing any of these parameters:

For a detailed description of all configuration parameters, refer to the man page of the smb.conf configuration file ("man smb.conf").

Samba share ACLs

With Samba, an ACL can be created for each share just like in Windows. No restrictions are enabled by default. This means that the user "Everyone" has the "Full Control" authorisation.

Samba saves the ACLs for shares in the share_info.tdb file. However, Samba does not provide a program to manage these ACLs. The administrator is therefore dependent on Windows. The administrator has the following choices in Windows:

If all rights are revoked from the "Everyone" user without completely deleting it from the ACL of the share, no user will have access to the share any more. The reason for this is that ACL entries that reduce the rights of a user have priority over ACL entries that extend the rights of a user.

Review questions:

© Federal Office for Information Security. All rights reserved.