Re: Glitch in sys_chroot()

Kai Henningsen (kai@khms.westfalen.de)
16 Nov 1996 16:48:00 +0200


alan@lxorguk.ukuu.org.uk (Alan Cox) wrote on 15.11.96 in <m0vOTPq-0005KjC@lightning.swansea.linux.org.uk>:

> > That's because the bug is in chroot(8), not chroot(2). chroot(2) is
> > supposed to change only the root directory; Linux's behavior is
> > correct.
>
> Changing chroot(2) for security reasons to the same is a smart move however.

I don't think so. It's not compatible, and furthermore (see below), it's
also a very bad idea.

This is from the "Single Unix Specification" (EX == extension, UX ==
X/Open extension):

*********************

3.3.14 chroot()
chroot()

NAME
chroot change root directory (TO BE WITHDRAWN)

SYNOPSIS

EX#include <unistd.h>

int chroot(const char *path);

DESCRIPTION
The path argument points to a pathname naming a directory. The chroot()
function causes the named directory to become the root directory, that is
the starting point for path searches for pathnames beginning with /. The
process working directory is unaffected by chroot().

The process must have appropriate privileges to change the root
directory.

The dot-dot entry in the root directory is interpreted to mean the
root directory itself. Thus, dot-dot cannot be used to access files
outside the subtree rooted at the root directory.

RETURN VALUE
Upon successful completion, 0 is returned. Otherwise, -1 is returned and
errno is set to indicate the error. If -1 is returned, no change is made
in the root directory.

ERRORS
The chroot() function will fail if:

[EACCES] Search permission is denied for a component of
path.

[ELOOP] UXToo many symbolic links were encountered in resolving
path.

[ENAMETOOLONG]
The length of the path argument exceeds {PATH_MAX} or a pathname
component is longer than {NAME_MAX}.

[ENOENT] A component of path does not name an existing
directory or path is an empty string.

[ENOTDIR] A component of the path name is not a directory.

[EPERM] The effective user ID does not have appropriate
privileges.

The chroot() function may fail if:

UX[ENAMETOOLONG]
Pathname resolution of a symbolic link produced an intermediate
result whose length exceeds {PATH_MAX}.

APPLICATION USAGE
There is no portable use that an application could make of this interface.
It is therefore marked TO BE WITHDRAWN.

SEE ALSO
chdir(), <unistd.h>.

CHANGE HISTORY
First released in Issue 1.

Derived from Issue 1 of the SVID.

Issue 4
Changes are incorporated as follows:

The interface is marked TO BE WITHDRAWN, as there is no
portable use that an application could make of this interface.

The header <unistd.h> is added to the SYNOPSIS section.

The type of argument path is changed from char * to const
char *.

The APPLICATION USAGE section is added.

The DESCRIPTION section now refers to the process working
directory instead of the user s working directory.

Issue 4, Version 2
The ERRORS section is updated for X/OPEN UNIX conformance as follows:

It states that [ELOOP] will be returned if too many
symbolic links are encountered during pathname resolution.

A second [ENAMETOOLONG] condition is defined that may
report excessive length of an intermediate result of pathname resolution
of a symbolic link.

******************

As to the command, that one already is "withdrawn" and so has no useable
description:

******************

3.3.12 chroot
chroot

NAME
chroot - change root directory for a command (WITHDRAWN)

SYNOPSIS

EXchroot newroot command

APPLICATION USAGE
This utility has been withdrawn because there is no portable way to set up
an environment where it is useful and it is usually usable only by
applications with appropriate privileges.

CHANGE HISTORY
First released in Issue 2.

Issue 3
Functionally equivalent to the entry in Issue 2.

Issue 4
This page has been marked as withdrawn. The intermediate step of
publishing an issue with a TO BE WITHDRAWN marking has been bypassed
intentionally because of the non-portable aspects of this utility.

*******************

As for the security aspects, making chroot() do a chdir() will only serve
to create programmers that think that chroot() will do a chdir() on all
machines. This doesn't close security holes, it *opens* them.

MfG Kai