File-Sharing under Linux, using Usershares – the Modernistic Way.

One concept which readers may already know, is that under Linux, we can set up a Samba-server, which makes the sharing-out of our home directories possible, and that if we fiddle with the ‘smb.conf’ configuration file thoroughly enough, it becomes possible to browse the available shares on a LAN, in a way semi-compatible with Windows computers that also reside on the same LAN.

Traditionally, this has always been a bit of a PITA, especially since the ‘/etc/samba/smb.conf’ configuration files have been finicky, and since each share practically needs to be configured individually, by a person with the ‘root’ password.

Well an alternative exists under Linux as well, which is the concept of ‘Usershares’. With this concept, each user who belongs to a specific group has the privilege, of designating a folder within his desktop manager, to share out, pointing-and-clicking. This is closer in ease-of-use, to how the process works under Windows. But, it needs to be set up correctly once, by the sysadmin, before it will work as often as simple users wish it to work.

I think that an existing Web-article on the subject, already explains well, what the settings in the ‘smb.conf’ file need to be, as well as what directories need to exist, in order for usershares to work. Except that the article I just linked to, refers to Fedora and SELinux systems and their norms. I happen to be based on Debian and KDE 4 or Plasma 5. And so I have a few observations to add:

Firstly, the following packages should be installed, under Debian also:

 


#apt-get install kdenetwork samba

 

Secondly, ‘/etc/samba/smb.conf’ needs to be edited like so:

 

screenshot_20180324_205625

 

Under Debian, the directory ‘/var/lib/samba/usershares’ already exists, If the relevant packages are installed. And its permission-bits have already been set as they should be set. Only, the feature is not configured in ‘smb.conf’ by default. And, the additional package named ‘kdenetwork-filesharing’ needs to be installed, in order for the tab to appear in Dolphin’s File-Properties box, that enables sharing from the GUI. Aside from that, enabled users need to be added to the ‘sambashare’ group, after which this membership only goes into effect, once the user in question has started a new session…

(Info Corrected 03/25/2018, 17h10,

Updated again 03/28/2018 … )

(As Of 03/24/2018 : )

screenshot_20180324_211445

 

I tested this feature and find it works well. From the sharing computer, the user sees this:

screenshot_20180324_195729

 

screenshot_20180324_195808

 

And from a different computer on the same LAN, another user gets to see this:

 

usershares_1

 

(Correction 03/25/2018 : )

There is one slight security-disadvantage however, to doing it this way. If the user who shares out a folder does not set ‘allow guests’, this means that the user who is browsing, must authenticate first. The disadvantage here is in the fact that the Samba password to use, is the same, as the log-in password of the user who is sharing out the folder.

What I have seen through simple experimentation, is that at least under Debian, the sysadmin must still use the ‘smbpasswd’ command, with the ‘-a’ option, to create a Samba-password for a specific user, before that user can create usershares which require authentication. After that, the user in question can use the ‘smbpasswd’ command himself, without any options, to change his Samba password.

I see this as a big bonus, because it means that the Samba password for any user can be different from their log-in password. This would mean that even if the Samba password was ever compromised, the actual log-in password of the same user, would not have been compromised.

Of course, enabling this feature will require the following setting in the ‘smb.conf’ configuration file:

 


   unix password sync = no

 

There’s another observation to add, this time having to do with encrypted transport. Our passwords are already encrypted by default. But the setting, to encrypt the data as well, is generally not compatible with ‘guest ok’. The reason for this is the fact that in order for encryption to work, a piece of information needs to be visible to both the server and client, which even a potential eavesdropper cannot derive from the full negotiation. And that piece of information is actually, the password.

This would mean that, If the sysadmin was to set:

smb encrypt = desired

Globally, Then, the server would respond to any capability the client announces, of using encryption, and would then enforce that all the remaining data of the session be encrypted. But in the case of ‘guest ok’, there would be no valid password to give, and the session would presumably fail.

And so the highest global setting on the server, If ‘guest ok’ was permitted for the usershares, would be:

smb encrypt = enabled

This way, encryption is not enforced globally, by the server, so that unencrypted access to anonymous shares can succeed. But it also means that encryption will not be applied, unless either:

  • The client requests it explicitly, or
  • A specific share has been set up in the ‘smb.conf’ file on the server, which upgrades its own requirements to, say, ‘smb encrypt = desired’.

(Updated 03/25/2018, 17h10 : )

And yet-another observation to add, has to do with the standard Homes share, that Debian flavors of Samba have set up. This share becomes visible to browsers, whose user-names and passwords match a Samba user-name and password. The concern might come to some users, that if their Samba-password was in fact compromised, then this would also have led to an attacker being able to browse this Homes share. Where then, the security of not having this password the same as the log-in password?

And one possible answer to that question would be, that by default, the Homes share is read-only, as well it should be. This means that if an attacker had obtained a user’s Samba-password, he would have been able to browse and read-from his Homes share as well, but not to write to the Homes share. The attacker would only have been able to write to folders, which the user specifically enabled as usershares.

Yet, If the sysadmin fears that:

  • A potential attacker is a sophisticated attacker, who can exploit read-only access to users’ folders, and/or
  • The actual users’ passwords might be weak,

Then a further measure to strengthen security would be to set the following:

 


[homes]

(...)

;   valid users = %S
   valid users = nobody

 

This should effectively disable the feature.

However, I suspect that a practical usage-consideration would be, that the user appreciates being able to read data from their home-folders, and is confident in his or her ability to keep their password secret. In that case, their only needs for a usershare would be:

  • To create a sub-folder which they themselves can write to remotely, or
  • To make data from a specific folder available anonymously, i.e. ‘for file-sharing’.

In that case, to keep the Homes feature activated, will reduce the number of usershares that actually need to be created (and which are not encrypted by default).

(Edit 03/26/2018, 01h30 : )

After tinkering with them for several days, I have a conclusion about Usershares:

They may make the task easier for non-experts, or more specifically, for non-Linux experts, to set up file-sharing. But they have two major drawbacks for power-users who are already adept at Linux.

  1. There is no way to ensure from the server, that encryption will take place. With statically-defined shares, I’m confident that I can do this.
  2. They’re incompatible with the concept of ‘Samba-mounts’, which are also referred to as ‘CIFS-mounts’, or ‘network-mounts’. Those will require that a major system of folders on the server, have read / write -access. And as I already mentioned, by default, Homes shares only have read-access, while Usershares will be scattered about in the user’s home-folder-tree. For example it would be simpler, just to set the Homes shares to ‘read only = no’, and then again, to achieve zero-setup-per-user.

 

(Update 03/27/2018 : )

I have a few more observations, about the subject of how secure or insecure these types of SMB-sessions are:

  • Even if encryption is enabled, This does not mean that an SMB-share should ever be exposed directly to the Internet, or the WAN.
  • SMB3-encryption offers AES-128 as its actual encryption-algorithm. However, it’s ultimately only as secure, as the password, since a symmetric key needs to be negotiated, and no form of Public-Key Infrastructure is used by default.
  • If there is no encryption, then the password-security defaults to some form of challenge-response negotiation. That methodology may be secure, or may not, depending on how it’s implemented. I know of challenge-response protocols that should be regarded as secure, and of others that should not. Just because the Linux community has strongly subscribed to the ‘NT1′ SMB-Protocol in the past, I’d guess it’s reasonably secure.
  • If data-encryption has been activated, either as part of ‘NT1′, or as part of the ‘SMB3′ protocols, then password-authentication does not take place separately. In those cases, the mere fact that the client is able to establish an encrypted session, is proof enough, that the client also knows the password. And in those cases, the password-security is also greater, than it would be entirely due to challenge-response authentication.

(Update 03/28/2018 : )

I’ve observed that if, I created a Usershare with the Access Control Lists (ACLs) set to give “Full Control” to a specific authenticated user, then, using the Dolphin GUI-based client from another machine, I can navigate to the share in question, and directly in the root folder of that share, my Dolphin client-program will have the options grayed-out, either to Paste a file, or to Create a New Object. However, if there is then a sub-folder of that share, I can right-click directly on the sub-folder, and the context-menu commands are available, to Paste, or to Create a New Object, which will all come into being, inside the folder I right-clicked on. When browsing my shares in this way, Dolphin shows their contents as a List View.

AFAICT, All this is really just a quirk in how Dolphin works under Debian / Stretch, and does not reflect what the per-share permissions are, that the Samba-server set. Whether those options are grayed out or not, further has no meaning, to indicate whether the server would allow me to write to the share. I.e., with the Access Control Lists set to Read-Only, the options will still become active in the GUI, to Paste a File, but If I attempt to do so, I’ll next get an ‘Access Denied’ message.

I guess I’ll just have to accept that this is the maximum degree, to which the Dolphin File-Browsing GUI will work, with Usershares.

Dirk

 

Print Friendly, PDF & Email

One thought on “File-Sharing under Linux, using Usershares – the Modernistic Way.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>