Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Jun 2018 07:05:15 +0200
From:      Polytropon <freebsd@edvax.de>
To:        Philipp Vlassakakis <freebsd-en@lists.vlassakakis.de>
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: <D380FEAE-77CE-4927-A610-B45000C0811E@lists.vlassakakis.de>
References:  <D380FEAE-77CE-4927-A610-B45000C0811E@lists.vlassakakis.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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 "./<name>").
For scripts, being able to execute them (after setting +x)
is not even needed - "sh <name>" 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, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180628070515.3591314b.freebsd>