Date: Thu, 28 Jun 2018 14:49:40 -0400 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: freebsd-questions@freebsd.org, o1e9@member.fsf.org Subject: Re: FreeBSD 11.1: chroot users / provide pre-built binaries Message-ID: <44a7reagqj.fsf@lowell-desk.lan> In-Reply-To: <6aec1872-509a-5807-23fe-cc22089d58eb@yandex.com> (Oleg Cherkasov's message of "Thu, 28 Jun 2018 17:48:05 %2B0200") References: <D380FEAE-77CE-4927-A610-B45000C0811E@lists.vlassakakis.de> <20180628070515.3591314b.freebsd@edvax.de> <6aec1872-509a-5807-23fe-cc22089d58eb@yandex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oleg Cherkasov <o1e9.cherkasov@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44a7reagqj.fsf>