From owner-freebsd-rc@FreeBSD.ORG Mon Oct 18 11:07:05 2010 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61738106564A for ; Mon, 18 Oct 2010 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 43E688FC16 for ; Mon, 18 Oct 2010 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9IB75SS029429 for ; Mon, 18 Oct 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9IB74o2029427 for freebsd-rc@FreeBSD.org; Mon, 18 Oct 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Oct 2010 11:07:04 GMT Message-Id: <201010181107.o9IB74o2029427@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/151063 rc [rc.subr] Verify network link and packet flow before s o conf/150752 rc [rc.subr] [patch] be not needed to eval $_pidcmd on re o conf/150474 rc [patch] rc.d/accounting: Add ability to set location o o conf/149867 rc [PATCH] rc.d script to manage multiple FIBS (kern opti o conf/149831 rc [PATCH] add support to /etc/rc.d/jail for delegating Z o conf/148961 rc [PATCH] netstart and network_ipv6 contains references o conf/148656 rc rc.firewall(8): {oip} and {iip} variables in rc.firewa o conf/147685 rc [rc.d] [patch] new feature for /etc/rc.d/fsck o conf/147444 rc [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot o conf/146053 rc [patch] [request] shutdown of jails breaks inter-jail o conf/145445 rc [rc.d] error in /etc/rc.d/jail (bad logic) o conf/145440 rc [rc.d] [patch] add multiple fib support (setfib) in /e o conf/145399 rc [patch] rc.d scripts are unable to start/stop programs o conf/145344 rc [patch] Fix kitchen sink approach for rc.d scripts ins o conf/145009 rc [patch] rc.subr(8): rc.conf should allow mac label con o conf/144213 rc [rc.d] [patch] Disappearing zvols on reboot o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances o conf/143084 rc [jail] [patch]: fix rc.d/jail creating stray softlinks o conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141907 rc [rc.d] Bug if mtu (maybe others?) is set as first argu o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/141275 rc [request] dhclient(8) rc script should print something o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip o conf/138208 rc [rc.d] [patch] Making rc.firewall (workstation) IPv6 a o conf/137629 rc [rc.d] background_dhclient rc.conf option causing doub o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/137271 rc [rc.d] Cannot update /etc/host.conf when root filesyst o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/135338 rc [rc.d] pf startup order seems broken [regression] o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/127917 rc [patch] dumpon rejects on start with physmem>swap even o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped p bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122968 rc [rc.d] /etc/rc.d/addswap: md swapfile multiplication a o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 89 problems total. From owner-freebsd-rc@FreeBSD.ORG Tue Oct 19 00:39:44 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B56106566B; Tue, 19 Oct 2010 00:39:44 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9858FC12; Tue, 19 Oct 2010 00:39:44 +0000 (UTC) Received: from [208.206.78.30] (port=49128 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P80Ev-00023e-Kd; Mon, 18 Oct 2010 17:39:43 -0700 From: Devin Teske To: freebsd-rc@freebsd.org In-Reply-To: <1286996709.32724.60.camel@localhost.localdomain> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> Content-Type: text/plain Organization: Vicor, Inc Date: Mon, 18 Oct 2010 17:39:41 -0700 Message-Id: <1287448781.5713.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: eeda19339be77836aac052df51e20ca1 X-Scan-Host: postoffice.vicor.com Cc: Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 00:39:44 -0000 On Wed, 2010-10-13 at 12:05 -0700, Devin Teske wrote: > On Tue, 2010-10-12 at 16:13 -0700, Devin Teske wrote: > > Hey all, > > > > [...] > > > > Behold... sysrc(8) v2.0 > > > > #!/bin/sh > > [...] > > Version 2.1 is available here: http://druidbsd.sf.net/ Version 2.2 now. Same links. I added `-R dir' for specifying an alternate root (other than `/') directory (mostly for handling jails). > > Direct links: > http://druidbsd.sf.net/download/sysrc.gz (download gzipped) > http://druidbsd.sf.net/download/sysrc.txt (view as text) > > Here's the changes: > --- sysrc.txt 2010-10-13 19:02:08.000000000 +0000 +++ bin/sysrc 2010-10-18 13:30:54.000000000 +0000 @@ -2,8 +2,8 @@ # -*- tab-width: 4 -*- ;; Emacs # vi: set tabstop=4 :: Vi/ViM # -# Revision: 2.1 -# Last Modified: October 13th, 2010 +# Revision: 2.2 +# Last Modified: October 18th, 2010 ############################################################ COPYRIGHT # # (c)2010. Devin Teske. All Rights Reserved. @@ -30,6 +30,7 @@ # SUCH DAMAGE. # # AUTHOR DATE DESCRIPTION +# dteske 2010.10.18 Add `-R dir' for operating in different root-dir # dteske 2010.10.13 Allow `-f file' multiple times. # dteske 2010.10.12 Updates per freebsd-hackers thread. # dteske 2010.09.29 Initial version. @@ -54,6 +55,7 @@ # -i Ignore unknown variables. # -n Show only variable values, not their names. # -N Show only variable names, not their values. +# -R dir Operate within the root directory `dir' rather than `/'. # # ENVIRONMENT: # RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. @@ -88,8 +90,9 @@ # Options # DESCRIBE= -RC_CONFS= IGNORE_UNKNOWNS= +RC_CONFS= +ROOTDIR= SHOW_ALL= SHOW_EQUALS= SHOW_NAME=1 @@ -170,6 +173,8 @@ "Show only variable values, not their names." eprintf "$optfmt" "-N" \ "Show only variable names, not their values." + eprintf "$optfmt" "-R dir" \ + "Operate within the root directory \`dir' rather than \`/'." eprintf "\n" eprintf "ENVIRONMENT:\n" @@ -185,10 +190,10 @@ # # Unset all environment variables in the current scope. An optional list of # arguments can be passed, indicating which variables to avoid unsetting; the -# `--except' is required to enabled the exclusion-list as the remainder of +# `--except' is required to enable the exclusion-list as the remainder of # positional arguments. # -# Be careful not to call this in a shell that you still except to perform +# Be careful not to call this in a shell that you still expect to perform # $PATH expansion in, because this will blow $PATH away. This is best used # within a sub-shell block "(...)" or "$(...)" or "`...`". # @@ -267,16 +272,41 @@ . "$RC_DEFAULTS" # + # If the query is for `rc_conf_files' then store the value that + # we inherited from sourcing RC_DEFAULTS (above) so that we may + # conditionally restore this value after source_rc_confs in the + # event that RC_CONFS does not customize the value. + # + if [ "$1" = "rc_conf_files" ]; then + _rc_conf_files="$rc_conf_files" + fi + + # # If `-f file' was passed, set $rc_conf_files to an explicit # value, modifying the default behavior of source_rc_confs(). # [ "$RC_CONFS" ] && rc_conf_files="$RC_CONFS" + source_rc_confs + + # + # If the query was for `rc_conf_files' AND after calling + # source_rc_confs the value has not changed, then we should + # restore the value to the one inherited from RC_DEFAULTS + # before performing the final query (preventing us from + # returning RC_CONFS which may be relative to ROOTDIR). + # + if [ "$1" = "rc_conf_files" -a \ + "$RC_CONFS" != "" -a \ + "$rc_conf_files" = "$RC_CONFS" \ + ]; then + rc_conf_files="$_rc_conf_files" + unset _rc_conf_files + fi + unset RC_CONFS # no longer needed - source_rc_confs - # # This must be the last functional line for both the sub-shell, # and the function to preserve the return status from formats @@ -332,8 +362,9 @@ # Find which file matches assignment to the given variable name. # for file in $conf_files; do + [ -f "$file" -a -r "$file" ] || continue if grep -q "^[[:space:]]*$varname=" $file; then - echo $file + echo ${file#$ROOTDIR} return $SUCCESS fi done @@ -404,7 +435,7 @@ # local not_found= local file="$( sysrc_find "$varname" )" - if [ "$file" = "$RC_DEFAULTS" -o ! "$file" ]; then + if [ "$file" = "${RC_DEFAULTS#$ROOTDIR}" -o ! "$file" ]; then # # We either got a null response (not found) or the variable # was only found in the rc.conf(5) defaults. In either case, @@ -554,7 +585,7 @@ # # Process command-line options # -while getopts hf:aAdevinN flag; do +while getopts hf:aAdevinNR: flag; do case "$flag" in h) usage;; f) RC_CONFS="$RC_CONFS${RC_CONFS:+ }$OPTARG";; @@ -566,13 +597,14 @@ i) IGNORE_UNKNOWNS=1;; n) SHOW_NAME=;; N) SHOW_VALUE=;; + R) ROOTDIR="$OPTARG";; \?) usage;; esac done shift $(( $OPTIND - 1 )) # -# Process command-line options +# Process `-e', `-n', and `-N' command-line options # SEP=': ' [ "$SHOW_EQUALS" ] && SEP='="' @@ -583,13 +615,49 @@ SHOW_EQUALS= fi +# +# Process `-R dir' command-line option +# +if [ "$ROOTDIR" ]; then + # + # Sanity checks + # + [ -e "$ROOTDIR" ] || die "%s: %s: No such file or directory" \ + "$progname" "$ROOTDIR" + [ -d "$( eval realpath "$ROOTDIR" )" ] || die \ + "%s: %s: Not a directory" "$progname" "$ROOTDIR" + + # + # When ROOTDIR is set, we need to: + # + # a. Prefix RC_DEFAULTS with ROOTDIR + # + RC_DEFAULTS="$ROOTDIR$RC_DEFAULTS" + + # b. Override the use of rc_conf_files from RC_DEFAULTS + # by setting RC_CONFS + # + [ "$RC_CONFS" ] || RC_CONFS="$( sysrc_get rc_conf_files )" + + # c. Prefix RC_CONFS with ROOTDIR + # + r= + for file in $RC_CONFS; do + r="$r${r:+ }$ROOTDIR$file" + done + RC_CONFS="$r" +fi + +# +# Process `-a' or `-A' command-line options +# if [ "$SHOW_ALL" ]; then # # Get a list of variables that are currently set in the rc.conf(5) # files (included `/etc/defaults/rc.conf') by performing a call to # source_rc_confs() in a clean environment. # - ( + ( # Operate in a sub-shell to protect the parent environment # # Set which variables we want to preserve in the environment. # Append the pipe-character (|) to the list of internal field @@ -602,7 +670,7 @@ IFS="$IFS|" EXCEPT="IFS|EXCEPT|PATH|RC_DEFAULTS|OPTIND|DESCRIBE|SEP" EXCEPT="$EXCEPT|SHOW_ALL|SHOW_EQUALS|SHOW_NAME|SHOW_VALUE" - EXCEPT="$EXCEPT|SYSRC_VERBOSE|RC_CONFS" + EXCEPT="$EXCEPT|SYSRC_VERBOSE|RC_CONFS|ROOTDIR" # # Clean the environment (except for our required variables) @@ -634,7 +702,8 @@ # other than rc.conf(5) defaults. # [ "$SHOW_ALL" = "1" -a \ - "$( sysrc_find rc_conf_files )" = "$RC_DEFAULTS" \ + "$( sysrc_find rc_conf_files )" = \ + "${RC_DEFAULTS#$ROOTDIR}" \ ] \ && unset rc_conf_files fi @@ -691,8 +760,11 @@ if [ "$SYSRC_VERBOSE" ]; then file="$( sysrc_find "$NAME" )" - [ "$file" = "$RC_DEFAULTS" -o ! "$file" ] && \ + if [ "$file" = "${RC_DEFAULTS#$ROOTDIR}" \ + -o ! "$file" ]; then file="$( sysrc_get "rc_conf_files%%[$IFS]*" )" + file="${file#$ROOTDIR}" + fi echo -n "$file: " fi -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Tue Oct 19 17:50:35 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2CF510656B8; Tue, 19 Oct 2010 17:50:35 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id BA74E8FC2A; Tue, 19 Oct 2010 17:50:32 +0000 (UTC) Received: from [208.206.78.30] (port=51629 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P8GKT-0001gR-Md; Tue, 19 Oct 2010 10:50:31 -0700 From: Devin Teske To: freebsd-rc@freebsd.org In-Reply-To: <1287448781.5713.3.camel@localhost.localdomain> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> Content-Type: text/plain Organization: Vicor, Inc Date: Tue, 19 Oct 2010 10:50:29 -0700 Message-Id: <1287510629.25599.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 394e1fa7ab79658ee7da2df862502365 X-Scan-Host: postoffice.vicor.com Cc: Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:50:35 -0000 On Mon, 2010-10-18 at 17:39 -0700, Devin Teske wrote: > On Wed, 2010-10-13 at 12:05 -0700, Devin Teske wrote: > > On Tue, 2010-10-12 at 16:13 -0700, Devin Teske wrote: > > > Hey all, > > > > > > [...] > > > > > > Behold... sysrc(8) v2.0 > > > > > > #!/bin/sh > > > [...] > > > > Version 2.1 is available here: http://druidbsd.sf.net/ > > Version 2.2 now. > Same links. > > I added `-R dir' for specifying an alternate root (other than `/') > directory (mostly for handling jails). Version 2.3 now. Same links. I added `-j jail' for specifying a jail id or name to operate within (requires jls(8); overrides `-R dir'). > > > > > Direct links: > > http://druidbsd.sf.net/download/sysrc.gz (download gzipped) > > http://druidbsd.sf.net/download/sysrc.txt (view as text) > > > > Here's the changes: > > > --- sysrc.2_2 2010-10-18 17:38:51.000000000 -0700 +++ sysrc 2010-10-19 10:40:33.000000000 -0700 @@ -2,8 +2,8 @@ # -*- tab-width: 4 -*- ;; Emacs # vi: set tabstop=4 :: Vi/ViM # -# Revision: 2.2 -# Last Modified: October 18th, 2010 +# Revision: 2.3 +# Last Modified: October 19th, 2010 ############################################################ COPYRIGHT # # (c)2010. Devin Teske. All Rights Reserved. @@ -30,7 +30,8 @@ # SUCH DAMAGE. # # AUTHOR DATE DESCRIPTION -# dteske 2010.10.18 Add `-R dir' for operating in different root-dir +# dteske 2010.10.19 Add `-j jail' for operating within jails (see jls(8)). +# dteske 2010.10.18 Add `-R dir' for operating in different root-dir. # dteske 2010.10.13 Allow `-f file' multiple times. # dteske 2010.10.12 Updates per freebsd-hackers thread. # dteske 2010.09.29 Initial version. @@ -56,6 +57,8 @@ # -n Show only variable values, not their names. # -N Show only variable names, not their values. # -R dir Operate within the root directory `dir' rather than `/'. +# -j jail The jid or name of the jail to operate within (overrides +# `-R dir'; requires jls(8)). # # ENVIRONMENT: # RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. @@ -91,6 +94,7 @@ progname="${0##*/}" # DESCRIBE= IGNORE_UNKNOWNS= +JAIL= RC_CONFS= ROOTDIR= SHOW_ALL= @@ -175,6 +179,10 @@ usage() "Show only variable names, not their values." eprintf "$optfmt" "-R dir" \ "Operate within the root directory \`dir' rather than \`/'." + eprintf "$optfmt" "-j jail" \ + "The jid or name of the jail to operate within (overrides" + eprintf "$optfmt" "" \ + "\`-R dir'; requires jls(8))." eprintf "\n" eprintf "ENVIRONMENT:\n" @@ -456,6 +464,14 @@ sysrc_set() fi # + # If not found, append new value to last file and return. + # + if [ "$not_found" ]; then + echo "$varname=\"$new_value\"" >> "$file" + return $SUCCESS + fi + + # # Perform sanity checks. # if [ ! -w $file ]; then @@ -465,14 +481,6 @@ sysrc_set() fi # - # If not found, append new value to last file and return. - # - if [ "$not_found" ]; then - echo "$varname=\"$new_value\"" >> "$file" - return $SUCCESS - fi - - # # Operate on the matching file, replacing only the last occurrence. # local new_contents="`lrev $file 2> /dev/null | \ @@ -585,10 +593,12 @@ $LINE" # # Process command-line options # -while getopts hf:aAdevinNR: flag; do +while getopts hf:aAdevinNR:j: flag; do case "$flag" in h) usage;; - f) RC_CONFS="$RC_CONFS${RC_CONFS:+ }$OPTARG";; + f) [ "$OPTARG" ] || die \ + "%s: Missing or null argument to \`-f' flag" "$progname" + RC_CONFS="$RC_CONFS${RC_CONFS:+ }$OPTARG";; a) SHOW_ALL=1;; A) SHOW_ALL=2;; d) DESCRIBE=1;; @@ -597,7 +607,12 @@ while getopts hf:aAdevinNR: flag; do i) IGNORE_UNKNOWNS=1;; n) SHOW_NAME=;; N) SHOW_VALUE=;; - R) ROOTDIR="$OPTARG";; + R) [ "$OPTARG" ] || die \ + "%s: Missing or null argument to \`-R' flag" "$progname" + ROOTDIR="$OPTARG";; + j) [ "$OPTARG" ] || die \ + "%s: Missing or null argument to \`-j' flag" "$progname" + JAIL="$OPTARG";; \?) usage;; esac done @@ -616,6 +631,13 @@ if [ ! "$SHOW_VALUE" ]; then fi # +# Process `-j jail' command-line option +# +if [ "$JAIL" ]; then + ROOTDIR="$( jls -j "$JAIL" path )" || die +fi + +# # Process `-R dir' command-line option # if [ "$ROOTDIR" ]; then -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Tue Oct 19 20:20:18 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 389101065670; Tue, 19 Oct 2010 20:20:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id D3E558FC1C; Tue, 19 Oct 2010 20:20:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 31DD845C9F; Tue, 19 Oct 2010 21:53:03 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8CE6945C8A; Tue, 19 Oct 2010 21:52:55 +0200 (CEST) Date: Tue, 19 Oct 2010 21:52:25 +0200 From: Pawel Jakub Dawidek To: Devin Teske Message-ID: <20101019195225.GB2127@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <1287510629.25599.2.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Julian Elischer , freebsd-rc@freebsd.org Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 20:20:18 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > I added `-j jail' for specifying a jail id or name to operate within > (requires jls(8); overrides `-R dir'). [...] Note that operating on jail files from outside a jail is serious security problem. The files from within the jail can be symbolic links that point to files from outside a jail from your perspective. Even chroot(2) to jail's root is neither safe (running applications that can be modified by jail's root is obvious security hole) nor reliable (jail might not have all the commands). The only safe way is to jexec(8) into a jail, but it of course has the same relialability issue as chroot(8). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAky99vgACgkQForvXbEpPzQLFwCfUw7oFcgj8ShqFb9TEz7JbDBg tswAoOUJ8Nr5OXoEUns1J60ozmB/A4UZ =FEUR -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 02:13:00 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6F92106566B; Wed, 20 Oct 2010 02:13:00 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4B18FC0C; Wed, 20 Oct 2010 02:13:00 +0000 (UTC) Received: from [208.206.78.30] (port=53197 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P8OAb-0006tL-JU; Tue, 19 Oct 2010 19:12:59 -0700 From: Devin Teske To: Pawel Jakub Dawidek In-Reply-To: <20101019195225.GB2127@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> Content-Type: text/plain Organization: Vicor, Inc Date: Tue, 19 Oct 2010 19:12:49 -0700 Message-Id: <1287540769.25599.73.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 4875425e9cdb15c4c4b12e968f9562b9 X-Scan-Host: postoffice.vicor.com Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 02:13:00 -0000 On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: > On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > > I added `-j jail' for specifying a jail id or name to operate within > > (requires jls(8); overrides `-R dir'). > [...] > > Note that operating on jail files from outside a jail is serious > security problem. The files from within the jail can be symbolic links > that point to files from outside a jail from your perspective. Even > chroot(2) to jail's root is neither safe (running applications that can > be modified by jail's root is obvious security hole) nor reliable (jail > might not have all the commands). The only safe way is to jexec(8) into > a jail, but it of course has the same relialability issue as chroot(8). > I see the concern, and you're absolutely right. I did see the need to use either chroot(8) or jexec(8), but for exactly the same reasons you mention (handing execution off-to something that could have been modified by the jail's root-user), I ended up writing routines that just edited the files outside the jail. It appears that (due to the other aforementioned security problem, involving hand-crafted symbolic links with malicious-intent), the only proper solution would be: a. Copy ourselves into some temporary location within the jail b. Hand execution off to ourself using either jexec(8) or chroot(8) And in doing that, we'll be properly jailed so that no matter the attack vector, we'll be covered via the kernel's built-in protection. How does that sound? For example (note: die() is a custom shell function and it does what you'd expect it to): progname="${0##*/}" tmp="$ROOTDIR/tmp/$progname" case "$0" in */*) cp "$0" "$tmp" || die \ "%s: Unable to copy self to \`%s'" \ "$progname" "$tmp" ;; *) for dir in $PATH; do [ -f "$dir/$progname" -a -x "$dir/$progname" ] || continue cp "$dir/$progname" "$tmp" || die \ "%s: Unable to copy self to \`%s'" \ "$progname" "$tmp" break done [ -f "$tmp" -a -x "$tmp" ] || die \ "%s: Unable to copy self to \`%s'" \ "$progname" "$tmp" esac jexec $JAIL $tmp \ ${SYSRC_VERBOSE:+-v} \ ${RC_CONFS:+-f"$RC_CONFS"} \ $( [ "$SHOW_ALL" = "1" ] && echo -a ) \ $( [ "$SHOW_ALL" = "2" ] && echo -A ) \ ${DESCRIBE:+-d} \ ${SHOW_EQUALS:+-e} \ ${IGNORE_UNKNOWNS:+-i} \ ${SHOW_NAME:--n} \ ${SHOW_VALUE:--N} \ ${ROOTDIR:+-R"$ROOTDIR"} Or something like that. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 04:46:04 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A47201065693 for ; Wed, 20 Oct 2010 04:46:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-30.mx.aerioconnect.net [216.240.47.90]) by mx1.freebsd.org (Postfix) with ESMTP id 370298FC14 for ; Wed, 20 Oct 2010 04:46:03 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9K4P6mK015977; Tue, 19 Oct 2010 21:25:06 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id BFC072D601C; Tue, 19 Oct 2010 21:25:05 -0700 (PDT) Message-ID: <4CBE6F55.5040609@freebsd.org> Date: Tue, 19 Oct 2010 21:25:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Devin Teske References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> In-Reply-To: <1287540769.25599.73.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-rc@freebsd.org, Pawel Jakub Dawidek Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 04:46:04 -0000 On 10/19/10 7:12 PM, Devin Teske wrote: > On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: >> On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: >>> I added `-j jail' for specifying a jail id or name to operate within >>> (requires jls(8); overrides `-R dir'). >> [...] >> >> Note that operating on jail files from outside a jail is serious >> security problem. The files from within the jail can be symbolic links >> that point to files from outside a jail from your perspective. Even >> chroot(2) to jail's root is neither safe (running applications that can >> be modified by jail's root is obvious security hole) nor reliable (jail >> might not have all the commands). The only safe way is to jexec(8) into >> a jail, but it of course has the same relialability issue as chroot(8). >> > I see the concern, and you're absolutely right. > > I did see the need to use either chroot(8) or jexec(8), but for exactly > the same reasons you mention (handing execution off-to something that > could have been modified by the jail's root-user), I ended up writing > routines that just edited the files outside the jail. > > It appears that (due to the other aforementioned security problem, > involving hand-crafted symbolic links with malicious-intent), the only > proper solution would be: > > a. Copy ourselves into some temporary location within the jail > b. Hand execution off to ourself using either jexec(8) or chroot(8) > can you fire off a shell in the jail and somehow shove yourself down it's throat? I vaguely remember that one could feed a shell script into the shell somehow.. but I forget the details. > And in doing that, we'll be properly jailed so that no matter the attack > vector, we'll be covered via the kernel's built-in protection. > > How does that sound? > > For example (note: die() is a custom shell function and it does what > you'd expect it to): > > progname="${0##*/}" > tmp="$ROOTDIR/tmp/$progname" > case "$0" in > */*) cp "$0" "$tmp" || die \ > "%s: Unable to copy self to \`%s'" \ > "$progname" "$tmp" > ;; > *) for dir in $PATH; do > [ -f "$dir/$progname" -a -x "$dir/$progname" ] || continue > cp "$dir/$progname" "$tmp" || die \ > "%s: Unable to copy self to \`%s'" \ > "$progname" "$tmp" > break > done > [ -f "$tmp" -a -x "$tmp" ] || die \ > "%s: Unable to copy self to \`%s'" \ > "$progname" "$tmp" > esac > jexec $JAIL $tmp \ > ${SYSRC_VERBOSE:+-v} \ > ${RC_CONFS:+-f"$RC_CONFS"} \ > $( [ "$SHOW_ALL" = "1" ]&& echo -a ) \ > $( [ "$SHOW_ALL" = "2" ]&& echo -A ) \ > ${DESCRIBE:+-d} \ > ${SHOW_EQUALS:+-e} \ > ${IGNORE_UNKNOWNS:+-i} \ > ${SHOW_NAME:--n} \ > ${SHOW_VALUE:--N} \ > ${ROOTDIR:+-R"$ROOTDIR"} > > Or something like that. From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 10:01:23 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F825106564A; Wed, 20 Oct 2010 10:01:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 9418F8FC18; Wed, 20 Oct 2010 10:01:22 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0EF2B45CA0; Wed, 20 Oct 2010 12:01:21 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 11E1245C9C; Wed, 20 Oct 2010 12:01:15 +0200 (CEST) Date: Wed, 20 Oct 2010 12:00:42 +0200 From: Pawel Jakub Dawidek To: Devin Teske Message-ID: <20101020100042.GE2127@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O8XZ+2Hy8Kj8wLPZ" Content-Disposition: inline In-Reply-To: <1287540769.25599.73.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 10:01:23 -0000 --O8XZ+2Hy8Kj8wLPZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2010 at 07:12:49PM -0700, Devin Teske wrote: > On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: > > On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > > > I added `-j jail' for specifying a jail id or name to operate within > > > (requires jls(8); overrides `-R dir'). > > [...] > >=20 > > Note that operating on jail files from outside a jail is serious > > security problem. The files from within the jail can be symbolic links > > that point to files from outside a jail from your perspective. Even > > chroot(2) to jail's root is neither safe (running applications that can > > be modified by jail's root is obvious security hole) nor reliable (jail > > might not have all the commands). The only safe way is to jexec(8) into > > a jail, but it of course has the same relialability issue as chroot(8). > >=20 >=20 > I see the concern, and you're absolutely right. >=20 > I did see the need to use either chroot(8) or jexec(8), but for exactly > the same reasons you mention (handing execution off-to something that > could have been modified by the jail's root-user), I ended up writing > routines that just edited the files outside the jail. >=20 > It appears that (due to the other aforementioned security problem, > involving hand-crafted symbolic links with malicious-intent), the only > proper solution would be: >=20 > a. Copy ourselves into some temporary location within the jail > b. Hand execution off to ourself using either jexec(8) or chroot(8) >=20 > And in doing that, we'll be properly jailed so that no matter the attack > vector, we'll be covered via the kernel's built-in protection. >=20 > How does that sound? Well, first of all you need to verify that $ROOTDIR/tmp/ is not a symbolic link (you can use realpath(1) for that). Then when you copy a file to $ROOTDIR/tmp/ you must be sure there is no symbolic link under the same name, as cp(1) will follow symblic link and you can end up overwriting eg. /etc/spwd.db with /bin/ls. I think it will be easier to just create random directory in $ROOTDIR/tmp/. This all must be done of course when jail is turned off. Anoher issue to consider is that you have to copy statically linked utilities - dynamically linked programs will use libraries from within a jail, which might not be there and might not be trusted. Also for this reason I'd forget about chroot(8) - even if you remember about libraries, there might still be malicious configuration files, etc. so jexec(8) is the only option. I, for one, use read-only root file systems for jails, maybe it would be good to check for that if you want to copy stuff over (/tmp/ is still writable). Please note, that all this is very risky still. I don't know if warned you about all possible problems. I'm also not a fun of copying stuff over into jails - this isn't pretty and also it is a problem to clean up (think about system crash in the middle of your operation). Maybe it will be wiser to just limit your script to operate within fully-populated jails, so that you can always call 'jexec sysrc'? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --O8XZ+2Hy8Kj8wLPZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEUEARECAAYFAky+vcoACgkQForvXbEpPzS5IwCY+e1kHMg5jz5S4xi30T7fI8Qx +ACdEaFG38wMFUjA7jnlyzSOOVMYTec= =LwKF -----END PGP SIGNATURE----- --O8XZ+2Hy8Kj8wLPZ-- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 16:53:52 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 383CE106566C; Wed, 20 Oct 2010 16:53:52 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE928FC1B; Wed, 20 Oct 2010 16:53:51 +0000 (UTC) Received: from [208.206.78.30] (port=55329 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P8bvB-0005Sa-2o; Wed, 20 Oct 2010 09:53:51 -0700 From: Devin Teske To: Julian Elischer In-Reply-To: <4CBE6F55.5040609@freebsd.org> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <4CBE6F55.5040609@freebsd.org> Content-Type: text/plain Organization: Vicor, Inc Date: Wed, 20 Oct 2010 09:53:48 -0700 Message-Id: <1287593628.19873.41.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: e8093ea28847b015b6a579b3a148cac8 X-Scan-Host: postoffice.vicor.com Cc: Pawel Jakub Dawidek , freebsd-rc@freebsd.org Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:53:52 -0000 On Tue, 2010-10-19 at 21:25 -0700, Julian Elischer wrote: > On 10/19/10 7:12 PM, Devin Teske wrote: > > On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: > >> On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > >>> I added `-j jail' for specifying a jail id or name to operate within > >>> (requires jls(8); overrides `-R dir'). > >> [...] > >> > >> Note that operating on jail files from outside a jail is serious > >> security problem. The files from within the jail can be symbolic links > >> that point to files from outside a jail from your perspective. Even > >> chroot(2) to jail's root is neither safe (running applications that can > >> be modified by jail's root is obvious security hole) nor reliable (jail > >> might not have all the commands). The only safe way is to jexec(8) into > >> a jail, but it of course has the same relialability issue as chroot(8). > >> > > I see the concern, and you're absolutely right. > > > > I did see the need to use either chroot(8) or jexec(8), but for exactly > > the same reasons you mention (handing execution off-to something that > > could have been modified by the jail's root-user), I ended up writing > > routines that just edited the files outside the jail. > > > > It appears that (due to the other aforementioned security problem, > > involving hand-crafted symbolic links with malicious-intent), the only > > proper solution would be: > > > > a. Copy ourselves into some temporary location within the jail > > b. Hand execution off to ourself using either jexec(8) or chroot(8) > > > can you fire off a shell in the jail and somehow shove yourself down > it's throat? > I vaguely remember that one could feed a shell script into the shell > somehow.. > but I forget the details. You bet. $ echo tail -2 /usr/include/osreldate.h | sudo chroot / /bin/sh #define __FreeBSD_version 801000 #endif $ echo tail -2 /usr/include/osreldate.h | sudo chroot /usr/jail/foomaster /bin/sh #define __FreeBSD_version 492101 #endif A more complete (yet simplified) example of a shell-script shoving itself into a chroot'ed shell -- complete with custom-set of positional parameters: ================================= BEGIN FILE: foo.sh #!/bin/sh jailed="$( sysctl -n security.jail.jailed )" echo "jailed: $jailed" echo -n "args: " for arg in "$@"; do echo -n "'$arg' " done echo [ $jailed -eq 1 ] && exit ( echo 'set -- "a b" "c d" "e f"' cat $0 ) | sudo jexec 8 /bin/sh ================================= END FILE When executed: $ uname -spr FreeBSD 8.1-RELEASE-p1 amd64 $ jls jid path 8 /usr/jail/foomaster 9 /usr/jail/foomaster.deluxe $ ./foo.sh "1 2" "3 4" "5 6" jailed: 0 args: '1 2' '3 4' '5 6' jailed: 1 args: 'a b' 'c d' 'e f' This is of-course a simplified example. A productionized version should take into consideration that PATH expansion may have been performed. This is trivial to "undo" as it were: myscript="$0" if [ ! -f "$0" ]; then # NOTE: `-x' should not be used because we could have been # invoked as `sh script' which allows execution of non- # executable shell-scripts # Perform reverse-PATH expansion for dir in $PATH; do # NOTE: If PATH-expansion was performed, the file # must now be executable (where earlier it could # have been non-executable if executed via sh in an # interactive shell) [ -x "$dir/$0" -a -f "$dir/$0" ] || continue # If we hit this point, we found a match myscript="$dir/$0" break done fi # At this point, $myscript should be a valid path to our own script # regardless of whether we were invoked by any of the following: # # sh ./myscript : Relative path (executable-bit optional) # sh myscript : Relative path (executable-bit optional) # sh /path/to/myscript : Absolute path (executable-bit optional) # env sh myscript : Relative path (executable-bit optional) # ./myscript : Relative path # /path/to/myscript : Absolute path # myscript : $PATH expansion performed However, this method is not without pitfalls: 1. Let's say that the script being executed is /usr/local/bin/myscript 2. Let's say that this script was invoked using $PATH expansion ($0 == 'myscript') 3. Let's say that the CWD is ~root 4. Let's say that `./myscript' exists 5. The above code will incorrectly think that we (/usr/local/bin/myscript) are ~root/myscript Unfortunately, there seems little way around this as even the following code fails in interesting ways: myscript="$0" case "$myscript" in */*) : Do nothing (already an absolute or relative path) ;; *) # $0 doesn't contain any slashes -- we were invoked in # one of two ways: # # 1. via $PATH expansion in the interactive shell # 2. via sh(1) and $0 truly is in the CWD # # NOTE: It is not possible to detect when we were invoked # via exec(3) versus sh(1) versus sh(1)-via-env(1) so # testing for #2 above is impossible. for dir in $PATH; do [ -x "$dir/$0" -a -f "$dir/$0" ] || continue myscript="$dir/$0" break done esac The comments in the above code-block explain why it won't work. In the case of: sh myscript $0 will equal "myscript" but, when reverse-PATH expansion is performed, we may end up finding something with the same name and then end up executing something perhaps entirely different. It seems clear that the only safe way to pass off execution to onself is to hard-code the path to yourself. For example: myscript=/usr/local/bin/foo ( echo 'set -- "a b" "c d" "e f"' cat $myscript ) | sudo jexec 8 /bin/sh Can anyone think of anything better? -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 17:11:46 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27F8106564A; Wed, 20 Oct 2010 17:11:46 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 676608FC14; Wed, 20 Oct 2010 17:11:46 +0000 (UTC) Received: from [208.206.78.30] (port=55393 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P8cCV-0005fJ-Tn; Wed, 20 Oct 2010 10:11:46 -0700 From: Devin Teske To: Pawel Jakub Dawidek In-Reply-To: <20101020100042.GE2127@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <20101020100042.GE2127@garage.freebsd.pl> Content-Type: text/plain Organization: Vicor, Inc Date: Wed, 20 Oct 2010 10:11:43 -0700 Message-Id: <1287594703.19873.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: ca33578e19835ff50fa4a7f3991757ed X-Scan-Host: postoffice.vicor.com Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:11:46 -0000 On Wed, 2010-10-20 at 12:00 +0200, Pawel Jakub Dawidek wrote: > On Tue, Oct 19, 2010 at 07:12:49PM -0700, Devin Teske wrote: > > On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: > > > On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > > > > I added `-j jail' for specifying a jail id or name to operate within > > > > (requires jls(8); overrides `-R dir'). > > > [...] > > > > > > Note that operating on jail files from outside a jail is serious > > > security problem. The files from within the jail can be symbolic links > > > that point to files from outside a jail from your perspective. Even > > > chroot(2) to jail's root is neither safe (running applications that can > > > be modified by jail's root is obvious security hole) nor reliable (jail > > > might not have all the commands). The only safe way is to jexec(8) into > > > a jail, but it of course has the same relialability issue as chroot(8). > > > > > > > I see the concern, and you're absolutely right. > > > > I did see the need to use either chroot(8) or jexec(8), but for exactly > > the same reasons you mention (handing execution off-to something that > > could have been modified by the jail's root-user), I ended up writing > > routines that just edited the files outside the jail. > > > > It appears that (due to the other aforementioned security problem, > > involving hand-crafted symbolic links with malicious-intent), the only > > proper solution would be: > > > > a. Copy ourselves into some temporary location within the jail > > b. Hand execution off to ourself using either jexec(8) or chroot(8) > > > > And in doing that, we'll be properly jailed so that no matter the attack > > vector, we'll be covered via the kernel's built-in protection. > > > > How does that sound? > > Well, first of all you need to verify that $ROOTDIR/tmp/ is not a > symbolic link (you can use realpath(1) for that). Agreed. I think I'm going to abandon that approach. It seems much cleaner to just pipe input into a jailed sh(1) process. > Then when you copy a > file to $ROOTDIR/tmp/ you must be sure there is no symbolic link under > the same name, as cp(1) will follow symblic link and you can end up > overwriting eg. /etc/spwd.db with /bin/ls. I think it will be easier to > just create random directory in $ROOTDIR/tmp/. This all must be done of > course when jail is turned off. I don't follow why the jail has be off. > Anoher issue to consider is that you > have to copy statically linked utilities - dynamically linked programs > will use libraries from within a jail, which might not be there and > might not be trusted. Do we really care about "trust" in the chroot(8) or jexec(8) (chroot(2)) context? Yes, you're right that if my script calls cp(1) within the jail and the root-user of the jail has poisoned it (perhaps replacing it with a shell script that does an "rm -Rf /*"), nothing will happen to the master-host -- only the jail itself will be destroyed (because the sh(1) process executing my script is jailed into the new root). And yes, similarly, the root-user of a jail can poison the shared libraries too, but again in the context of chroot/jexec the master host is protected. > Also for this reason I'd forget about chroot(8) - > even if you remember about libraries, there might still be malicious > configuration files, etc. so jexec(8) is the only option. I fail to see the difference between chroot(8) and jexec(8). Both rely on chroot(2). > I, for one, > use read-only root file systems for jails, maybe it would be good to > check for that if you want to copy stuff over (/tmp/ is still writable). Abandoning the idea that I have to write some file into the jail's filesystem heirarchy. Much more efficient to fire up an sh(1) process via chroot(8) or jexec(8) and then pipe standard input to it. > > Please note, that all this is very risky still. I don't know if warned > you about all possible problems. I'm also not a fun of copying stuff > over into jails - this isn't pretty and also it is a problem to clean up > (think about system crash in the middle of your operation). Yep. Abandoning the copy-in method. > Maybe it > will be wiser to just limit your script to operate within > fully-populated jails, so that you can always call 'jexec sysrc'? While that remains an option (and indeed a very valid approach since a "service jail" -- that is, a light-weight jail for running single daemons etc. in -- is unlikely to have a complementary set of rc.conf(5) files). Though I believe it to still be worth the effort to find a safe-way of reaching into the jail to perform the action because it's nice for developers to be able to depend on the script to get the job done regardless of whether (a) the jail has the script, (b) the jail has an untainted copy of the script (though admittedly the latter depends on untainted dependencies such as sh(1), grep(1), cp(1), etc.). But alas, if a safe-way can't be found, then assuredly the `-R dir' and `-j jail' options should be removed and the recommendation would be that they just copy the script into the jail. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 19:48:07 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FEBC10656A4; Wed, 20 Oct 2010 19:48:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id D25CA8FC1D; Wed, 20 Oct 2010 19:47:59 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4C68F45C9F; Wed, 20 Oct 2010 21:47:57 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8FBE045C8A; Wed, 20 Oct 2010 21:47:51 +0200 (CEST) Date: Wed, 20 Oct 2010 21:47:20 +0200 From: Pawel Jakub Dawidek To: Devin Teske Message-ID: <20101020194720.GB1755@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <20101020100042.GE2127@garage.freebsd.pl> <1287594703.19873.58.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: <1287594703.19873.58.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:48:07 -0000 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2010 at 10:11:43AM -0700, Devin Teske wrote: > > Then when you copy a > > file to $ROOTDIR/tmp/ you must be sure there is no symbolic link under > > the same name, as cp(1) will follow symblic link and you can end up > > overwriting eg. /etc/spwd.db with /bin/ls. I think it will be easier to > > just create random directory in $ROOTDIR/tmp/. This all must be done of > > course when jail is turned off. >=20 > I don't follow why the jail has be off. Because jailed root can mess with those files during your work (which is bad in chroot(8) case). > And yes, similarly, the root-user of a jail can poison the shared > libraries too, but again in the context of chroot/jexec the master host > is protected. >=20 >=20 > > Also for this reason I'd forget about chroot(8) - > > even if you remember about libraries, there might still be malicious > > configuration files, etc. so jexec(8) is the only option. >=20 > I fail to see the difference between chroot(8) and jexec(8). Both rely > on chroot(2). So why do you think we have jail and not only chroot? File system namespace is not everything. when you chroot, a malicious command has still access to all the other namespaces - non-jailed processes being one. It can then use ptrace to attach to non-jailed process and run with its privileges and restrictions, ie. outside chroot. Being able to even signal non-jailed processes alone is not good either. There are plenty of ways to escape from a chroot when you are root. chroot might be quite ok when you are running as regular user, but you still have access to various namespaces even if read-only. There also might be uid collision - non-jailed uid=3D1000 user might not be the same as jailed uid=3D1000 user, but when running in chroot with this uid you can use non-jailed uid=3D1000 process to escape. chroot wasn't really designed for what it is used and for what you are trying to use it. > > Maybe it > > will be wiser to just limit your script to operate within > > fully-populated jails, so that you can always call 'jexec sysrc'? >=20 > While that remains an option (and indeed a very valid approach since a > "service jail" -- that is, a light-weight jail for running single > daemons etc. in -- is unlikely to have a complementary set of rc.conf(5) > files). >=20 > Though I believe it to still be worth the effort to find a safe-way of > reaching into the jail to perform the action because it's nice for > developers to be able to depend on the script to get the job done > regardless of whether (a) the jail has the script, (b) the jail has an > untainted copy of the script (though admittedly the latter depends on > untainted dependencies such as sh(1), grep(1), cp(1), etc.). >=20 > But alas, if a safe-way can't be found, then assuredly the `-R dir' and > `-j jail' options should be removed and the recommendation would be that > they just copy the script into the jail. The -R option is still useful in the same way DESTDIR is useful for installworld/installkernel and -D option for mergemaster(8). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CdrF4e02JqNVZeln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAky/R0gACgkQForvXbEpPzRVyACgwudKSUCCOVZfvwZxtB9QMgYa VKEAoIbc5enQcvHpiPz+elPb3Xg/Hoap =HbAd -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 22:40:53 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77009106566B; Wed, 20 Oct 2010 22:40:53 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 150A38FC13; Wed, 20 Oct 2010 22:40:53 +0000 (UTC) Received: from [208.206.78.30] (port=37541 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P8hL0-0000su-9O; Wed, 20 Oct 2010 15:40:52 -0700 From: Devin Teske To: Pawel Jakub Dawidek In-Reply-To: <20101020194720.GB1755@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <20101020100042.GE2127@garage.freebsd.pl> <1287594703.19873.58.camel@localhost.localdomain> <20101020194720.GB1755@garage.freebsd.pl> Content-Type: text/plain Organization: Vicor, Inc Date: Wed, 20 Oct 2010 15:40:49 -0700 Message-Id: <1287614449.19873.186.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 56cffa919b9803222843a3336065659f X-Scan-Host: postoffice.vicor.com Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 22:40:53 -0000 On Wed, 2010-10-20 at 21:47 +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 20, 2010 at 10:11:43AM -0700, Devin Teske wrote: > > > Then when you copy a > > > file to $ROOTDIR/tmp/ you must be sure there is no symbolic link under > > > the same name, as cp(1) will follow symblic link and you can end up > > > overwriting eg. /etc/spwd.db with /bin/ls. I think it will be easier to > > > just create random directory in $ROOTDIR/tmp/. This all must be done of > > > course when jail is turned off. > > > > I don't follow why the jail has be off. > > Because jailed root can mess with those files during your work (which is > bad in chroot(8) case). I disagree that this is any problem at all. Previously in the thread we discussed how copying the script into the jail and then executing said script is bad. This is no longer a problem because the script is now piped into a jailed sh(1) process. Even if the assumed-malicious root-user of the jail was able to (a) interrupt the sh (1) process executing within his jail and (b) somehow take control of the standard input file-descriptor feeding the script to the process, he still wouldn't be any closer to causing a problem in the master-host. If "rm -Rf /*" was injected into the input stream, it would only destroy the jail, not the master-host. Now, if you're instead talking about the temporary files that are used by the script... We (Garrett and I) discussed earlier in this thread the atomicity of the edit-operation. We use mktemp(1) to allocate a temporary file in a manner that is safe from race-conditions. When we're done operating on the temporary file, we perform a mv(1) to overwrite the destination file with the temporary file. Yes, it's true that the malicious root-user can hypothetically munge the temporary file before eventually overwriting the destination file, but again... he'd only be destroying his own jail. Race-conditions and malicious users aside (which should be of no concern given the above setup), what else could possibly require a jail to be powered down during the operation? > > And yes, similarly, the root-user of a jail can poison the shared > > libraries too, but again in the context of chroot/jexec the master host > > is protected. > > > > > > > Also for this reason I'd forget about chroot(8) - > > > even if you remember about libraries, there might still be malicious > > > configuration files, etc. so jexec(8) is the only option. > > > > I fail to see the difference between chroot(8) and jexec(8). Both rely > > on chroot(2). Correction, I was wrong. I took a peek at usr.sbin/jexec/jexec.c and found that it uses the new jail_attach() function from libc. > > So why do you think we have jail and not only chroot? There was never any debate here. Rather, there was a misunderstanding on my part that I thought jexec(8) used chroot(2). Now it makes more sense what you were saying earlier... "Even chroot(2) to jail's root is [unsafe]" > File system > namespace is not everything. when you chroot, a malicious command has > still access to all the other namespaces Right. I just didn't know that jexec(8) relied on a more-secure set of routines (i.e., jail_attach) than chroot(2). > - non-jailed processes being > one. It can then use ptrace to attach to non-jailed process and run with > its privileges and restrictions, ie. outside chroot. Being able to even > signal non-jailed processes alone is not good either. There are plenty > of ways to escape from a chroot when you are root. chroot might be quite > ok when you are running as regular user, but you still have access to > various namespaces even if read-only. There also might be uid collision > - non-jailed uid=1000 user might not be the same as jailed uid=1000 > user, but when running in chroot with this uid you can use non-jailed > uid=1000 process to escape. chroot wasn't really designed for what it is > used and for what you are trying to use it. > > > > Maybe it > > > will be wiser to just limit your script to operate within > > > fully-populated jails, so that you can always call 'jexec sysrc'? > > > > While that remains an option (and indeed a very valid approach since a > > "service jail" -- that is, a light-weight jail for running single > > daemons etc. in -- is unlikely to have a complementary set of rc.conf(5) > > files). > > > > Though I believe it to still be worth the effort to find a safe-way of > > reaching into the jail to perform the action because it's nice for > > developers to be able to depend on the script to get the job done > > regardless of whether (a) the jail has the script, (b) the jail has an > > untainted copy of the script (though admittedly the latter depends on > > untainted dependencies such as sh(1), grep(1), cp(1), etc.). > > > > But alas, if a safe-way can't be found, then assuredly the `-R dir' and > > `-j jail' options should be removed and the recommendation would be that > > they just copy the script into the jail. > > The -R option is still useful in the same way DESTDIR is useful for > installworld/installkernel and -D option for mergemaster(8). After much discussion, I think: `-R dir' will use chroot(8) and the man-page should warn users that this should _not_ be used to manage jails (that if they want to manage a jail, they should use instead `-j jail' which relies on jexec(8)). By offering both `-R dir' (which relies on chroot(8)) and `-j jail' (which relies on jexec(8)), the hope is that: `-R dir' will be used for: + FreeBSD release engineering (discussed below) + Managing jails on legacy systems lacking jexec(8) Meanwhile... `-j jail' will be used for: + Managing jails on modern systems with jexec(8) ASIDE: FreeBSD release engineering... there's a few rc.conf(5) files in `/usr/release/R' when working your way through FreeBSD release engineering. Having sysrc(8) with `-R dir' option available could mean that a developer wishing to fork his/her own release could write makefiles capable of changing the defaults prior to completing the later stages of release(7) and packing up their own custom OS. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Wed Oct 20 23:18:54 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C02711065673; Wed, 20 Oct 2010 23:18:54 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC9F8FC26; Wed, 20 Oct 2010 23:18:54 +0000 (UTC) Received: from [208.206.78.30] (port=38049 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P8hvl-0001Do-Df; Wed, 20 Oct 2010 16:18:53 -0700 From: Devin Teske To: Julian Elischer In-Reply-To: <1287593628.19873.41.camel@localhost.localdomain> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <4CBE6F55.5040609@freebsd.org> <1287593628.19873.41.camel@localhost.localdomain> Content-Type: text/plain Organization: Vicor, Inc Date: Wed, 20 Oct 2010 16:18:48 -0700 Message-Id: <1287616729.19873.215.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: fa07551004a4b25ceda46d11f14c15cc X-Scan-Host: postoffice.vicor.com Cc: freebsd-rc@freebsd.org, Pawel Jakub Dawidek Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 23:18:54 -0000 On Wed, 2010-10-20 at 09:53 -0700, Devin Teske wrote: > On Tue, 2010-10-19 at 21:25 -0700, Julian Elischer wrote: > > On 10/19/10 7:12 PM, Devin Teske wrote: > > > On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: > > >> On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > > >>> I added `-j jail' for specifying a jail id or name to operate within > > >>> (requires jls(8); overrides `-R dir'). > > >> [...] > > >> > > >> Note that operating on jail files from outside a jail is serious > > >> security problem. The files from within the jail can be symbolic links > > >> that point to files from outside a jail from your perspective. Even > > >> chroot(2) to jail's root is neither safe (running applications that can > > >> be modified by jail's root is obvious security hole) nor reliable (jail > > >> might not have all the commands). The only safe way is to jexec(8) into > > >> a jail, but it of course has the same relialability issue as chroot(8). > > >> > > > I see the concern, and you're absolutely right. > > > > > > I did see the need to use either chroot(8) or jexec(8), but for exactly > > > the same reasons you mention (handing execution off-to something that > > > could have been modified by the jail's root-user), I ended up writing > > > routines that just edited the files outside the jail. > > > > > > It appears that (due to the other aforementioned security problem, > > > involving hand-crafted symbolic links with malicious-intent), the only > > > proper solution would be: > > > > > > a. Copy ourselves into some temporary location within the jail > > > b. Hand execution off to ourself using either jexec(8) or chroot(8) > > > > > can you fire off a shell in the jail and somehow shove yourself down > > it's throat? > > I vaguely remember that one could feed a shell script into the shell > > somehow.. > > but I forget the details. > > You bet. > > $ echo tail -2 /usr/include/osreldate.h | sudo chroot / /bin/sh > #define __FreeBSD_version 801000 > #endif > $ echo tail -2 /usr/include/osreldate.h | sudo chroot /usr/jail/foomaster /bin/sh > #define __FreeBSD_version 492101 > #endif > > A more complete (yet simplified) example of a shell-script shoving > itself into a chroot'ed shell -- complete with custom-set of positional > parameters: > > ================================= BEGIN FILE: foo.sh > #!/bin/sh > jailed="$( sysctl -n security.jail.jailed )" > echo "jailed: $jailed" > echo -n "args: " > for arg in "$@"; do > echo -n "'$arg' " > done > echo > [ $jailed -eq 1 ] && exit > ( echo 'set -- "a b" "c d" "e f"' > cat $0 > ) | sudo jexec 8 /bin/sh > ================================= END FILE > > When executed: > > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > > $ jls jid path > 8 /usr/jail/foomaster > 9 /usr/jail/foomaster.deluxe > > $ ./foo.sh "1 2" "3 4" "5 6" > jailed: 0 > args: '1 2' '3 4' '5 6' > jailed: 1 > args: 'a b' 'c d' 'e f' > > This is of-course a simplified example. A productionized version should > take into consideration that PATH expansion may have been performed. Sorry... testing shows that when PATH expansion is performed, $0 has the expanded form, not the unexpanded form. For example: ============================== BEGIN FILE: foo.sh #!/bin/sh echo "0 = '$0'" ============================== END FILE $ foo.sh 0 = '/usr/local/bin/foo.sh' > [snip] > > Unfortunately, there seems little way around this as even the following > code fails in interesting ways: > > myscript="$0" > case "$myscript" in > */*) : Do nothing (already an absolute or relative path) > ;; > *) > # $0 doesn't contain any slashes -- we were invoked in > # one of two ways: > # > # 1. via $PATH expansion in the interactive shell Wrong, PATH expansion leads to the absolute or relative path to the program being in $0. > # 2. via sh(1) and $0 truly is in the CWD > # > # NOTE: It is not possible to detect when we were invoked > # via exec(3) versus sh(1) versus sh(1)-via-env(1) so > # testing for #2 above is impossible. Wrong, I found a way. $_ directly after invocation holds a clue... > > for dir in $PATH; do > [ -x "$dir/$0" -a -f "$dir/$0" ] || continue > myscript="$dir/$0" > break > done > esac > > > The comments in the above code-block explain why it won't work. > > In the case of: > > sh myscript > > $0 will equal "myscript" but, when reverse-PATH expansion is performed, > we may end up finding something with the same name and then end up > executing something perhaps entirely different. This has changed slightly because we don't need to perform reverse PATH expansion. > It seems clear that the only safe way to pass off execution to onself is > to hard-code the path to yourself. > > For example: > > myscript=/usr/local/bin/foo > ( echo 'set -- "a b" "c d" "e f"' > cat $myscript > ) | sudo jexec 8 /bin/sh > > > Can anyone think of anything better? I came up with this... (first to test) ============================== BEGIN FILE: foo.sh #!/bin/sh echo "_ = '$_'" echo "0 = '$0'" ============================== END FILE Then we test different invocations: $ sh foo.sh _ = '/bin/sh' 0 = 'foo.sh' $ env sh foo.sh _ = '/usr/bin/env' 0 = 'foo.sh' $ ./foo.sh _ = './foo.sh' 0 = './foo.sh' $ /var/tmp/foo.sh _ = '/var/tmp/foo.sh' 0 = '/var/tmp/foo.sh' $ PATH="/var/tmp" $ foo.sh _ = '/var/tmp/foo.sh' 0 = '/var/tmp/foo.sh' $ cd /var/tmp $ PATH="." $ foo.sh _ = './foo.sh' 0 = './foo.sh' $ PATH=":" $ foo.sh _ = './foo.sh' 0 = './foo.sh' $ sh /var/tmp/foo.sh _ = '/bin/sh' 0 = '/var/tmp/foo.sh' And in analyzing each of the results... $0 is perfectly acceptable in ALL results (as long as we don't change the current working directory -- outside the protection of a subshell at least, such as (...), $(...), `...`, or sh -c '...'). So this is the final answer... ( echo 'set -- "a b" "c d" "e f"' cat $0 ) | sudo jexec 8 /bin/sh -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Thu Oct 21 06:46:26 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A54D1065670; Thu, 21 Oct 2010 06:46:26 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id E0C588FC13; Thu, 21 Oct 2010 06:46:25 +0000 (UTC) Received: from [173.241.24.124] (port=51102 helo=[10.0.0.109]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1P8our-0004aF-Bj; Wed, 20 Oct 2010 23:46:25 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <1287510629.25599.2.camel@localhost.localdomain> Date: Wed, 20 Oct 2010 23:46:20 -0700 Message-Id: References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> To: Devin Teske X-Mailer: Apple Mail (2.1081) X-Scan-Signature: b36ebcecae68c541cee255cd563fabe7 X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Julian Elischer , freebsd-rc@freebsd.org Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 06:46:26 -0000 On Oct 19, 2010, at 10:50 AM, Devin Teske wrote: > On Mon, 2010-10-18 at 17:39 -0700, Devin Teske wrote: >> On Wed, 2010-10-13 at 12:05 -0700, Devin Teske wrote:=20 >>> On Tue, 2010-10-12 at 16:13 -0700, Devin Teske wrote: >>>> Hey all, >>>>=20 >>>> [...] >>>>=20 >>>> Behold... sysrc(8) v2.0 >>>>=20 >>>> #!/bin/sh >>>> [...] >>>=20 >>> Version 2.1 is available here: http://druidbsd.sf.net/ >>=20 >> Version 2.2 now. >> Same links. >>=20 >> I added `-R dir' for specifying an alternate root (other than `/') >> directory (mostly for handling jails). >=20 > Version 2.3 now. > Same links. >=20 Version 2.4 now. Same links. >=20 >>=20 >>>=20 >>> Direct links: >>> http://druidbsd.sf.net/download/sysrc.gz (download gzipped) >>> http://druidbsd.sf.net/download/sysrc.txt (view as text) >>>=20 >>> Here's the changes: >>>=20 >>=20 >=20 --- sysrc.2_3 2010-10-19 10:49:52.000000000 -0700 +++ sysrc 2010-10-20 20:21:37.000000000 -0700 @@ -2,8 +2,8 @@ # -*- tab-width: 4 -*- ;; Emacs # vi: set tabstop=3D4 :: Vi/ViM # -# Revision: 2.3 -# Last Modified: October 19th, 2010 +# Revision: 2.4 +# Last Modified: October 20th, 2010 ############################################################ COPYRIGHT # # (c)2010. Devin Teske. All Rights Reserved. @@ -30,7 +30,8 @@ # SUCH DAMAGE. # # AUTHOR DATE DESCRIPTION -# dteske 2010.10.19 Add `-j jail' for operating within jails (see = jls(8)). +# dteske 2010.10.20 Make `-j jail' and `-R dir' more secure +# dteske 2010.10.19 Add `-j jail' for operating on jails (see = jexec(8)). # dteske 2010.10.18 Add `-R dir' for operating in different = root-dir. # dteske 2010.10.13 Allow `-f file' multiple times. # dteske 2010.10.12 Updates per freebsd-hackers thread. @@ -58,7 +59,7 @@ # -N Show only variable names, not their values. # -R dir Operate within the root directory `dir' rather than = `/'. # -j jail The jid or name of the jail to operate within = (overrides -# `-R dir'; requires jls(8)). +# `-R dir'; requires jexec(8)). #=20 # ENVIRONMENT: # RC_DEFAULTS Location of `/etc/defaults/rc.conf' file. @@ -182,7 +183,7 @@ usage() eprintf "$optfmt" "-j jail" \ "The jid or name of the jail to operate within = (overrides" eprintf "$optfmt" "" \ - "\`-R dir'; requires jls(8))." + "\`-R dir'; requires jexec(8))." eprintf "\n" =20 eprintf "ENVIRONMENT:\n" @@ -302,7 +303,8 @@ sysrc_get() # source_rc_confs the value has not changed, then we = should # restore the value to the one inherited from = RC_DEFAULTS # before performing the final query (preventing us from - # returning RC_CONFS which may be relative to ROOTDIR). + # returning what was passed in via `-f' when the intent = was + # instead to query the value from the file(s) = specified). # if [ "$1" =3D "rc_conf_files" -a \ "$RC_CONFS" !=3D "" -a \ @@ -372,7 +374,7 @@ sysrc_find() for file in $conf_files; do [ -f "$file" -a -r "$file" ] || continue if grep -q "^[[:space:]]*$varname=3D" $file; then - echo ${file#$ROOTDIR} + echo $file return $SUCCESS fi done @@ -443,7 +445,7 @@ sysrc_set() # local not_found=3D local file=3D"$( sysrc_find "$varname" )" - if [ "$file" =3D "${RC_DEFAULTS#$ROOTDIR}" -o ! "$file" ]; then + if [ "$file" =3D "$RC_DEFAULTS" -o ! "$file" ]; then # # We either got a null response (not found) or the = variable # was only found in the rc.conf(5) defaults. In either = case, @@ -631,43 +633,49 @@ if [ ! "$SHOW_VALUE" ]; then fi =20 # -# Process `-j jail' command-line option +# Process `-j jail' and `-R dir' command-line options # -if [ "$JAIL" ]; then - ROOTDIR=3D"$( jls -j "$JAIL" path )" || die -fi - -# -# Process `-R dir' command-line option -# -if [ "$ROOTDIR" ]; then - # - # Sanity checks - # - [ -e "$ROOTDIR" ] || die "%s: %s: No such file or directory" \ - "$progname" "$ROOTDIR" - [ -d "$( eval realpath "$ROOTDIR" )" ] || die \ - "%s: %s: Not a directory" "$progname" "$ROOTDIR" - - # - # When ROOTDIR is set, we need to: +if [ "$JAIL" -o "$ROOTDIR" ]; then # - # a. Prefix RC_DEFAULTS with ROOTDIR + # Reconstruct the arguments that we want to carry-over # - RC_DEFAULTS=3D"$ROOTDIR$RC_DEFAULTS" + args=3D" + ${SYSRC_VERBOSE:+-v} + ${RC_CONFS:+-f'$RC_CONFS'} + $( [ "$SHOW_ALL" =3D "1" ] && echo \ -a ) + $( [ "$SHOW_ALL" =3D "2" ] && echo \ -A ) + ${DESCRIBE:+-d} + ${SHOW_EQUALS:+-e} + ${IGNORE_UNKNOWNS:+-i} + $( [ "$SHOW_NAME" ] || echo \ -n ) + $( [ "$SHOW_VALUE" ] || echo \ -N ) + " + for arg in "$@"; do + args=3D"$args '$arg'" + done =20 - # b. Override the use of rc_conf_files from RC_DEFAULTS - # by setting RC_CONFS # - [ "$RC_CONFS" ] || RC_CONFS=3D"$( sysrc_get rc_conf_files )" - - # c. Prefix RC_CONFS with ROOTDIR + # If both are supplied, `-j jail' supercedes `-R dir' # - r=3D - for file in $RC_CONFS; do - r=3D"$r${r:+ }$ROOTDIR$file" - done - RC_CONFS=3D"$r" + if [ "$JAIL" ]; then + # + # Re-execute ourselves with sh(1) via jexec(8) + # + ( echo set -- $args + cat $0 + ) | env - RC_DEFAULTS=3D"$RC_DEFAULTS" \ + /usr/sbin/jexec "$JAIL" /bin/sh + exit $? + elif [ "$ROOTDIR" ]; then + # + # Re-execute ourselves with sh(1) via chroot(8) + # + ( echo set -- $args + cat $0 + ) | env - RC_DEFAULTS=3D"$RC_DEFAULTS" \ + /usr/sbin/chroot "$ROOTDIR" /bin/sh + exit $? + fi fi =20 # @@ -692,7 +700,7 @@ if [ "$SHOW_ALL" ]; then IFS=3D"$IFS|" EXCEPT=3D"IFS|EXCEPT|PATH|RC_DEFAULTS|OPTIND|DESCRIBE|SEP"= = EXCEPT=3D"$EXCEPT|SHOW_ALL|SHOW_EQUALS|SHOW_NAME|SHOW_VALUE" - EXCEPT=3D"$EXCEPT|SYSRC_VERBOSE|RC_CONFS|ROOTDIR" + EXCEPT=3D"$EXCEPT|SYSRC_VERBOSE|RC_CONFS" =20 # # Clean the environment (except for our required = variables) @@ -724,8 +732,7 @@ if [ "$SHOW_ALL" ]; then # other than rc.conf(5) defaults. # [ "$SHOW_ALL" =3D "1" -a \ - "$( sysrc_find rc_conf_files )" =3D \ - "${RC_DEFAULTS#$ROOTDIR}" \ + "$( sysrc_find rc_conf_files )" =3D = "$RC_DEFAULTS" \ ] \ && unset rc_conf_files fi @@ -782,11 +789,8 @@ while [ $# -gt 0 ]; do =20 if [ "$SYSRC_VERBOSE" ]; then file=3D"$( sysrc_find "$NAME" )" - if [ "$file" =3D "${RC_DEFAULTS#$ROOTDIR}" \ - -o ! "$file" ]; then + [ "$file" =3D "$RC_DEFAULTS" -o ! "$file" ] && \ file=3D"$( sysrc_get = "rc_conf_files%%[$IFS]*" )" - file=3D"${file#$ROOTDIR}" - fi echo -n "$file: " fi =20 -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.1 GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? = K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ = e>+ h r>++ y+=20 ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- From owner-freebsd-rc@FreeBSD.ORG Thu Oct 21 11:07:03 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D597F106564A; Thu, 21 Oct 2010 11:07:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 46AFE8FC08; Thu, 21 Oct 2010 11:07:03 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 1ACA745CAC; Thu, 21 Oct 2010 13:07:02 +0200 (CEST) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4B5D645C8A; Thu, 21 Oct 2010 13:06:56 +0200 (CEST) Date: Thu, 21 Oct 2010 13:06:25 +0200 From: Pawel Jakub Dawidek To: Devin Teske Message-ID: <20101021110625.GA2624@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <20101020100042.GE2127@garage.freebsd.pl> <1287594703.19873.58.camel@localhost.localdomain> <20101020194720.GB1755@garage.freebsd.pl> <1287614449.19873.186.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <1287614449.19873.186.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 11:07:03 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2010 at 03:40:49PM -0700, Devin Teske wrote: > On Wed, 2010-10-20 at 21:47 +0200, Pawel Jakub Dawidek wrote: > > On Wed, Oct 20, 2010 at 10:11:43AM -0700, Devin Teske wrote: > > > I don't follow why the jail has be off. > >=20 > > Because jailed root can mess with those files during your work (which is > > bad in chroot(8) case). >=20 > I disagree that this is any problem at all. >=20 > Previously in the thread we discussed how copying the script into the > jail and then executing said script is bad. This is no longer a problem > because the script is now piped into a jailed sh(1) process. Even if the > assumed-malicious root-user of the jail was able to (a) interrupt the sh > (1) process executing within his jail and (b) somehow take control of > the standard input file-descriptor feeding the script to the process, he > still wouldn't be any closer to causing a problem in the master-host. If > "rm -Rf /*" was injected into the input stream, it would only destroy > the jail, not the master-host. If you read entire sentence you will note, that I was talking about chroot(8) case, not about jexec(8) case:) > Now, if you're instead talking about the temporary files that are used > by the script... >=20 > We (Garrett and I) discussed earlier in this thread the atomicity of the > edit-operation. >=20 > We use mktemp(1) to allocate a temporary file in a manner that is safe > from race-conditions. > > When we're done operating on the temporary file, we perform a mv(1) to > overwrite the destination file with the temporary file. >=20 > Yes, it's true that the malicious root-user can hypothetically munge the > temporary file before eventually overwriting the destination file, but > again... he'd only be destroying his own jail. Exactly, it is good that you are aware that mktemp(1) doesn't protect in any away against jailed root. > Race-conditions and malicious users aside (which should be of no concern > given the above setup), what else could possibly require a jail to be > powered down during the operation? Let this be clear. I was discussing chroot(8) case. > > > I fail to see the difference between chroot(8) and jexec(8). Both rely > > > on chroot(2). >=20 > Correction, I was wrong. I took a peek at usr.sbin/jexec/jexec.c and > found that it uses the new jail_attach() function from libc. You were partially right - jail does use chroot functionality, but internally, in the kernel, but chroot is only one of the restrictions. > After much discussion, I think: >=20 > `-R dir' will use chroot(8) and the man-page should warn users that this > should _not_ be used to manage jails (that if they want to manage a > jail, they should use instead `-j jail' which relies on jexec(8)). Sounds reasonable. Apart from documenting it, checking if the given directory for -R option is a root of one of the running jails and warning about it would be nice too. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzAHrEACgkQForvXbEpPzTcswCg+GC7l9twFYIJSNAIjTonEI8b nLAAn1UFOxoQedRZE1Qhq+L7h2sMHfsd =eBJW -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-rc@FreeBSD.ORG Thu Oct 21 15:45:02 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C6C10656A5 for ; Thu, 21 Oct 2010 15:45:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 98BBA8FC1A for ; Thu, 21 Oct 2010 15:45:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9LFWRWB008336; Thu, 21 Oct 2010 08:32:27 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 1C5F62D6015; Thu, 21 Oct 2010 08:32:25 -0700 (PDT) Message-ID: <4CC05D3E.4060704@freebsd.org> Date: Thu, 21 Oct 2010 08:33:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Devin Teske References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> In-Reply-To: X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-rc@freebsd.org Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:45:02 -0000 On 10/20/10 11:46 PM, Devin Teske wrote: > -# c. Prefix RC_CONFS with ROOTDIR > +# If both are supplied, `-j jail' supercedes `-R dir' > # I was thinking about this... -j X -R /jail/jailY is what you would use if you were BUILDING a child jail within a jail.. Since we now have hierarchical jails :-) you need not implement this.. I was just stating that I interpreted what it would mean differently from you.. From owner-freebsd-rc@FreeBSD.ORG Thu Oct 21 19:07:34 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D5D1065679; Thu, 21 Oct 2010 19:07:34 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCE78FC20; Thu, 21 Oct 2010 19:07:33 +0000 (UTC) Received: from [208.206.78.30] (port=41206 helo=dt.vicor.com) by postoffice.vicor.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.71) (envelope-from ) id 1P90U7-0002iz-EE; Thu, 21 Oct 2010 12:07:33 -0700 From: Devin Teske To: Julian Elischer In-Reply-To: <4CC05D3E.4060704@freebsd.org> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <4CC05D3E.4060704@freebsd.org> Content-Type: text/plain Organization: Vicor, Inc Date: Thu, 21 Oct 2010 12:07:31 -0700 Message-Id: <1287688051.17360.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit X-Scan-Signature: 039cb2e8e02b076007c9031e8d4837ec X-Scan-Host: postoffice.vicor.com Cc: freebsd-rc@freebsd.org Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 19:07:34 -0000 On Thu, 2010-10-21 at 08:33 -0700, Julian Elischer wrote: > On 10/20/10 11:46 PM, Devin Teske wrote: > > - # c. Prefix RC_CONFS with ROOTDIR > > + # If both are supplied, `-j jail' supercedes `-R dir' > > # > I was thinking about this... -j X -R /jail/jailY is what you would > use if you were BUILDING a child jail within a jail.. > Since we now have hierarchical jails :-) > > you need not implement this.. I was just stating that I interpreted > what it would mean differently from you.. ^_^ I think we think alike. I thought long and hard about that one (actually saw some real merits to supporting either multiple `-j' arguments or combination `-j'/`-R', or multiple `-R', et cetera, etc. ad nauseum). ... but where would it end? I had to draw the line somewhere, and I figured, hey... if someone wants to build heirarchical jails, they can do this: jexec 8 sysrc -R /usr/jail/subjail1 ... or chroot /usr/jail/jail1 sysrc -R /usr/jail/subjail1 ... Where the parent jail is `/usr/jail/jail1' and the child jail is `/usr/jail/jail1/usr/jail/subjail1'. I think that seems reasonable. Even going one level deeper seems do-able (if not a bit masochistic): jexec 8 jexec 1 sysrc -R /usr/jail/subsubjail1 ... or chroot /usr/jail/jail1 chroot /usr/jail/subjail1 sysrc - R /usr/jail/subsubjail1 ... ============================== ... and it dawned on me a couple days ago ... `-R dir' is absolutely required for operating on _inactive_ jails. So this really becomes a powerful tool when you consider that nearly-all jail admins go through the following process at least once in their life: 1. Populate some directory with vanilla FreeBSD installation (either from `buildworld'/`installworld' process or via some other method such as jail_build(8) + binary distribution) 2. Configure services in rc.conf(5) file(s) within the jail prior to starting the jail. 3. Bring the jail up. I think it's notably handy to be able to have a makefile that can cleanly configure the rc.conf(5) file(s) for you within that jail prior to bringing it up. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <-