FreeBSD 11.1: chroot users / provide pre-built binaries

[Philipp Vlassakakis]

Hi everyone,

just FYI and for documentation purposes.
Another “solution" would be to use scponly (https://www.freshports.org/shells/scponly/), but it’s unmaintained for a couple of years. 

Regards,
Philipp

> On 28. Jun 2018, at 20:49, Lowell Gilbert <freebsd-questions-local at be-well.ilk.org> wrote:
> 
> Oleg Cherkasov <o1e9.cherkasov at yandex.com <mailto:o1e9.cherkasov at yandex.com>> 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 freebsd.org <mailto:freebsd-questions at freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org <mailto:freebsd-questions-unsubscribe at freebsd.org>"