Home | History | Annotate | only in /test/stcnv/usr/src/tools/runwattr
Up to higher level directory
NameDateSize
bin/17-Jun-2009
etc/17-Jun-2009
lib/17-Jun-2009
Makefile17-Jun-20091K
pkgdef/17-Jun-2009
README17-Jun-200914.1K
STC.INFO17-Jun-20094.1K
STF.INFO17-Jun-20091K

README

      1 #
      2 # CDDL HEADER START
      3 #
      4 # The contents of this file are subject to the terms of the
      5 # Common Development and Distribution License (the "License").
      6 # You may not use this file except in compliance with the License.
      7 #
      8 # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
      9 # or http://www.opensolaris.org/os/licensing.
     10 # See the License for the specific language governing permissions
     11 # and limitations under the License.
     12 #
     13 # When distributing Covered Code, include this CDDL HEADER in each
     14 # file and include the License file at usr/src/OPENSOLARIS.LICENSE.
     15 # If applicable, add the following below this CDDL HEADER, with the
     16 # fields enclosed by brackets "[]" replaced with your own identifying
     17 # information: Portions Copyright [yyyy] [name of copyright owner]
     18 #
     19 # CDDL HEADER END
     20 #
     21 
     22 #
     23 # Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
     24 # Use is subject to license terms.
     25 #
     26 # ident	"@(#)README	1.4	08/11/21 SMI"
     27 #
     28 
     29 runwattr - Run With Attributes
     30 
     31 	This tool provides a simple interface so that test cases can
     32 	execute programs with any desired credential level.  This
     33 	currently includes manipulation of the real/effective uid/gid,
     34 	privileges, and zone.  In addition, environment variables can
     35 	be changed or added.
     36 
     37 	runwattr can be thought of as a "filter" on the credentials of
     38 	the programs run under it.  In other words, invoking "runwattr
     39 	someutility" would have the same effect as invoking
     40 	"someutility" directly.  However, invoking "runwattr -z
     41 	somezone someutility" would switch to the alternate zone while
     42 	preserving as much as possible of the current context.  There
     43 	are additional options described below to alter other aspects
     44 	of the credential context; these can be used together in any
     45 	desired combination.
     46 
     47 Usage:
     48 
     49 	runwattr [-u uid] [-U uid] [-g gid] [-G gid]
     50 	         [-p priv_mod ...]
     51 	         [-z zonename]
     52 	         [-i] [-e name=value ...]
     53 	         [-D]
     54 	         [--] command [args ...]
     55 
     56 	The uid/gid options manipulate user and group ids:
     57 	-u and -g will set both the real and effective uid or gid.
     58 	-U and -G will set the real uid or gid only, and can also be
     59 	used together with -u and -g to set a real uid or gid that is
     60 	different from the effective uid or gid set by -u or -g.
     61 
     62 	The priv_mod syntax is: [=+-]priv_name[,priv_name]*
     63 	= will explicitly set the listed priv_name(s)
     64 	+ and - will add or remove the listed priv_name(s) to
     65 	the current privileges.
     66 
     67 	The -z option specifies the desired zone in which to execute
     68 	the command.  If the specified zone matches the current zone,
     69 	the option is ignored and no special action is taken.  When
     70 	runwattr is invoked in the global zone, this option can be
     71 	used to change to a non-global zone.  When runwattr is
     72 	invoked in a non-global zone, the only valid value for this
     73 	option is to specify the current zone, which would be ignored
     74 	as described above.
     75 
     76 	The -i and -e options manipulate environment variables.
     77 	By default, the current environment variables will be
     78 	propagated into the environment of the child process.
     79 	-i will clear all variables from the current environment.
     80 	-e can be used to add or change additional variables.
     81 
     82 	The -D option enables extra debugging information.
     83 
     84 Installation:
     85 
     86 	Several installation alternatives are available:
     87 
     88 	1) Package Installation:
     89 
     90 	   This method uses the standard STF techniques to create a
     91 	   Solaris package, which will be installed under the base
     92 	   directory "/opt/SUNWstc-runwattr".
     93 
     94 	   Briefly, this installation is performed as follows:
     95 
     96                 # set path to STF bin directory
     97                 PATH=<path-to-STF>/bin/`uname -p`:$PATH
     98                 export PATH
     99 
    100 		# WS_ROOT represents the root of the STC workspace
    101                 cd <WS_ROOT>/usr/src/tools/runwattr
    102                 stf_build package
    103                 cd <WS_ROOT>/packages/`uname -p`
    104                 pkgadd -d `pwd` SUNWstc-runwattr
    105 
    106 	   (NOTE: stf_build is part of the SUNWstc-stf package)
    107 
    108 	   To uninstall:
    109 
    110 		pkgrm SUNWstc-runwattr
    111 
    112 	2) Manual Installation:
    113 
    114 	   These steps can be used if STF or a SUNWstc-runwattr
    115 	   package are unavailable.  In addition, this method
    116 	   allows the flexibility to install runwattr in any
    117 	   location.
    118 
    119 	   The following steps will use the variable ${BASEDIR}
    120 	   to identify the root of the installation; this can
    121 	   be changed to any desired location.
    122 
    123 		# define location for installation
    124 		BASEDIR=/usr/local
    125 
    126 		# install runwattr script
    127 		mkdir -p ${BASEDIR}/bin
    128 		cp -p bin/runwattr.pl ${BASEDIR}/bin/runwattr
    129 		chmod +x ${BASEDIR}/bin/runwattr
    130 
    131 		# install "forcepriv" helper binaries
    132 		/usr/bin/ksh -p bin/runwattr_admin.ksh \
    133 		    install -s ${BASEDIR}/lib/forcepriv
    134 
    135 	   To uninstall:
    136 
    137 		# remove runwattr script
    138 		rm -f ${BASEDIR}/bin/runwattr
    139 
    140 		# remove "forcepriv" helper binaries
    141 		/usr/bin/ksh -p bin/runwattr_admin.ksh \
    142 		    uninstall ${BASEDIR}/lib/forcepriv
    143 
    144 	3) Network installation:
    145 
    146 	   This is simply a variation on the "manual" installation
    147 	   steps described above that can be used when the main
    148 	   runwattr script is already installed in a shared network
    149 	   location.  On the local system, only the "runwattr_admin"
    150 	   steps from the "manual" installation method need to be
    151 	   performed.
    152 
    153 	   Because the "forcepriv" scripts are not installed in a fixed
    154 	   location relative to the runwattr script, the environment
    155 	   variable RUNWATTR_FORCEPRIV may be used to tell the runwattr
    156 	   script where to find the "forcepriv" binaries.
    157 
    158 		RUNWATTR_FORCEPRIV=/usr/local/lib/forcepriv
    159 		export RUNWATTR_FORCEPRIV
    160 		runwattr_admin install -s ${RUNWATTR_FORCEPRIV}
    161 		# test execution steps using runwattr go here
    162 		runwattr_admin uninstall ${RUNWATTR_FORCEPRIV}
    163 
    164 	   The runwattr and runwattr_admin scripts both acknowledge
    165 	   the path "/var/tmp/SUNWstc-runwattr/forcepriv" as a
    166 	   default location for the "forcepriv" binaries.  If this
    167 	   location is used, no environment variable is required
    168 	   and the steps are simply as follows:
    169 
    170 		runwattr_admin install -s
    171 		# test execution steps using runwattr go here
    172 		runwattr_admin uninstall
    173 
    174 RBAC alternative for forcepriv:
    175 
    176 	All of the above procedures will create a setuid/setgid
    177 	root binary on the system.  This can then be used by any
    178 	system user to gain all privileges.  If this is not desired,
    179 	RBAC can be used to restrict the utility to designated users.
    180 
    181 	1) Remove the setuid bit from the forcepriv helper binary.
    182 
    183 	   If runwattr is installed via a package, this must be done
    184 	   with a command such as the following.  Be sure to replace
    185 	   the "/opt/SUNWstc-runwattr" portion of the pathname if
    186 	   another installation location was chosen.
    187 
    188 		chmod -s /opt/SUNWstc-runwattr/lib/forcepriv
    189 
    190 	   If runwattr is installed using the "manual" or "network"
    191 	   methods described above, simply omit the "-s" option
    192 	   from the "runwattr_admin install" command.
    193 
    194 	2) Add entries for the runwattr tools to the system's
    195 	   prof_attr(4) and exec_attr(4) databases.
    196 
    197 	   Sample entries are provided in the "etc/security"
    198 	   directory of this distribution.  Be sure to replace
    199 	   the "/opt/SUNWstc-runwattr" portion of the pathnames
    200 	   in exec_attr(4) if another installation location was
    201 	   chosen.
    202 
    203 	3) Add the "Solaris Test Collection runwattr" profile to
    204 	   the user_attr(4) database for user accounts that are
    205 	   authorized to use the tool.
    206 
    207 	For further details on RBAC, see the "Roles, Rights Profiles,
    208 	and Privileges" section of the __Solaris System Administration
    209 	Guide: Security Services__ and the prof_attr(4), exec_attr(4)
    210 	and user_attr(4) man pages.
    211 
    212 Further details on the location of "forcepriv" helper binaries:
    213 
    214 	The "forcepriv" helper binaries are located at runwattr
    215 	execution time by searching for the first match against
    216 	the following list of locations:
    217 
    218 	1) The full path specified by the RUNWATTR_FORCEPRIV
    219 	   environment variable, if it is set.
    220 
    221 	2) The standard path "/var/tmp/SUNWstc-runwattr/forcepriv",
    222 	   which is the default location for "network" installations.
    223 
    224 	3) The standard path "/opt/SUNWstc-runwattr/lib/forcepriv",
    225 	   which is the default location for "package" installations.
    226 
    227 	4) A path derived from the location of the runwattr script
    228 	   itself.  This algoritm assumes that if the runwattr script
    229 	   is installed as /some_path_name/bin/runwattr then the
    230 	   forcepriv binary would be /some_path_name/lib/forcepriv.
    231 
    232 	Like the runwattr script itself, copies of these binaries
    233 	must be created at the same location in each system zone.
    234 	The following commands are used to maintain these copies:
    235 
    236 	runwattr_admin install   [ -z <zonename> ] [ -s ] [ <forcepriv_path> ]
    237 	runwattr_admin uninstall [ -z <zonename> ] [ <forcepriv_path> ]
    238 
    239 	The "install" and "uninstall" subcommands indicate whether
    240 	the forcepriv binaries should be created or removed.
    241 
    242 	The "-z <zonename>" option (which may be repeated) indicates
    243 	which system zones are manipulated during each invocation of
    244 	runwattr_admin.  By default, when this command is used in the
    245 	global zone, ALL system zones are included; when used in a
    246 	non-global zone, only that zone is included.
    247 
    248 	The "-s" option indicates that the runwattr_admin script
    249 	should apply "setuid/setgid root" permissions to the forcepriv
    250 	binaries that are created.  The invoking prcess must already
    251 	have super-user credentials to use this option.
    252 
    253 	The optional "<forcepriv_path>" argument may be used to
    254 	explicitly state the location where the forcepriv binaries
    255 	should be created:
    256 
    257 	1) The path given in the "<forcepriv_path>" argument is
    258 	   always used when it is provided.
    259 
    260 	2) Otherwise, the path given in the RUNWATTR_FORCEPRIV
    261 	   environment variable is used if it is defined.
    262 
    263 	3) Otherwise, "/var/tmp/SUNWstc-runwattr/forcepriv" is
    264 	   used by default.
    265 
    266 	When "runwattr_admin install" is executed, a single final
    267 	subdirectory component of the "<forcepriv_path>" argument
    268 	(for example, the "SUNWstc-runwattr" directory from the
    269 	full path "/var/tmp/SUNWstc-runwattr/forcepriv") will be
    270 	created if needed.  Similarly, when "runwattr_admin uninstall"
    271 	is executed, the final subdirectory will be removed if it
    272 	would otherwise be empty.
    273 
    274 Limitations:
    275 
    276 	The restriction on movement between zones (with the -z
    277 	option) is imposed by the zones(5) model and applies in
    278 	all cases.
    279 
    280 	Modification of any attribute of a credential context which
    281 	has a security impact (with the -uUgGpz options) is subject
    282 	to the limitations described in ppriv(1) and privileges(5).
    283 
    284 	Typically, this requires that user invoking runwattr be able
    285 	to run the associated "forcepriv" utility with all privileges.
    286 	This can be achieved by the following methods:
    287 
    288 		- Installing forcepriv as a setuid/setgid 0 binary.
    289 		- Using RBAC profiles to asign this right to users.
    290 		- Invoking the runwattr utility as the super-user.
    291 
    292 	In other cases, modification of the credential context is
    293 	restricted to those changes that the invoking user would
    294 	have been able to achieve through their preexisting privilege
    295 	level:
    296 
    297 		- Switching zones may not be possible.
    298 		- Changes to uid/gid may not be possible.
    299 		- Privileges may only be reduced.
    300 
    301 	The -e and -i options may be used freely without limitation.
    302 
    303 Examples:
    304 
    305 	In the following two examples, the command "zonename ; id ;
    306 	ppriv -S $$" is executed twice.  The first invocation
    307 	displays the existing credential context, the second
    308 	shows how it is modified with runwattr:
    309 
    310 	1) From within the public zone, operating as a normal user,
    311 	   invoke a command as a different user with additional
    312 	   privileges:
    313 
    314 		% zonename ; id ; ppriv -S $$
    315 		public
    316 		uid=1001(tester) gid=10(staff)
    317 		143968: ksh
    318 		flags = <none>
    319 		        E: basic
    320 		        I: basic
    321 		        P: basic
    322 		        L: zone
    323 		% runwattr \
    324 			-u nobody -g nobody \
    325 			-p +file_dac_read \
    326 			'zonename ; id ; ppriv -S $$'
    327 		public
    328 		uid=60001(nobody) gid=60001(nobody)
    329 		144046: sh -c zonename ; id ; ppriv -S $$
    330 		flags = <none>
    331 		        E: basic,file_dac_read
    332 		        I: basic,file_dac_read
    333 		        P: basic,file_dac_read
    334 		        L: zone
    335 
    336 	2) From within the global zone, operating as the super user,
    337 	   enter the public zone and execute a command with altered
    338 	   uid, gid, and privilege:
    339 
    340 		# zonename ; id ; ppriv -S $$
    341 		global
    342 		uid=0(root) gid=0(root)
    343 		128876: ksh
    344 		flags = <none>
    345 		        E: all
    346 		        I: basic
    347 		        P: all
    348 		        L: all
    349 		# runwattr \
    350 			-z public \
    351 			-U tester -G staff \
    352 			-u nobody -g nobody \
    353 			-p -proc_info \
    354 			'zonename ; id ; ppriv -S $$'
    355 		public
    356 		uid=1001(tester) gid=10(staff) euid=60001(nobody) egid=60001(nobody)
    357 		144109: sh -c zonename ; id ; ppriv -S $$
    358 		flags = <none>
    359 		        E: basic,!proc_info
    360 		        I: basic,!proc_info
    361 		        P: basic,!proc_info
    362 		        L: zone
    363 
    364 	The following three examples show how environment variables
    365 	can be propagated between zones and manipulated with the
    366 	-e and -i options:
    367 
    368 	1) Propagating environment variables between zones
    369 	   automatically:
    370 
    371 		# zonename
    372 		global
    373 		# MY_SPECIAL_VARIABLE=foo
    374 		# export MY_SPECIAL_VARIABLE
    375 		# zlogin public 'env | grep MY_SPECIAL_VARIABLE'
    376 		# runwattr -z public 'env | grep MY_SPECIAL_VARIABLE'
    377 		MY_SPECIAL_VARIABLE=foo
    378 
    379 	2) Using -e to set extra environment variables:
    380 
    381 		# zonename
    382 		global
    383 		# unset MY_SPECIAL_VARIABLE
    384 		# env | grep MY_SPECIAL_VARIABLE
    385 		# runwattr \
    386 			-z public \
    387 			-e MY_SPECIAL_VARIABLE=foo \
    388 			'env | grep MY_SPECIAL_VARIABLE'
    389 		MY_SPECIAL_VARIABLE=foo
    390 
    391 	3) Using -i to severely limit the environment, removing
    392 	   even those variables set automatically with zlogin(1).
    393 	   "wc -l" is used to count the number of variables defined
    394 	   in the global zone, set by zlogin, and left after using
    395 	   "runwattr -i":
    396 
    397 		# zonename ; env | wc -l
    398 		global
    399 		      45
    400 		# zlogin public 'zonename ; env | wc -l'
    401 		public
    402 		       7
    403 		# runwattr -z public -i 'zonename ; env | wc -l'
    404 		public
    405 		       0
    406 
    407 Warnings:
    408 
    409 	This tool should only be installed on systems used for test
    410 	purposes, and never on a production or other sensitive system.
    411 
    412 	This tool will pass special shell environment variables
    413 	(such as PATH or IFS) along to the environment for the child
    414 	process.  Make certain that this does not have unintended
    415 	consequences.  In particular, make certain that the correct
    416 	child process commands are executed.
    417 
    418 Notes:
    419 
    420 	This tool is implemented as a Perl script, with a helper binary
    421 	to force privileges.  The helper is simply a copy of the normal
    422 	ppriv(1) program included in the OS.
    423 
    424