View previous topic :: View next topic |
Author |
Message |
salam Apprentice
Joined: 29 Sep 2005 Posts: 221
|
Posted: Thu Jul 15, 2021 10:56 am Post subject: Why is sshd_config ChrootDirectory root ownership required |
|
|
According to manual:
Code: | ...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? |
|
Back to top |
|
|
alamahant Advocate
Joined: 23 Mar 2019 Posts: 3872
|
Posted: Thu Jul 15, 2021 6:27 pm Post subject: |
|
|
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? _________________
|
|
Back to top |
|
|
salam Apprentice
Joined: 29 Sep 2005 Posts: 221
|
Posted: Fri Jul 16, 2021 10:10 am Post subject: |
|
|
This applies to sftp as well, which can be tested easily with internal-sftp.
Code: | 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? |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3095
|
Posted: Fri Jul 16, 2021 9:31 pm Post subject: |
|
|
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) |
|
Back to top |
|
|
salam Apprentice
Joined: 29 Sep 2005 Posts: 221
|
Posted: Tue Jul 20, 2021 10:59 am Post subject: |
|
|
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! |
|
Back to top |
|
|
swanson Tux's lil' helper
Joined: 04 Jun 2004 Posts: 147 Location: Edinburgh, Scotland
|
Posted: Sat Jul 31, 2021 12:15 pm Post subject: |
|
|
Code: | ...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). _________________ Alan. |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3095
|
Posted: Sat Jul 31, 2021 3:58 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
swanson Tux's lil' helper
Joined: 04 Jun 2004 Posts: 147 Location: Edinburgh, Scotland
|
Posted: Sat Jul 31, 2021 4:05 pm Post subject: |
|
|
Because a chroot is not your home directory, it is a effectively a restricted root directory. _________________ Alan. |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3095
|
Posted: Sat Jul 31, 2021 5:32 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21431
|
Posted: Sat Jul 31, 2021 5:50 pm Post subject: |
|
|
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): Code: | $ 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. |
|
Back to top |
|
|
|