Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Why is sshd_config ChrootDirectory root ownership required
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
salam
Apprentice
Apprentice


Joined: 29 Sep 2005
Posts: 221

PostPosted: Thu Jul 15, 2021 10:56 am    Post subject: Why is sshd_config ChrootDirectory root ownership required Reply with quote

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
View user's profile Send private message
alamahant
Advocate
Advocate


Joined: 23 Mar 2019
Posts: 3872

PostPosted: Thu Jul 15, 2021 6:27 pm    Post subject: Reply with quote

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
View user's profile Send private message
salam
Apprentice
Apprentice


Joined: 29 Sep 2005
Posts: 221

PostPosted: Fri Jul 16, 2021 10:10 am    Post subject: Reply with quote

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
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3095

PostPosted: Fri Jul 16, 2021 9:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
salam
Apprentice
Apprentice


Joined: 29 Sep 2005
Posts: 221

PostPosted: Tue Jul 20, 2021 10:59 am    Post subject: Reply with quote

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
View user's profile Send private message
swanson
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2004
Posts: 147
Location: Edinburgh, Scotland

PostPosted: Sat Jul 31, 2021 12:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3095

PostPosted: Sat Jul 31, 2021 3:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
swanson
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2004
Posts: 147
Location: Edinburgh, Scotland

PostPosted: Sat Jul 31, 2021 4:05 pm    Post subject: Reply with quote

Because a chroot is not your home directory, it is a effectively a restricted root directory.
_________________
Alan.
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3095

PostPosted: Sat Jul 31, 2021 5:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21431

PostPosted: Sat Jul 31, 2021 5:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum