Is it possible to set up a remote login session where a specific user only has access to certain folders, and can only run one executable?

Question

I have a server where I'd like to grant a user the ability to log in remotely, but restrict the session in two specific ways:

• They can only access a certain set of folders on the computer, and for those folders they only have read access
• Aside from normal shell commands for navigating the filesystem, there is only one command they can execute

For illustration purposes, the folders I want them to access are:

/data/folderA
/data/folderB
/data/folderC

and the binary I want them to be able to execute is:

/usr/local/bin/SomeCommand

Note that the /data directory contains other files and folders that I don't want the user to be able to see at all.

Basically, I want the session to only display folderA, folderB, and folderC at the root of the visible filesystem. If there's a few other visible files or folders related only to setting this up that are visible, that's acceptable, but nothing else.

They also need to be able to use SomeCommand normally, but no other executable. Note that SomeCommand requires internet access, and has a large dependency tree.

There are two systems where I could set this up: an old mac running macOS 10.13.6 (my preference), or a headless Debian system.

What I've tried so far:

I tried configuring OpenSSH to have a specific user account be locked into a chroot jail. I don't think that's going to work, though, not only because I don't know how to give access to the specific folders in question (especially given that they have sibling files and folders I don't want to be visible, so I can't chroot into their parent directory), but also because that would prevent SomeCommand from being able to find any of its needed libraries, and as I mentioned it has a lot of dependencies.

Any other options?

Is there perhaps a specific specialized shell I can use that can be set up this way, or some way to configure bash to do this?

Answer 1

Chroot is an option, if you mount -o bind the necessary folders into the new root. This is a Linux feature (some BSDs have a near-equivalent such as "nullfs" but I don't think macOS does).

This is similar to how Linux containers work (though with additional "mount namespaces" and other fancy features), so you could in fact set up a dedicated container – e.g. a fresh Debian with debootstrap and systemd-nspawn – then bind-mount /data into it, and have the user SSH into the container, as a more secure alternative to ordinary chroot. The container will naturally have a minimal /usr/bin that has only basic commands.

You will not be able to limit the user to just /data – even just for their CLI shell to start up, they will invariably need some files from /lib (at minimum the ld-linux*.so "loader"); some of /usr/{bin,lib,share}; and at least bits and pieces of /etc.

So if those contain anything sensitive but world-readable (not that they ever should!), then you could use even more bind-mounts to craft the necessary contents of the "limited" /usr/bin (you can bind-mount individual files, not only directories) but it might be your best option to use a full container so that the user will only see the container's generic out-of-the-box /etc instead of your main one.

One additional way to limit commands, specifically, is to set the user's shell to rbash which only lets them run what's available in $PATH – and you can point the user's $PATH to e.g. "/usr/local/limitedbin" with symlinks to only the allowed commands.