# Why is sshd_config ChrootDirectory root ownership required

## salam

According to manual:

```
...At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group....
```

I spent several hours googling for reason, but no result. What is the technical background behind this? All chroot escapes I found required either chrooted process

running as root or ptracing user process outside chroot. But nothing related to permissions of target dir.

Can you point me to some documented reason or even proof of concept?

----------

## alamahant

I dont think this applies to sftp.

If you use CrootDirectory inside an sftp stanza then the perms will be those of the specified directory.

But if you need to create a chroot dir for ssh users then you need to create that directory as root and populate it with

/dev{null,zero,tty,random} nodes

/bin/bash

and also some libs

https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/

Why does that displease you?

----------

## salam

This applies to sftp as well, which can be tested easily with internal-sftp.

```
sshd[20656]: fatal: bad ownership or modes for chroot directory "/home/test"
```

I am aware how to setup it using recommended config, lack of information is the problem.

And that information is in the form of answer to question "why from security perspective the chrooted dir cannot be user-owned?"

If we take sftp as example, user logs in, sshd spawns root process, chroots to user's homedir, then drops privileges, so we have user process in user-owned chroot. What is the risk here?

----------

## szatox

 *Quote:*   

> why from security perspective the chrooted dir cannot be user-owned?

 I have no idea and I found it equally frustrating.

It doesn't seem important, since the user doesn't have any way to _name_ the files outside of chroot anyway.

Accommodating both, sftp access to chroot and public key authentication required jumping through quite a few hoops. Like creating a train-sized path to user's home directory (sftp would drop him into /home/user/chroot/home/user/; authorized_keys was in /home/user/.ssh/, so he couldn't even update his key)

----------

## salam

Yes, creating a root owned directory in the middle is recommended way. But I so hate mess....

I think I'll give it a try with disabling that requirement. What can happen in worst possible situation? Chroot escape and access the filesystem as given user. So same thing as if chroot was not configured at all.

*one funny option is to chown home directory to root and setup additional ACL for user to be able to write there, but then ssh keys stop working because of ownership problem!

----------

## swanson

```
...At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group....
```

Because a user with write and execute permissions on a directory can delete and replace (but not read or modify depending on their permissions) any files or directories underneath it including root owned (except those made immutable).

----------

## szatox

Yes, you can modify your home. How is it a problem though?

It's YOUR home after all, not some random other user's, and chroot's purpose is to protect the system from you rather than the other way around. You can't even name, let alone touch, anything that is not inside your chroot.

----------

## swanson

Because a chroot is not your home directory, it is a effectively a restricted root directory.

----------

## szatox

swanson, I don't get it. Let's reiterate:

I want to restrict user's access to /home/user.

Sshd can chroot into a specified directory upon login if a condition matches and resolve some variables. It can match on user name or group membership and chroot into user's home. Clean and easy solution, looks great, so I go for it.

And it doesn't work because /home/user is owned by user because it is his home.

Why is it a problem that needs a solution?

Bonus points if said user is also restricted to internal-sftp and doesn't need or have ANY executable code inside his home, interal-sftp does not require or use it.

----------

## Hu

I haven't tested this, but I have an idea about the motivation for this rule.  Historically, a user could hard link to a file he did not own, subject to some rules that were not strict enough to ensure security.  A motivation for restricting the system call chroot is that, if it is freely usable, a user could do the following (assuming all directories are on the same partition):

```
$ cd /tmp

$ mkdir exploit exploit/etc

$ cd exploit

$ ln /bin/su bin/su

$ ln /etc/passwd etc/passwd

# Set up etc/shadow with a known password for root

$ chroot . /bin/su

# Give the password that was set above.
```

Since chroot is not legal for unprivileged users, this exploit does not work on modern systems.  However, sshd will call chroot from a privileged process on your behalf, so if you could prepare the exploit directory from outside, then ssh in to get chroot called on your behalf, you can run this.  (Some modern kernels restrict such hard links as a defense against this attack.  OpenSSH's safety mechanism predates that feature, and may guard against attacks that the feature cannot help against.)  I have no ready explanation for why this is a problem if the user never has any access outside the chroot.

----------

