From owner-freebsd-questions@freebsd.org Thu Jun 28 05:05:26 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 219EC1012094 for ; Thu, 28 Jun 2018 05:05:26 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 910278986E for ; Thu, 28 Jun 2018 05:05:25 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.97.38]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.167]) with ESMTPA (Nemesis) id 0MLCD7-1fYgEU32fZ-000ILH; Thu, 28 Jun 2018 07:05:15 +0200 Date: Thu, 28 Jun 2018 07:05:15 +0200 From: Polytropon To: Philipp Vlassakakis Cc: freebsd-questions@freebsd.org Subject: Re: FreeBSD 11.1: chroot users / provide pre-built binaries Message-Id: <20180628070515.3591314b.freebsd@edvax.de> In-Reply-To: References: Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:khUMbM+y0uTw9h+XiAPPN6ow1CfZIC0/RBx2cw2r464Dcq7P7Cl cX0je3A4qwfC2N9a+88DzO2Sua8P5Y17sE6oEGW2vRf3mSxMxhYT+uLLuOnobPQrQdBG+G9 BDS/coU1Cl7sl40LHCB1HEDZWtBsa00H1Q5EvU5YvV78t/x4nFxIhOgkUF/ZQsRm4IRncnY x5iToDsonD41dF7NiHH5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:zIRp3AOLTnM=:HvbQgOlwlR0aUWMdPTiLoB Czy4+DJ6oQU3A8l06wjjYAalap4rvbw5j+nMSLRYalaGF7XV8OvSRX4Km0TIzEecPFTKkrhHg HT+RzmYmJbGnWsflbN/MJ04eppidXuAgNtwDLQ0LLsIa8d5xdbSXzghh+F+6054pirVNCqmdw b0p/ZN/oBYVYGDvKZuQ0yKWOleJbL5Sbz7nNhkZ+TvmFzOPQ52yrk1cbwlZmYkZ2b3h3dMxoT vQvQRKCNDMXvHuyIu1uTWmVBHpSaxsj8FJ/JL41oUw98lPdwB/ghp9gryqUbnpyEmF/DL4CHt 42JQh40ysEkaAMZVzy0d9Ig5eOP/KWvk9vI2D06RJVFPThZLI8JiisQf4u3oOgUYO8Vm1oKR+ PeXky5xE2k9a6dmcuq7lp4+4rNK21tdrpPkEQGYTSEjwkay3dwnUJS3f5DR5MEgMmJqBqO5rS XOFhmLs3DbGltrDZSS98oU2J0IIGHyoJ7ft/fvWG1F1Dux6mfW/4Y6CksIDoejFJBU+pjKfZE Fxazvc88FW9h3NceH9246+cxXCLKvXOaFw7oWBTmnshz0ZJ7wdo6ktFxD/7PluQ2wHSYamHyC LYwdkadbpelq2fpAO5aBgMFtuj6ENWXVArm+x4Sb5yWq5ELlNoYjQwsVDXp3E+mO5wMmH/bi8 iGWJa0raSHzlJ3Gu20W3QgckgcZbs9TpeBEWmgVCDapRPhRsn1AETkmpjc1fNGTh8HlTJA2NC r3cxq/BpnM9Nwq8x X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 05:05:26 -0000 On Mon, 25 Jun 2018 19:45:02 +0200, Philipp Vlassakakis wrote: > Scenario: I have a fileserver with several hundreds local users. > > Each user should be locked into his $HOME (so they can’t cd into > any other user-directory, /root etc.), but can login via SSH,SFTP > and upload files. This is commonly accomplished by setting the user directories permissions to rwx/---/---. When group and others don't have the x attribute (executable) on _directories_ they cannot be changed into. For /root, this should be standard. The typical permissions for new user directories are rwx/r-x/r-x which allows changing into other people's directories and reading them, which is what you want to prevent. But you're saying "fileserver" and "login via SSH". On a fileserver, you typically don't provide interactive logins. Is this intended? > Via ZFS exec,devices,setuid is set to „off", so they can't > execute any self-uploaded binaries, except binaries, which > are provided by me. (cp, mv, rm, rmdir, sh, touch, chgrp, > groups, pwd etc.). This can be done both with ZFS (easier due to datasets) or regular mountpoints (requires /home to be a separate partition that can get the -o noexec mount option). But sh (and whatever you have set as $SHELL for the user) is a problem. > The binaries are included via $PATH. Make sure the users cannot change $PATH. This is tricky as it is a variable that "advanced" users can add ~/bin or . to. They can then execute a previously uploaded binary without problems (even without the "advanced technique" of "./"). For scripts, being able to execute them (after setting +x) is not even needed - "sh " is suffient and doesn't require any execution permission. > 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. > Is there any simple way to lock users into their Home-Directory > without editing sshd_config every time? No _simple_ way I know of... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...