openssh unix dev - Jul 2019 - Feature request: allow chrooted directory writable by others

Hello, I am trying to setup a file server using the SFTP protocol with OpenSSH.

I am in trouble because sshd refuses to chroot to a directory that is
writable by users other than the owner.  I guess that this is to
prevent someone else from creating a .ssh/authorized_keys file and
impersonate the user. But we have configured an alternative
AuthorizedKeysFile. I also understand that a chroot user needs a
layout for login (/bin/bash, ...) or for executing the external
sftp-server, and that nobody should be allowed to change it. But for
an SFTP server that only serves files, using the internal-sftp server,
that should not be a problema.

Note that this is extremely restrictive in practice. Even if one is
very careful and only allows specific users to write (with acls)
openssh refuses to chroot to that directory. And when one has to work
with a speficied directory layout, required for compatibility with
existing applications, it makes it very hard to implement a sftp file
server.

I would like to  contribute a patch with an option
StrictModesChrootDirectory . That option could be document with the
reasons when it should not be used.

Best regards.

On 15/7/19 7:54 pm, Ram?n Garc?a wrote:
> I am trying to setup a file server using the SFTP protocol with OpenSSH.
>
> I am in trouble because sshd refuses to chroot to a directory that is
> writable by users other than the owner.
I doubt that you need the root to be writeable.? Put your files inside a 
globally writeable sub-directory.? This allows you to have a dev, bin, 
lib, and whatever, within your chroot, without leaving yourself open 
someone tearing you a new one.

If somebody says, "but I need to write to root", your go-to answer is 
"no, you don't; and get off my lawn."

Also, look at rssh.

On 2019/07/15 12:24, Ram?n Garc?a wrote:
> Hello, I am trying to setup a file server using the SFTP protocol with
OpenSSH.
> 
> I am in trouble because sshd refuses to chroot to a directory that is
> writable by users other than the owner.  I guess that this is to
> prevent someone else from creating a .ssh/authorized_keys file and
> impersonate the user. But we have configured an alternative
> AuthorizedKeysFile. I also understand that a chroot user needs a
> layout for login (/bin/bash, ...) or for executing the external
> sftp-server, and that nobody should be allowed to change it. But for
> an SFTP server that only serves files, using the internal-sftp server,
> that should not be a problema.
> 
> Note that this is extremely restrictive in practice. Even if one is
> very careful and only allows specific users to write (with acls)
> openssh refuses to chroot to that directory. And when one has to work
> with a speficied directory layout, required for compatibility with
> existing applications, it makes it very hard to implement a sftp file
> server.
> 
> I would like to  contribute a patch with an option
> StrictModesChrootDirectory . That option could be document with the
> reasons when it should not be used.
A similar patch was added to RHEL in the past, the result was
CVE-2009-2904 / https://bugzilla.redhat.com/show_bug.cgi?id=522141

On Mon, Jul 15, 2019 at 6:44 AM David Newall <openssh at davidnewall.com>
wrote:
>
> On 15/7/19 7:54 pm, Ram?n Garc?a wrote:
> > I am trying to setup a file server using the SFTP protocol with
OpenSSH.
> >
> > I am in trouble because sshd refuses to chroot to a directory that is
> > writable by users other than the owner.
>
> I doubt that you need the root to be writeable.  Put your files inside a
> globally writeable sub-directory.  This allows you to have a dev, bin,
> lib, and whatever, within your chroot, without leaving yourself open
> someone tearing you a new one.
Being ale to write to root means being able to replace /etc/ and
/tmp/, and /proc, with non-root owned directories. It's very
dangerous.

Most of us accept being able to write to "/ome/username", where
"/home" is owned by root and prevents the deletion or relocation of
"/home/username", as sufficient. Or we accept a shared sftp workspace,
such as "/var/projectname"
> If somebody says, "but I need to write to root", your go-to
answer is
> "no, you don't; and get off my lawn."
>
> Also, look at rssh.
rssh is not being maintained, sadly. If someone wants hooks for that,
I publish some updated chroot cage building tools for it, which I
built up for an employer who used a public scp and sftp upload site
rather than the FTPS site I recommended for them, which have been much
easier to set up.

On 2019-07-15 at 12:24 +0200, Ram?n Garc?a wrote:
> I am in trouble because sshd refuses to chroot to a directory that is
> writable by users other than the owner.
[...]
>                                              And when one has to work
> with a speficied directory layout, required for compatibility with
> existing applications, it makes it very hard to implement a sftp file
> server.
Have you considered using a "bind mount", or "nullfs mount",
depending
upon the OS you're using?

If you have one directory layout for compatibility with one application,
you don't need to use the same layout for another application: you can
construct "views" to present the layout needed.

So you'd make a "proper" root directory, with sensible
permissions,
`/dev/` and `/etc/` already existing and protected, but then use a
remapping mount ("bind" on Linux, "nullfs" on FreeBSD, other
names
elsewhere) to make the tree _also_ available here.  You don't need to
let one app dictate layout and permissions to every other app.

Regards,
-Phil

> On 2019-07-15 at 12:24 +0200, Ram?n Garc?a wrote:
> > I am in trouble because sshd refuses to chroot to a directory that is
> > writable by users other than the owner.
> [...]
> >                                              And when one has to work
> > with a speficied directory layout, required for compatibility with
> > existing applications, it makes it very hard to implement a sftp file
> > server.
Simply put: tough. If you have to have non-root ownership and/or write
permission to the top of the chroot cage, then don't use SFTP. Use
ftps, supported by vsftpd, which has a different security model and
suports an enitely empty workspace fo FTP-like uploads or downloads.
For Linux and UNIX systems, the "vsftpd" daemon does this very well. A
genuine ftp or ftps server does not have some of the powerful features
of an an SFTP server, but can handle symlinks considerably better.

On Mon, Jul 15, 2019 at 12:24:30PM +0200, Ram?n Garc?a
wrote:
> Note that this is extremely restrictive in practice. Even if one is
> very careful and only allows specific users to write (with acls)
> openssh refuses to chroot to that directory. And when one has to work
> with a speficied directory layout, required for compatibility with
> existing applications, it makes it very hard to implement a sftp file
> server.
If you have very specific layout requirements, I wouldn't use OpenSSH.
At work we have SFTP servers implemented using Twisted Conch, which lets
us implement our own custom authentication/authorisation arrangements
and our own virtual file system layout.  This works well for us because
we're a Python shop, but I'm sure there are other possibilities too.

-- 
Colin Watson                                       [cjwatson at debian.org]

Thank you all of you for your wonderful explanations

I will try to have all writting to subdirectories.

On Thu, Jul 18, 2019 at 10:55 AM Colin Watson <cjwatson at debian.org>
wrote:
>
> On Mon, Jul 15, 2019 at 12:24:30PM +0200, Ram?n Garc?a wrote:
> > Note that this is extremely restrictive in practice. Even if one is
> > very careful and only allows specific users to write (with acls)
> > openssh refuses to chroot to that directory. And when one has to work
> > with a speficied directory layout, required for compatibility with
> > existing applications, it makes it very hard to implement a sftp file
> > server.
>
> If you have very specific layout requirements, I wouldn't use OpenSSH.
> At work we have SFTP servers implemented using Twisted Conch, which lets
> us implement our own custom authentication/authorisation arrangements
> and our own virtual file system layout.  This works well for us because
> we're a Python shop, but I'm sure there are other possibilities
too.
>
> --
> Colin Watson                                       [cjwatson at debian.org]
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev