From owner-freebsd-current Mon Dec 14 15:04:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27198 for freebsd-current-outgoing; Mon, 14 Dec 1998 15:04:14 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27193 for ; Mon, 14 Dec 1998 15:04:09 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id MAA18507; Tue, 15 Dec 1998 12:03:58 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.1/8.9.1) id MAA17703; Tue, 15 Dec 1998 12:03:57 +1300 (NZDT) Message-ID: <19981215120357.B11837@clear.co.nz> Date: Tue, 15 Dec 1998 12:03:57 +1300 From: Joe Abley To: freebsd-current@FreeBSD.ORG Cc: jabley@clear.co.nz Subject: modification to exec in the kernel? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, We want to allow people to upload scripts to provide cgi hosting for our web hosting product. However, we are nervous about allowing people to upload arbitrary binaries, even though they will be run chrooted. We would also like to provide telnet access - but again, we don't want people to hang around running their own binaries. A controlled set of binaries will be installed for users to play with instead. Telnet and ftp access is provided within a chrooted filesystem, and the web server will exec scripts with uid set to the user's uid. How about a kernel option which, when enabled, restricts the use of exec for users in a particular group? With this option set, "execve will always fail for a user in the restricted group if the binary to be run is owned by the user who is running it." This means that we don't have to worry about users uploading their own binaries any more - they won't be able to run them anyway. In fact, we bill them for the disk space they use, so the more statically-linked exploits they try to upload the better :) Here is a patch to sys/kern/kern_exec.c which, if the macro RESTRICT_EXEC_GROUP exists, restricts execve in the manner mentioned for the restricted gid RESTRICT_EXEC_GROUP. Whaddaya think? Joe [$Id: kern_exec.c,v 1.88 1998/10/28 13:36:58 dg Exp $] 256,257c256,257 < if ((attr.va_mode & VSUID && p->p_ucred->cr_uid != attr.va_uid || < attr.va_mode & VSGID && p->p_ucred->cr_gid != attr.va_gid) && --- > if ((attr.va_mode & VSUID && p->p_cred->cr_uid != attr.va_uid || > attr.va_mode & VSGID && p->p_cred->cr_gid != attr.va_gid) && 686a687,698 > > #ifdef RESTRICT_EXEC_GROUP > /* > * If the invoking user has gid RESTRICT_EXEC_GROUP, check ownership > * of the file and deny execution if owned by the invoker. > */ > if ((p->p_ucred->p_rgid == (gid_t) RESTRICT_EXEC_GROUP || \ > p->p_ucred->p_svgid == (gid_t) RESTRICT_EXEC_GROUP) && \ > (p->p_ucred->p_ruid == attr->va_uid || \ > p->p_ucred->p_psvuid == attr->va_uid)) \ > return(ENOEXEC); > #endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message