Samba - opening windows to a wider world

	WARNING: The "syslog" option is deprecated
	Unable to initialize messaging context
	

1. /etc/samba/smb.conf actually has a clause like :

   logging = syslog

2. A bug in smbclient itself. You can even reproduce it with :
   smbclient -L nothing.atThis.IP.address

   	WARNING: The "syslog" option is deprecated
   	Unable to initialize messaging context
   	WARNING: The "syslog" option is deprecated
   	do_connect: Connection to nothing.atThis.IP.address failed (Error NT_STATUS_HOST_UNREACHABLE)

   No fix/workaround so far

Fix the logging = syslog line of /etc/samba/smb.conf

1. Add to /etc/samba/smb.conf, within the [global] section :

   log level = logLevel

   With logLevel :

   logLevel	Usage
   0	(default) only critical errors and serious warnings will be logged
   1	reasonable level for day-to-day running : it generates a small amount of information about operations carried out
   2, 3	will generate considerable amounts of log data, and should only be used when investigating a problem
   4-10	these levels are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic

2. Restart Samba :
   systemctl restart smbd

• I have a pretty basic Samba setup with a single shared directory between a Debian Buster virtual machine and a Windows host.
• This directory only contains symlinks to other directories so that I can quickly add / remove shared resources without changing the configuration + restarting the daemon.
• Some of these symlinks point outside of the shared directory thanks to this hack.
• On the Windows client side, I can open the shared directory and see subdirectories (that actually are symlinks). But I can't follow anymore one of these links : Access denied, please contact your administrator error. This symlink points to an external USB drive.

• I re-formatted this USB drive lately from Ext3 to Ext4
• I also upgraded my workstation to Debian Buster

1. read daemon logs :
   journalctl -r -u smbd
2. read daemon logs in real time while trying to access the forbidden resource :
   journalctl -f -u smbd
3. review the cascading filesystem permissions :
   namei -lx /path/to/shared/directory
4. check the USB drive mount options
5. read client-specific logs :
   ls -ltr /var/log/samba
   ... and see what you can find in recently changed files. Consider tail -f ...
6. increase Samba's log verbosity, reproduce the error and check logs again

1. AppArmor current status (as root) :
   aa-status

   
   5 processes are in enforce mode.
   	/usr/sbin/smbd (830) smbd
   	/usr/sbin/smbd (833) smbd
   	/usr/sbin/smbd (834) smbd
   	/usr/sbin/smbd (835) smbd
   	/usr/sbin/smbd (3393) smbd
   

2. Let's disable it and see what happens :
   aa-complain $(which smbd)
   I can now access the USB drive via Samba !
3. Let's get more details :
   for i in $(grep logfiles /etc/apparmor/logprof.conf | cut -d '=' -f 2); do [ -e "$i" ] && grep -iq 'apparmor' "$i" && echo "'$i' matches"; done

   '/var/log/syslog' matches
   '/var/log/messages' matches

4. Are these distinct entries ?
   for i in /var/log/syslog /var/log/messages; do grep apparmor "$i" | tail -10 | md5sum; done

   9f03bd8f908cbe44f3e078c95a259be4	-
   9f03bd8f908cbe44f3e078c95a259be4	-

   Nope, so let's focus on /var/log/messages only, then.
5. Let's reproduce the error while watching real-time logs :
   tail -f /var/log/messages | grep apparmor

   Aug 27 11:23:02 localhost kernel: [ 9180.681476] audit: type=1400 audit(1566897782.433:2083): apparmor="DENIED" operation="open" profile="smbd" name="/target/of/symlink/on/usb/drive" pid=3393 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

6. What + where is the corresponding AppArmor profile file for Samba ?
   grep -r 'profile smbd' /etc/apparmor*

   /etc/apparmor.d/usr.sbin.smbd:profile smbd /usr/{bin,sbin}/smbd flags=(complain) {

7. Fix it !

• SMB is the protocol used by Windows for file and printer sharing. It is implemented by Samba for the same purpose.
• In 2017, the WannaCry ransomware attack exploited security vulnerabilities in Microsoft's implementation of the protocol (source).
• The version 1 of the SMB protocol is said to be vulnerable to some exploits (such as EternalBlue) allowing ransomware attacks (sources : 1, 2).

1. disable SMB1 on Samba
2. disable SMB1 on Windows clients

Disable SMB1 on Samba

Failed to restart samba.service: Unit samba.service is masked.

• Let's consider /path/to/sharedDir, a directory shared by Samba. It contains directories, sub-directories and files, and everything is going extremely well.
• Let's imagine /path/to/sharedDir/link, a symlink to /somewhere/else/someFile : the target is clearly NOT within the originally shared tree.
• With the appropriate smb.conf settings, it is possible to allow Samba clients to follow such links :
  • the snippet below only shows the minimal set of configuration options allowing to follow symlinks; this is not a functional configuration per se
  • allowing clients to follow symlinks pointing outside of the shared tree is considered a security hole and is not recommended

  [global]
  	allow insecure wide links = yes
  	unix extensions = no
  
  [myShare]
  	path = /path/to/sharedDir
  	wide links = yes

• But, Windows clients (tested with Windows 7) still refuse to display such symlinks

1. open a Windows shell having Administrator privileges
2. fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1

   L : local
   R : remote
   2 : "to"
   1 : enable

3. You can also edit these settings in the Registry (source) :
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\Symlink*
4. reboot to reload settings
5. If it still doesn't work, check this functionality is not disabled by a group policy (source) :
   fsutil behavior query SymlinkEvaluation

   Les liens symboliques local à local sont activés
   Les liens symboliques local à distant sont activés.
   Les liens symboliques distant à local sont activés.
   Les liens symboliques distant à distant sont activés.

6. Last but not least :
   Whether or not files / directories / links within shares appear on clients also depends on their *nix permissions .

workaround :

as root :
	mount --bind /directory/to/effectively/share /directory/shared/by/samba

Allow Samba to follow symlinks :

# (explicit)
follow symlinks = yes

# allows following symlinks outside of the shared directory
wide links = yes

# related to uid/gid between server and client, but also collides with 'wide links' above when enabled
unix extensions = no

DO's and DO NOT's of /etc/samba/smb.conf :

Let's get dirty !!!

Found this in old notes, not sure this is still true / useful :
				
If you just want to setup a network share with no special permissions (easiest but lowest security level), you just have to
					

						
switch from security = user to security = share
						
"chmod 777" the shared directory
					
				

A little less dirty setting :

[myShare]
	force user = kevin
	create mask = 0700
	directory mask = 0700

Quick reference

Access control

Users management

Utilities :

Let users mount / unmount Samba shares on Unix machines

Let Unix clients handle files bigger than 2GB