1

For platform hardware independence, a proposal to host a SFTP server within a containerized environment was being considered.

A container or pod would have the server running within it, with mounted host directories for file related operations.

I am not certain how secure this proposal could be, both from SSH and docker perspective. While I can see the merit in hosting a shared service or a webpage within a container, and modifying files within that container using SFTP, here though, the users of SFTP are expected to be the host users - not sure yet how it'll translate into the container - with mounted directories having write permissions, so that the sftp service inside the container can modify files outside on the host.

I was also concerned about the login credentials of the host users (auth_keys files) being present inside the docker container, though those are public keys, so should be OK everywhere maybe...

The host platform is a Linux platform with STIG guidelines conformance, and I am not sure whether there is something which would offend STIG guidelines with this implementation either. I didn't find anything explicit there...

Therefore I wanted to ask if there was anything in STIG guidelines for a RHEL type OS which would prevent this mechanism from being implemented, if so, then I'll research and learn and this becomes moot, if not, then is it at least something which can be considered alright from a security perspective?

Improve this question
6
  • sftp isn't secure in the first place
    – Software Engineer
    Commented Oct 1, 2020 at 8:19
  • 1
    @SoftwareEngineer Why is sftp not secure? Is there any major security issues with the ssh protocol?
    – vidarlo
    Commented Oct 1, 2020 at 8:28
  • There are issues with all protocols, but that's not the point. It's not the 'S' bit that's the problem here. It's the bit where you let anyone with a password upload unsanitised files onto your computers and download anything they find there. It's rarely necessary to let this happen, and even if you do want that there are other solutions that may be better.
    – Software Engineer
    Commented Oct 1, 2020 at 9:03
  • 1
    Well, the user base is controlled, access is through keys, minus the containers, their access to file system is restricted and the mounted file system for them to access has other provisions to increase security. I am just not sure what security loopholes will get introduced with host users being mimic'd inside container, with access control, and mounting host directories with write permissions.
    – user1173240
    Commented Oct 1, 2020 at 9:07
  • 1
    You should also set SFTP/SSH to a non-standard port (anything other than 22). If I understand vidario's concern correctly, the unfettered access is probably due to other permissions associated with a successful SSH/SFTP authentication, like port forwarding and filesystem access. You might look into revoking those, using a permission limited service account, and depending on the exact requirements, even implement MAC.
    – Saustin
    Commented Oct 1, 2020 at 12:45

1 Answer 1

Reset to default
3

It's important to note, when considering container security, that standard Linux containers are literally just Linux processes with some isolation techniques applied to them.

There are security considerations relating to them, but they're really similar to what you would have for any other process running on a host.

In this case, when you mount files inside a container, you're giving the contained process rights to operate on them, in the same way as you would if you gave an SFTP daemon running on the host access.

Key security concerns are likely to be :-

  • Ensuring the container image comes from a trusted source (e.g. you control the image building process)
  • Ensuring that the image is patched. Generally container images come with Linux base files to support the running daemon, so ensuring patching is maintained is important.
  • Hardening the container image. Important issues include making sure your container isn't running as the root user (many images default to this) and only installing packages that are neded for the operation of the daemon
  • Controlling what files can be mounted from the host. The Docker daemon runs as root, so if you let a user define what directories they can mount, it's possible fo them to mount sensitive directories inside the container.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .