Feature Request: ability to specify URL and password for the SMB Network share

[dosssman]

First and foremost, thanks again for putting together and publishing this tool. This has most of my use cases covered, beside maybe some specific usage scenario.

Let us consider that I have a dual-booting system with Windows / MacOS and Linux. On the Linux system, I have a LUKS encrypted partition with an ext4 FS that I would like to regularly access from the Windows system.

The physical drive is detected under windows as \\.\PhysicalDrive3, and the encrypted partition is detected as vdb1 by linsk.

As of now, after setting up linsk and running with linsk run -l dev:\\.\PhysicalDevice3 vdb1 ext4, it generates: a. arbitrary IPv6 URL to connect via SMB Network Share b. a username linsk, and c. a random password.

For regular mounting of said LUKS partition, it would be desirable to have a fixed a. URL and c. password, so that the mounting process could be automated with a Batch script, for example.

This could be address by adding support for two flags, for example:

linsk run -l dev:\\.\PhysicalDevice3 vdb1 ext4 --share-address "MyFixedAddress" --share-password "MyFixedPassword"

Moreover, regarding --smb-address, it seems that it is tied to the address of the TAP device used to establish a virtual network between the QEMU VM and the host system. Even if it is not possible to set a human readable name, it would still be enough if the user can specify a dummy but fixed IPv6 address. Also, not sure whether or not this is related to --share-listen.

Thanks a lot for your time.

[AlexSSD7]

Hi @dosssman.

Thanks for sharing this.

There is a critical issue arising from the format you proposed. It's never a good idea to specify any secrets in the command line as it can be viewed by any user via ps or Windows' tasklist.

But regardless of the approach, there are a lot of security concerns when it comes to using static credentials in general. It was done on purpose that Linsk credentials' lifetime is short. If we do otherwise, we risk a lot by introducing many attack vectors.

Affording the small inconvenience of having to reconnect to the network share every time you start Linsk gives you a lot better security. The only way I can see it being somewhat secure is to store the static credentials as an encrypted file. But this would mean that you will have to enter the password to unlock it every time you start Linsk, nullifying the potential UX gains. The other approach we have in line is to not encrypt anything but lock the files to 0400 permissions while assigning the credentials file ownership to root. This would ensure that the attacker would need to have root access to the computer in order to read the password. It can be considered more or less secure because the attacker having root access is often when it's indeed "too late". But implementing this would add a lot of complexity, and the UX gains are negligible given that we're talking about saving 5-10 seconds of time on every startup.

Thoughts?

[dosssman]

Thanks for the feedback.

There is a critical issue arising from the format you proposed. It's never a good idea to specify any secrets in the command line as it can be viewed by any user via ps or Windows' tasklist.

Indeed. This suggestion is more about giving the choice / flexibility to the user, if they deem it desirable. Even with the proposed flag to fix the share's password, the behavior of randomly generated password would be maintained by default, should the user not specify --share-password.

Furthermroe, while having a fixed password for the SMB share might be less secure, it should be mitigated enough by having the user set a strong enough password, which will at least make it harder for an attack approaching from the network perspective.

Assuming the attacker has access to ps or the windows tasklist, he could also access the randomly generated password through linsk terminal session (?) anyway.

In my use case, the data is only accessible after unlocking a LUKS partition anyway, so the even if the fixed password is known, the attacker still has to obtain the password to unlock the partition. Given a closed enough, the vulnerability of having a fixed password are relatively minor.

[istvandesign]

The user could configure a password or require admin rights to save a root/admin readable file only. Then from the file you can read the url and credentials. (the file would be encrypted either by the user defined key or it would be protected by admin rights)

[AlexSSD7]

@dosssman

Quite a bit of misconceptions.

Furthermroe, while having a fixed password for the SMB share might be less secure, it should be mitigated enough by having the user set a strong enough password, which will at least make it harder for an attack approaching from the network perspective.

Usually, none of any real attacks are happening through password brute-forcing and similar password-based attacks.

Assuming the attacker has access to ps or the windows tasklist, he could also access the randomly generated password through linsk terminal session (?) anyway.

I disagree with this. Accessing the terminal session would require making a screenshot, and doing so is the finest red flag for an anti-virus. I'm not really sure about the following, but so far, it looks that usually, somewhat decent anti-viruses are going to block this kind of activity and notify the user of it straight away. On the other hand, accessing tasklist is not really suspicious.

In my use case, the data is only accessible after unlocking a LUKS partition anyway, so the even if the fixed password is known, the attacker still has to obtain the password to unlock the partition.

Not really if Linsk is running. There is nothing that stops a malicious program from connecting to the SMB share provided the password and do whatever it "wants" with the data.

@istvandesign

The user could configure a password or require admin rights to save a root/admin readable file only. Then from the file you can read the url and credentials. (the file would be encrypted either by the user defined key or it would be protected by admin rights)

If you are talking about making Linsk read from a file like this, then yes, this is what I proposed as a viable alternative. But the thing is, I don't think that the difficulties associated with implementing and maintaining this feature is going to be worth it. In the end, we're talking about affording a 15-second inconvenience of having to reconnect to a share.

[AlexSSD7]

I'm sorry for advocating against it. It's just that the initial purpose for Linsk was to provide a secure minimalist solution for accessing Linux file systems on unsupported OSes. I hope it's okay.

[unusualevent]

what's cool is that the OS keychain is useful for it :) (as in, remembering LUKS passphrases for devices on login)

[p-h-a-i-l]

I think it would be a useful feature and I think providing a sensible way for script integration does even increase the security. Relying on stdin and stdout only forces the user to be more creative and apply hacks, which are usually also not very secure.

On a mac, this is my "solution":

#!/usr/bin/expect -f

set timeout 60
spawn sudo linsk run -l dev:/dev/disk0s6 vdb

# Wait for sudo Password prompt
expect {
    -re "^Password:" {
        stty -echo
        send_user "\r\rEnter the password required for sudo: "
        expect_user -re "(.*)\n"
        send $expect_out(1,string)
        send "\n"
        stty echo
    }
    timeout {
        puts "Failed to find sudo password prompt. Maybe not needed?"
    }
}

# wait for luks password prompt
expect {
    -re "Enter Password:" {
        stty -echo
        send_user "\r\rEnter the password required for disk encryption: "
        expect_user -re "(.*)\n"
        send $expect_out(1,string)
        send "\n"
        stty echo
    }
    timeout {
        puts "Failed to find luks password prompt."
    }
}

expect {
    -re {URL: afp://(\S+)} {
        set mounted_share_url $expect_out(1,string)
        exp_continue
    }
    -re {Username:\s*(\S+)} {
        set mounted_share_username $expect_out(1,string)
        exp_continue
    }
    -re {Password:\s*(\S+)} {
        set mounted_share_password $expect_out(1,string)
    }
    timeout {
        puts "Failed to find afp credentials."
    }
}

puts "Extracted full afp url: afp://$mounted_share_username:$mounted_share_password@$mounted_share_url"
exec open afp://$mounted_share_username:$mounted_share_password@$mounted_share_url

interact

It gets the job done for me, and it would also be trivial to just hardcode my sudo password and disk encryption password in the script when I am lazy. This script will fail as soon as the dialogs change, which will be annoying.

What is even gained by making such a secret of the password? Right now it is visible on stdout, and it will pass through my clip board. As soon as the drive is mounted, the files are accessible anyways by everyone on the system.

My proposal would be to use environment variables to set the network share username, network share password and luks password. As an alternative just files from which the values can be read.