FreeBSD 11.1: chroot users / provide pre-built binaries

Philipp Vlassakakis freebsd-en at
Tue Oct 9 20:33:01 UTC 2018

Hi everyone,

just FYI and for documentation purposes.
Another “solution" would be to use scponly (, but it’s unmaintained for a couple of years. 


> On 28. Jun 2018, at 20:49, Lowell Gilbert <freebsd-questions-local at> wrote:
> Oleg Cherkasov <o1e9.cherkasov at <mailto:o1e9.cherkasov at>> writes:
>> On 28. juni 2018 07:05, Polytropon wrote:
>>> On Mon, 25 Jun 2018 19:45:02 +0200, Philipp Vlassakakis wrote:
>>>> On the one hand I want to save space, so that the binairies
>>>> don't have to be in every $HOME,
>>>> on the other hand the work is reduced if a binary needs to be
>>>> updated.
>>> If you want a set of "whitelisted binaries", i. e., a fixed
>>> and defined set of binaries a user can call interactively,
>>> you'll still be facing the problem mentioned above: The shell.
>>> If you allow interactive logins, it's more or less GAME OVER
>>> as the shell sadly has too much power. Sure, creating a
>>> directory like /secbin (secure binaries), making copies of
>>> the binaries you explicitely want to allow, and only have
>>> PATH=/secbin could be a starting point, but as mentioned
>>> above, this won't work.
>>> The easiest way to prevent execution of any (!) programs is
>>> to disallow interactive access. Tools like scp and sftp will
>>> still work, but ssh won't. Setting $SHELL to /sbin/nologin
>>> or /does/not/exist in /etc/passwd for those users will
>>> prevent the use of ssh (without completely deactivating it
>>> for the whole system), and still allow scp uploads.
>>> But changing $PATH isn't sufficient. If the user has access
>>> to /bin, /usr/bin or /usr/local/bin, he can manually call
>>> binaries from there (via full path). This is where chroot
>>> can help.
>> Bash has RESTRICTED SHELL mode with -r option or may be soft linked as
>> rbash to run in restricted mode.  Check man bash and search for
>> RESTRICTED SHELL for more details.
> Like other restricted shells, bash's restricted mode is very fragile.
> You should never trust that sort of configuration to keep you safe when
> an actively hostile attacker might gain access.
> _______________________________________________
> freebsd-questions at <mailto:freebsd-questions at> mailing list
> <>
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at <mailto:freebsd-questions-unsubscribe at>"

More information about the freebsd-questions mailing list