From owner-freebsd-bugs@FreeBSD.ORG Fri Mar 7 14:00:05 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D9181065678 for ; Fri, 7 Mar 2008 14:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4728FC23 for ; Fri, 7 Mar 2008 14:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m27E05ev009653 for ; Fri, 7 Mar 2008 14:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m27E04iG009652; Fri, 7 Mar 2008 14:00:04 GMT (envelope-from gnats) Date: Fri, 7 Mar 2008 14:00:04 GMT Message-Id: <200803071400.m27E04iG009652@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Jille Timmermans Cc: Subject: Re: kern/121073: [kernel] [patch] run chroot as an unprivileged user X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jille Timmermans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 14:00:05 -0000 The following reply was made to PR kern/121073; it has been noted by GNATS. From: Jille Timmermans To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/121073: [kernel] [patch] run chroot as an unprivileged user Date: Fri, 07 Mar 2008 14:32:49 +0100 Hello, This is the way I think about this; correct me when/where I'm wrong: - When an user chroot()'s himself, there is no possibility to change user, because setuid is disabled, and this is the only way to switch user. - This means no local exploits will be possible. - Something that is possible, is programs use eg /etc/passwd, and think it is reliable. It is the chroot()'ing user's job to make sure this is reliable (no empty passwords, weak passwords, etc) Example 'remote exploit': userx chroot()'s an ftpd, because root doesn't want to run one, and he wants to ftp. the ftpd checks the /etc/passwd in the chroot, and checks whether passwords match that file. So if userx added users, or 'changed' passwords in the /etc/passwd the ftpd will think that are his own passwords. This way a remote attacker can get unwanted access to the system. I think this is userx' responsibility, he should know what chroot()'ing for (side)effects has. - What if some setuid program does a chroot() ? (euid!=ruid) 1) userx runs a setuid-usery: usery might have coded an chroot() that chroots, and userx doesn't know that - this is userx' fault, he shouldn't run binaries owned by others 2) userx runs a setuid-usery binary: There is no way userx can 'insert' a chroot() (I assume), or modify the memory etc; otherwise even su is an enourmous security risk. Am I making mistakes ? Missing things ? -- Jille Timmermans