similar to: Another security advisory for a writable chroot daemon

There are two security advisories for people who run a writable rsync daemon. One affects only those with "use chroot = no" (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These

There are two security advisories for people who run a writable rsync daemon. One affects only those with "use chroot = no" (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These

SUMMARY There is a path-sanitizing bug that affects daemon mode in all recent rsync versions (including 2.6.2) but only if chroot is disabled. It does NOT affect the normal send/receive filenames that specify what files should be transferred (this is because these names happen to get sanitized twice, and thus the second call removes any lingering leading slash(es) that the first call left

On Fri, 2018-01-05 at 16:00 +1030, David Newall wrote: > On 05/01/18 02:44, Thomas G?ttler wrote: > > I set up a chroot sftp server [...] > > Is there a way to get both? > > > > - chroot > > > > - writable root > > The source code (sftpd.c) seems to require that the root directory > be > owned by root and not group or world writable, so I

On Fri, Jan 05, 2018 at 09:42:18PM +1030, David Newall wrote: > On 05/01/18 20:06, Jakub Jelen wrote: > > if the confined user has write access to the chroot directory, > > there are ways how to get out, gain privileges and or do other > > nasty things. > > I'm not inexperienced with UNIX and unix-like operating systems (30+ years), > and I can't think what

(this is the third try. In the previous mails the body was empty) Hi, I set up a chroot sftp server by following this guide: https://wiki.archlinux.org/index.php/SFTP_chroot Things work well, with one exception: The root directory is not writable. The above docs give a hint how to work around this. But this is just a work-around. In my context I need a writable (ch)root directory.

On Sun, 2018-01-07 at 18:41 +0000, halfdog wrote: > Hello list, > > I created a page to demonstrate, what would happen when chroot > root directory is writeable. In fact, code execution is possible > already, when only /etc and /bin are writable. I also tried to > escape the chroot jail, but that did not work for non-root users. > > As the 2009 CVE activities mention,

Am 07.01.2018 um 19:41 schrieb halfdog: > Hello list, > > I created a page to demonstrate, what would happen when chroot > root directory is writeable. In fact, code execution is possible > already, when only /etc and /bin are writable. I also tried to > escape the chroot jail, but that did not work for non-root users. > > As the 2009 CVE activities mention, that creating

--- src/build.ml | 43 ++++++++++++++++++++++++++----------------- src/chroot.ml | 12 +++++++----- src/dpkg.ml | 17 +++++++++++++++-- src/ext2.ml | 8 +++++++- 4 files changed, 55 insertions(+), 25 deletions(-) diff --git a/src/build.ml b/src/build.ml index 9225184..205701b 100644 --- a/src/build.ml +++ b/src/build.ml @@ -106,11 +106,7 @@ let rec build debug *) let files =

On Fri, 2018-01-05 at 21:42 +1030, David Newall wrote: > On 05/01/18 20:06, Jakub Jelen wrote: > > if the confined user has write access to the chroot directory, > > there are ways how to get out, gain privileges and or do other > > nasty things. > > I'm not inexperienced with UNIX and unix-like operating systems (30+ > years), and I can't think what these

Hi, I think that the wu-ftp style chroot /./ should be a configurable option. In our servers we have some home directories in /chroot-web/./username (where web users can upload their web sites in a chrooted environment) and all imap mail in /mail-disk/username. We are planning a dovecot migration from our modified version of uw-imap and we noticed that the chroot in /chroot-web/ can't be

Rely on currying, and avoid extra helper functions. No behaviour changes. --- daemon/inspect_fs_unix.ml | 20 ++++++++++---------- daemon/inspect_fs_windows.ml | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/daemon/inspect_fs_unix.ml b/daemon/inspect_fs_unix.ml index 59e26a05e..3ad119306 100644 --- a/daemon/inspect_fs_unix.ml +++ b/daemon/inspect_fs_unix.ml @@ -68,7

On Tue, Dec 01, 2015 at 04:58:11PM +0000, Richard W.M. Jones wrote: > On Tue, Dec 01, 2015 at 03:59:56PM +0100, Mateusz Guzik wrote: > > CHROOT_IN/OUT around commandvf are definitely problematic. chroot should be > > done in the child, which also removes the need to chroot out in the > > parent. > > The CHROOT_IN/OUT business does need to be rewritten. Every >

https://bugzilla.samba.org/show_bug.cgi?id=12817 Bug ID: 12817 Summary: [PATCH] Allow daemon itself to chroot Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

On Tuesday 01 December 2015 15:59:56 Mateusz Guzik wrote: > On Thu, Nov 19, 2015 at 05:38:25PM +0100, Pino Toscano wrote: > > When running commands in the mounted guest (using the "command" API, and > > APIs based on it), provide the /dev/null from the appliance as open fd > > for stdin. Commands usually assume stdin is open if they didn't close > > it

Hy there, My name is Alex Vladulescu, and i found this very interesting tool for backup files and folders over remote network servers. For the past four days i have been reading the FAQ on the site, google-ing the web for some answers on my local problem, but i am very stuck, nothing seems to answer my question so far. My issue consists on having a rsyncd.conf on a master server on which i

On Tue, Dec 01, 2015 at 06:29:01PM +0100, Mateusz Guzik wrote: > CHROOT_OUT is mere chroot ("."), which suggests that that cwd for > virt-builder is "/". This means anything using aforementioned construct > has to use absolute paths, otherwise it looks names up against the real > "/". For current code it would make sense to somewhow check if all >

On Thu, Nov 19, 2015 at 05:38:25PM +0100, Pino Toscano wrote: > When running commands in the mounted guest (using the "command" API, and > APIs based on it), provide the /dev/null from the appliance as open fd > for stdin. Commands usually assume stdin is open if they didn't close > it explicitly, so this should avoid crashes or misbehavings due to that. This does not

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

On Tue, Dec 01, 2015 at 04:16:57PM +0100, Pino Toscano wrote: > On Tuesday 01 December 2015 15:59:56 Mateusz Guzik wrote: > > I would argue that /dev has to be at least partially populated for anything > > that gets executed in the chroot. At the very least special nodes like null, > > zero and {u,}random are needed. > > We do not assume anything about guests, which