Mailing List Archive

Blacklisting/whitelisting sftp-server commands
I'm running OpenSSH_7.4p1 (CentOS7) and have been asked to build a sort of
"drop box" to allow clients read-only access from a certain directory.

Right now, I've implemented this with the following lines in
/etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match User update_user
ChrootDirectory /opt/dropbox
ForceCommand internal-sftp -d / -R

This is mostly working; it's allowing read-only access and restricting the
connecting user to the /opt/dropbox directory. I am concerned about the
following note in the man page: 'For file transfer sessions using ''sftp'',
no additional configuration of the environment is necessary if the
in-process sftp server is used, *though sessions which use logging do
require **/dev/log inside the chroot directory'*

As I haven't created a /dev/log socket in the directory, I am concerned
that there is logging information I will wish I had.

Looking at the -p and -P options, I wonder if there isn't a more
fine-grained approach possible, to perhaps whitelist only the commands
necessary for two operations: to list the contents of the current directory
and retrieve the files. My attempts so far to restrict opendir, lstat,
read, readdir, realpath, etc. haven't been successful. For example,
restricting "opendir" gives an error that the client can't get the CWD and
the session fails.

Any pointers?

-Cheers,

Travis
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Blacklisting/whitelisting sftp-server commands [ In reply to ]
On Thu, Sep 2, 2021 at 7:10 PM Travis Hayes <travis.hayes@gmail.com> wrote:
>
> I'm running OpenSSH_7.4p1 (CentOS7) and have been asked to build a sort of
> "drop box" to allow clients read-only access from a certain directory.

If you can't do it gracefully with SFTP, for whatever reason, consider
sidestepping the issue and using FTPS with vsftpd. As much as I
appreciate OpenSSH and SSH in general, restricted directory access has
never been one of its most graceful uses. And vsftpd takes about 10
minutes to install and set up sanely.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Blacklisting/whitelisting sftp-server commands [ In reply to ]
On Thu, 2 Sep 2021, Travis Hayes wrote:

> I'm running OpenSSH_7.4p1 (CentOS7) and have been asked to build a sort of
> "drop box" to allow clients read-only access from a certain directory.
>
> Right now, I've implemented this with the following lines in
> /etc/ssh/sshd_config:
>
> Subsystem sftp internal-sftp
> Match User update_user
> ChrootDirectory /opt/dropbox
> ForceCommand internal-sftp -d / -R
>
> This is mostly working; it's allowing read-only access and restricting the
> connecting user to the /opt/dropbox directory. I am concerned about the
> following note in the man page: 'For file transfer sessions using ''sftp'',
> no additional configuration of the environment is necessary if the
> in-process sftp server is used, *though sessions which use logging do
> require **/dev/log inside the chroot directory'*
>
> As I haven't created a /dev/log socket in the directory, I am concerned
> that there is logging information I will wish I had.

There's very little logged at the default loglevel, but most operations
are logged at -lVERBOSE.

> Looking at the -p and -P options, I wonder if there isn't a more
> fine-grained approach possible, to perhaps whitelist only the commands
> necessary for two operations: to list the contents of the current directory
> and retrieve the files. My attempts so far to restrict opendir, lstat,
> read, readdir, realpath, etc. haven't been successful. For example,
> restricting "opendir" gives an error that the client can't get the CWD and
> the session fails.

Yes, most clients issue an FXP_OPENDIR to figure out their "home
directory" since the protocol has no notion of one other than the
current working directory the server starts at.

For listing and downloading files, you'll need to allow something like:
open,close,read,lstat,fstat,opendir,readdir,realpath,stat

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Blacklisting/whitelisting sftp-server commands [ In reply to ]
On 03.09.21 01:05, Travis Hayes wrote:
> I am concerned about the
> following note in the man page: 'For file transfer sessions using ''sftp'',
> no additional configuration of the environment is necessary if the
> in-process sftp server is used, *though sessions which use logging do
> require **/dev/log inside the chroot directory'*
>
> As I haven't created a /dev/log socket in the directory, I am concerned
> that there is logging information I will wish I had.

Note that providing a large number of chroots with /dev/log scales very
poorly, because you'll need to configure your syslogd(-variant) to
access and read every single one of them.

On our SFTP server - which happens to be CentOS 7 as well -, I provide
stub /etc/passwd and /etc/group (just so that directory listings will
not show bare UIDs/GIDs), an empty /dev , a /README text file for a
welcome(*), a writable subdir for the uploads, and told the sshd to
(among other things):

SyslogFacility AUTHPRIV
Subsystem sftp internal-sftp
Match group mandanten
ForceCommand internal-sftp -l INFO -u 0077
Banner /home/chroot/README
AuthorizedKeysCommand [...] (**)
AuthorizedKeysCommandUser [...]

- and nonetheless get to see all the open's and close's recorded in
/var/log/secure .

(*) Individual /READMEs get refreshed in regular intervals, by
appending the respective user's current disk quota status to the
global /home/chroot/README . I make a point of having a Banner
right from square one so that automated clients will not enter
production unless they've been taught to deal with the extra
noise.
(**) Using the AuthorizedKeysCommand system allows me to keep the
management of pubkeys a) in our hands and b) out of the chroots.
Both are our policy choices; YMMV.

Regards,
--
Jochen Bern
Systemingenieur

T +49 6151 9067-231
F +49 6151 9067-290
E jochen.bern@binect.de
W www.binect.de


Binect GmbH
Robert-Koch-Str. 9
64331 Weiterstadt

Geschäftspost.Einfach.Digital.
Wir sind nach ISO/IEC 27001:2013 und 9001:2015 zertifiziert.
BMWi fördert digitale Lösungen für KMU.

Geschäftsführung: Dr. Frank Wermeyer, Michael Imiolczyk
Unternehmenssitz: Weiterstadt
Register: Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID: DE 221 302 264