Security Implications of Samba Access to non-ACL File Systems

Several processes control the flow of data through a Samba-managed network connection. Ironically, the most important of them has nothing to do with networking.

When it comes to authorization and authentication of data transfers, Samba, SMB (Server Message Block), CIFS (Common Internet File System), and NFS (Network File System) can and should be integrated into a Network Access Control (NAC) strategy. However, these protocols are limited in their ability to restrict or manage data access, primarily because they are data agnostic.

A network file sharing protocol between two systems should require securing more than the network connection itself, but that is not a foregone conclusion. A robust access control system at the file level is a critical component of host data protection. This is particularly true of Linux and UNIX, which do not incorporate such protection by default.

We rely on Samba to maintain the sanctity of transmitted data in situ, but we cannot rely on it to know what it should or should not be allowed access to when it comes to the actual content. Samba has some built-in control capabilities, but the real power in access control lies in the file and directory permissions of the host server. On Linux devices, the NFS networking protocol affords a limited level of protection.

Samba and NFS' Presumed Trust Model

Samba and NFS both utilize an implied trust model of authorization. If you pass their authentication test, you're good-to-go, and data transfers may proceed. This forces the file system into position as the last vestige of security. A valid question is: Does the host system incorporate a file-level ACL? If not, it means the entire file system is now accessible to any user authenticated via Samba, regardless of their credentials.

One can think of it this way: If the target system accepts the incoming Samba connection, it is giving the remote connection carte blanche access to files on the target system device. The question then becomes, does the target system employ ACLs on its file system? If not, the file system is wide open.

As a result, a crucial need exists for a final layer of control exercised by the target system, in order to ensure only specific files may be shared. Quite frankly, Samba doesn't have a clue. NFS does partially, but it essentially trusts whatever you tell it is reality. For the most part, even native NFS transmissions are inherently insecure from a file permission perspective on both source and target systems.

File System ACLs: The Real Gatekeeper

Virtually any file system you apply to a Linux operating system (such as Ubuntu) will have ACL capabilities. ACL stands for "Access Control Lists." In simple terms, it means the file system is capable of restricting access to files and folders (directories) based on a user's credentials. A key question in securing data when a server is accessible via Samba is whether or not a target system employs an Access Control List (ACL) at the file level to limit access to its files. That may sound redundant in our modern age; however, the fact is non-ACL file systems do exist.

Perhaps more importantly, it is possible to turn off ACL on many modern file systems (for example, ext2 and ext3 in Linux)![1] And furthermore, the presence of an ACL over local files does not guarantee there truly is an ACL. Semantically, it may exist, but functionally it may not. In fact, many common Linux file systems can be forced to a non-ACL state. In short, this issue should not be dismissed without verifying a host server's devices are using ACL; particularly if the server(s) are available to external networks by any means.

Linux Multi-Layer Approach

Linux distributions ACLs utilize a multi-layered approach to file permissions. Every process on the device belongs to a user group and has a user name. The user must have permission to access the device. The folder or directory must allow the user access to where a given file is located. And finally, the user must have access to the specific file they wish to access. User permissions comprise the combination of group access and user level access. You must have both.

When Samba initiates a connection with a remote host, it identifies the connecting user by group name and user name. These values are specified in Samba's configuration file.

A Layered Defense

When you access a host remotely via Samba, you are in essence granting the remote user direct access to the server's file system. That means that remote user will potentially be able to read, write, modify, and delete your files. Obviously, wrapping constraints around that access should be a priority. And that means forcing a user to jump through multiple authentication hoops prior to allowing a command against a file on the remote server.

Accessing content on a remote server via Samba requires the user to pass through three (3) layers of authentication for every file transfer or modification request. Authorization is another matter (described below as a 4th layer). As we will see shortly, lack of a proper ACL on the host can result in a failure of the authorization process, and potentially allow rogue actors to manipulate the host server's files at will. But first, let's clarify what protections the Samba connection has to go through.

Layer 1 (Authentication): Independent Samba Connection Components

Samba has two components: a client interface and a host interface. Each operates independently and exclusively. A server may have both a Samba client and Samba server interface running, but they will not be interconnected.

A remote user connecting via Samba must first pass Samba's authentication process. When initiating a Samba client process, the application or user must provide a username and password. These are Samba usernames and passwords. The Samba host process on the other end of the transaction will compare these values to its database of allowed connections before allowing the connection to complete.

Note that if anonymous logins are allowed on the host server end, this process is skipped.

Layer 2 (Authentication): NFS and CIFS Client/Host Authentication

What about the network protocol? Does it matter if the Linux portion is connecting via NFS or CIFS? Yes.

NFS and CIFS only conduct authentication when the client is attempting to initiate a connection with the host. This process is called "mounting," which refers to creating a virtual mount on the client side of a virtual disk that acts like whatever it's connected to on the host end. Both will behave as if the target device were connected directly to the client operating system.

Once that connection is established, as far as NFS and CIFS are concerned, the client user has access to all the shared data in the connected resource (device), and they will not conduct any further authentication steps. The channel is open and data will flow freely in both directions.

When Samba is brokering the connection between two servers, it handles this process on the Linux server side of the equation. Note that Samba can be used between two Linux servers.

NFS Only: Restricted IPs

NFS maintains a table of allowed IP addresses and/or ranges. If the client connection isn't coming from one of them, the connection will be disallowed. CIFS does not have this feature. There are many switches in Samba that can be used to restrict access to specific shares or restrict all share access to specific users and other criteria. IP addresses happen to be one that is also possible with NFS, which means the NFS process itself might be the bottleneck if a connection is not allowed based on IP.

Layer 3 (Authentication): Server Username

On a Linux device, if the Samba host server implementation accepts the Samba client's connection request, the server will compare the Samba user credentials with its username and permissions records for the network connection protocol (e.g. NFS or CIFS). The network device itself - like any other device in Linux - has its own ACL (Access Control List). If the Samba user's credentials do not match the network interface ACL of the host server, the connection will be disallowed.

Layer 4 (Authorization): The File System

The last security step when a specific directory or file is requested is to validate the user is authorized. This process comes down to the file system, and is truly the heart of where Samba security and access should primarily be focused.

Solving ACL Issues with VFS

Recent Samba iterations (versions 4.x in particular) allow the incorporation of add-on modules called Virtual File System (VFS) modules. VFS are extensions to Samba's built-in functionality. For example, there are several existing VFS modules pertaining to file system ACLs, including the ability to copy and convert Windows NTFS ACL rules to a Linux server or export ACL rules. There are a variety of VFS functions. I encourage you to check out VFS as there are a number of useful features. VFS modules are free.

More information may be found in the Samba Wiki, including a list of current Samba VFS modules and how to build your own custom VFS module.


Remote access to network-connected resources is a multi-layered process. One of the links in the chain is the actual file access at the remote connection. The use of ACLs is a basic tenet of system administration, and file and disk access authorization. However, the presence of an ACL should not be presumed as a foregone conclusion. Careless management of ACLs on target systems (or a failure to notice their omission) exposes a significant potential risk of unauthorized file access via network protocols. This is particularly true when using network file transfer protocols such as Samba or NFS, which utilize single-instance authentication checks only during network connection initialization.

[1] Danen, V. (10 July 2006). Learn to use extended filesystem ACLs. TechRepublic.