Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenSSH: Dev

chroot directory ownership

 

 

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded


des at des

Feb 21, 2012, 3:40 AM

Post #1 of 6 (2807 views)
Permalink
chroot directory ownership

Currently, sshd requires the chroot directory to be owned by root. This
makes it impossible to chroot users into their own home directory, which
would be convenient for sftp-only users. Is there a particular reason
why, in safely_chroot() in session.c,

if (st.st_uid != 0 || (st.st_mode & 022) != 0)
fatal("bad ownership or modes for chroot "
"directory %s\"%s\"",
cp == NULL ? "" : "component ", component);

can't be changed to

if ((st.st_uid != 0 && st.st_uid != uid) ||
(st.st_mode & 022) != 0)
fatal("bad ownership or modes for chroot "
"directory %s\"%s\"",
cp == NULL ? "" : "component ", component);

?

DES
--
Dag-Erling Smørgrav - des [at] des
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


ldv at altlinux

Feb 21, 2012, 4:22 AM

Post #2 of 6 (2739 views)
Permalink
Re: chroot directory ownership [In reply to]

On Tue, Feb 21, 2012 at 12:40:31PM +0100, Dag-Erling Smørgrav wrote:
> Currently, sshd requires the chroot directory to be owned by root. This
> makes it impossible to chroot users into their own home directory, which
> would be convenient for sftp-only users. Is there a particular reason
> why, in safely_chroot() in session.c,
>
> if (st.st_uid != 0 || (st.st_mode & 022) != 0)
> fatal("bad ownership or modes for chroot "
> "directory %s\"%s\"",
> cp == NULL ? "" : "component ", component);

Most likely, this was made to ensure that the chroot directory itself is
not writable and cannot be made writable by the user, to avoid various
kinds of attacks.


--
ldv


des at des

Feb 21, 2012, 5:13 AM

Post #3 of 6 (2746 views)
Permalink
Re: chroot directory ownership [In reply to]

"Dmitry V. Levin" <ldv [at] altlinux> writes:
> Most likely, this was made to ensure that the chroot directory itself is
> not writable and cannot be made writable by the user, to avoid various
> kinds of attacks.

Sure, but *which* attacks?

Currently, if I don't want sftp-only users to see eachother's home
directories, I have to have two levels of directories: /home/$USER owned
by root and /home/$USER/$USER owned by the user. Alternatively (note: I
haven't tested this) I can chmod o-rw /home so users can't ls /home but
can still access /home/$USER, but they'll be able to tell whether other
directories exist because they will get EPERM instead of ENOENT. Not a
big deal, perhaps, but wouldn't it be simpler if you could just chroot
users to their ~?

DES
--
Dag-Erling Smørgrav - des [at] des
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


keisial at gmail

Feb 21, 2012, 6:10 AM

Post #4 of 6 (2750 views)
Permalink
Re: chroot directory ownership [In reply to]

On 21/02/12 14:13, Dag-Erling Smørgrav wrote:
> "Dmitry V. Levin" <ldv [at] altlinux> writes:
>> Most likely, this was made to ensure that the chroot directory itself is
>> not writable and cannot be made writable by the user, to avoid various
>> kinds of attacks.
> Sure, but *which* attacks?
>
> Currently, if I don't want sftp-only users to see eachother's home
> directories, I have to have two levels of directories: /home/$USER owned
> by root and /home/$USER/$USER owned by the user. Alternatively (note: I
> haven't tested this) I can chmod o-rw /home so users can't ls /home but
> can still access /home/$USER, but they'll be able to tell whether other
> directories exist because they will get EPERM instead of ENOENT. Not a
> big deal, perhaps, but wouldn't it be simpler if you could just chroot
> users to their ~?
>
> DES
Just one example.
If the user is the owner of /, he could move away /etc and replace it with
its own one, providing a /etc/passwd under its control.

You may think a user-owned chroot is not a problem for your setup, and it
may not be, or there may be a way you don't yet known (or opened by a config
change). Having a root-owned / is *much* safer.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Roman.Fiedler at ait

Feb 21, 2012, 6:34 AM

Post #5 of 6 (2757 views)
Permalink
AW: chroot directory ownership [In reply to]

> DES
> Just one example.
> If the user is the owner of /, he could move away /etc and replace it with
> its own one, providing a /etc/passwd under its control.
>
> You may think a user-owned chroot is not a problem for your setup, and it
> may not be, or there may be a way you don't yet known (or opened by a
> config
> change). Having a root-owned / is *much* safer.

With sftp, most likely attack scenario might be local code execution, where user had only sftp access. With user-writeable chroot, minor programming errors might allow such a task, e.g.

* sftp or libc might load locale info or translations from untrusted files (changing normal print to format string vuln)
* Buffer overflows reading locale/translation file info, e.g. by placing a 4GB+something locale files
* A memory error, e.g. double free, in sftp - which would have be caught by libc -- might trigger loading of another shared library, e.g. the result in http://www.cvedetails.com/cve/CVE-2012-0031/

These additional attacks are not possible with non-writeable root.

Kind regards,
Roman
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


openssh-unix-dev at oh3mqu

Mar 13, 2012, 9:30 AM

Post #6 of 6 (2679 views)
Permalink
Re: chroot directory ownership [In reply to]

Angel Gonzalez wrote:
> Just one example.
> If the user is the owner of /, he could move away /etc and replace it
> with its own one, providing a /etc/passwd under its control.
>
> You may think a user-owned chroot is not a problem for your setup, and
> it may not be, or there may be a way you don't yet known (or opened by a
> config change). Having a root-owned / is *much* safer.

I think that most used configuration of this chrooting is for sftp-only
users.

With this kind of config it is not a problem if /user creates etc in his
home directory.

Match Group sftp-only
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
ChrootDirectory %h

At least documentation should have note, that this reasonable looking
configuration is not valid.

Or if devs think that this shouldn't be allowed by default. Maybe they can
add a configuration entry "TrustMeIKnowWhatIAmDoing yes" to make this
configuration possible.

(Currently I must use proftpd with sftp module, but I would
like to use opensshd so there is only one software to handle both, file
transfers and remote shells)

--
Ari Saastamoinen

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.