automating and securing share access for linux client

Currently reading
automating and securing share access for linux client

37
1
NAS
DSM 1621+
Operating system
  1. Linux
Mobile operating system
  1. Android
With no native file sharing feature in the Virtual Machine Manager, guest systems must rely on standard network file sharing to access files on the host storage device. For systems that would perform automated tasks without user login, on files in the shares of the network device, this demand creates a dilemma, because file sharing must be permissive enough to allow mounting by the guest system without a user supplying a password, but also must be restrictive enough to enforce adequate security.

For provisioning a Linux client for automatic mounting of shared volumes, it would seem that common solutions fall into one of three categories:
  1. Mounting an NFS share that is accessible without password, perhaps with the IP address of the client system serving as the only means of authentication.
  2. As above, but using a password stored on the client.
  3. Using a key-management authentication and authorization system, such as Kerberos.
It would seem that option (1) has the vulnerability of exposing files to any node on the network, at least any node that is able to set it's own IP address, which is extremely common.

Option (2) might be slightly more secure, but storing credentials, especially a string created by the user, and persisted in plain text, is cumbersome and vulnerable. (I believe that in this case the password would be accessible also to any regular user of the system, if not through reading the the fstab file, then by listing the table of active mounts.)

Option (3) solves most of the above problems, but incurs administrative overhead exceeding that feasible for most small deployments, at least in the case specifically of Kerberos, which DSM supports.

Are any better options overlooked, perhaps more secure than (2) but less difficult to manage than (3) for a small but secure deployment of an automated client system?
 
It would seem that option (1) has the vulnerability of exposing files to any node on the network, at least any node that is able to set it's own IP address, which is extremely common.
You can restricict the share to a single ip, a list of ip's or an ip-range if wanted, which will allow to apply a restriction on why system is able to mount the share. At least this is what nfs typicaly provides, though I am not 100% sure, if the Syno-UI allows to set these restrictions as well. Update: seems the ui does not allow a list of ips, but adds support for a hostname and wildcard fqdn.

Additionaly, the file level unix-permissions (uid:gid) still apply. You just need to make sure that the uid:gids from the VM allign with those from the Syno, or use a static uid:gid while mounting the share, . This will at least allow to apply access restrictions for subfolders/files inside the the remote share..
 
... which would lead to an ip collision. This would rather result in a denial of service for both devices, unless you disconnect the original machien from the network, wouldn't it? The connecting switch would constantly switch the ip between the mac adress of the two machines interfaces.. I'd be surprised if this would allow any stable hostile take over.
 
This would rather result in a denial of service for both devices

Not necessarily. Spoofing IP addresses is time-honored attack method. The only protection is not relying on addresses for authentication. I'm sure many sources on network security explain the issues in detail.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top