|
|
United States-English | |
|
|
 |
|
HP-UX Reference > C
chatr_ia(1)Integrity Systems OnlyHP-UX 11i Version 3: February 2007 |
|
|
NAMEchatr_ia: chatr — change program's internal attributes on Integrity systems SYNOPSISFormat 1: for files with a single text segment and a single data segmentchatr [-s] [-z|Z] [-l library] [-B mode] [+as mode] [+b flag] [+cd flag] [+ci flag] [+dbg flag] [+es flag] [+gst flag] [+gstsize size] [+id flag] [+k flag] [+l library] [+md flag] [+mergeseg flag] [+mi flag] [+o flag] [+pd size] [+pi size] [+s flag] [+z flag] [+I flag] file ... Format 2: for explicit specification of segmentschatr {+sa address | +sall | +si index} [-s] [-B mode] [+c flag] [+dz flag] [+k flag] [+m flag] [+mergeseg flag] [+p size] [+r flag] [+s flag] [+z flag] [+I flag] file ... RemarksThis manpage describes chatr on Integrity systems. For chatr on PA-RISC systems, see chatr_pa(1). DESCRIPTIONchatr allows you to change a program's internal attributes for 32-bit and 64-bit ELF files. There are two syntactic forms that can be used to invoke chatr.
Upon completion, chatr prints the file's old and new values to standard output unless -s is specified. The +pd and +pi options only provide a hint for the virtual memory page size. The actual page sizes may vary. Under certain conditions, page size hints of L may result in better performance, depending on the specific memory requirements of the application. The performance of some applications may benefit from static branch prediction, others may not. The +r option provides a hint for using or avoiding this feature. The +gst and related options provide performance enhancements through use of global symbol table which improves searching for exported symbols. See dld.so(5) and the HP-UX Linker and Libraries Online User Guide for more information. To use Format 2, first specify the segment you want to modify by address (with the +sa option) or index (with the +si option), or specify all segments (with the +sall option). Then use the +c, +m, +r, +s, or +z options to modify the segment attributes. You can include more than one segment on the command line as long as you specify each segment with an +sa address or +si index option, followed by the modifying options. Options
Restricting Execute Permission on StacksA frequent or common method of breaking into systems is by maliciously overflowing buffers on a program's stack, such as passing unusually long, carefully chosen command line arguments to a privileged program that does not expect them. Malicious unprivileged users can use this technique to trick a privileged program into starting a superuser shell for them, or to perform similar unauthorized actions. One simple yet highly effective way to reduce the risk from this type of attack is to remove the execute permission from a program's stack pages. This improves system security without sacrificing performance and has no negative effects on the vast majority of legitimate applications. The changes described in this section only affect the very small number of programs that try to execute (or are tricked into executing) instructions located on the program's stack(s). If the stack protection feature described in this section is enabled for a program and that program attempts to execute code from its stack(s), the HP-UX kernel will terminate the program with a SIGKILL signal, display a message referring to this manual page section, and log an error message to the system message log (use dmesg to view the error message). The message logged by the kernel is:
If you see one of these messages, check with the program's owner to determine whether this program is legitimately executing code from its stack. If it is, you can use one or both of the methods described below to make the program functional again. If the program is not legitimately executing code from its stack, you should suspect malicious activity and take appropriate action. HP-UX provides two options to permit legitimate execution from a program's stack(s). Combinations of these two options help make site-specific tradeoffs between security and compatibility. The first method is the use of the +es option of chatr and affects individual programs. It is typically used to specify that a particular binary must be able to execute from its stack, regardless of the system default setting. This allows a restrictive system default while not preventing legitimate programs from executing code on their stack(s). Ideally this option should be set (if needed) by the program's provider, to minimize the need for manual intervention by whomever installs the program. An alternate method is setting the kernel tunable parameter, executable_stack, to set a system-wide default for whether stacks are executable. Setting the executable_stack parameter to 1 (one) with sam (see sam(1M)) tells the HP-UX kernel to allow programs to execute on the program stack(s). Use this setting if compatibility with older releases is more important than security. Setting the executable_stack parameter to 0 (zero), the recommended setting, is appropriate if security is more important than compatibility. This setting significantly improves system security with minimal, if any, negative effects on legitimate applications. Combinations of these settings may be appropriate for many applications. For example, after setting executable_stack to 0, you may find that one or two critical applications no longer work because they have a legitimate need to execute from their stack(s). Programs such as simulators or interpreters that use self-modifying code are examples you might encounter. To obtain the security benefits of a restrictive system default while still letting these specific applications run correctly, set executable_stack to 0, and run chatr +es enable on the specific binaries that need to execute code from their stack(s). These binaries can be easily identified when they are executed, because they will print error messages referring to this manual page. The possible settings for executable_stack are as follows:
The table below summarizes the results from using the possible combinations of chatr +es and executable_stack when executing from the program's stack. Running chatr +es disable relies solely on the setting of the executable_stack kernel tunable parameter when deciding whether or not to grant execute permission for stacks and is equivalent to not having run chatr +es on the binary.
RETURN VALUEchatr returns zero on success. If the command line contents is syntactically incorrect, or one or more of the specified files cannot be acted upon, chatr returns information about the files whose attributes could not be modified. If no files are specified, chatr returns decimal 255. Illegal optionsIf you use an illegal option, chatr returns the number of non-option words present after the first illegal option. The following example returns 4: chatr +b enable +xyz enable +mno enable +pqr enable file Invalid argumentsIf you use an invalid argument with a valid option and you do not specify a file name, chatr returns 0, as in this example: chatr +b <no argument> If you specify a file name (regardless of whether or not the file exists), chatr returns the number of files specified. The following example returns 3: chatr <no argument> file1 file2 file3 Invalid filesIf the command cannot act on any of the files given, it returns the total number of files specified (if some option is specified). Otherwise it returns the number of files upon which it could not act. If a2 does not have read/write permission, the first of the following examples returns 4 and the second returns 1: chatr +b enable a1 a2 a3 a4 chatr a1 a2 a3 a4 EXTERNAL INFLUENCESEnvironment VariablesThe following internationalization variables affect the execution of chatr:
If any internationalization variable contains an invalid setting, chatr behaves as if all internationalization variables are set to C. See environ(5). In addition, the following environment variable affects chatr:
EXAMPLESChange a.out to demand-loaded chatr -q a.out Change binding mode of program file that uses shared libraries to immediate and nonfatal. Also enable usage of SHLIB_PATH environment variable: chatr -B immediate -B nonfatal +s enable a.out Disallow run-time path lookup for the shared library /usr/lib/libc.sl that the shared library libfoo.sl depends on: chatr +l /usr/lib/libc.sl libfoo.sl Given segment index number 5 from a previous run of chatr, change the page size to 4 kilobytes: chatr +si 5 +p 4K average64 To set the modify bit of a specific segment, first find the index or address number of the segment. chatr a.out a.out: 32-bit ELF executable shared library dynamic path search: LD_LIBRARY_PATH enabled first SHLIB_PATH enabled second embedded path enabled third /CLO/TAHOE_BE/usr/lib/hpux32 shared library list: libsin.so libc.so.1 shared library binding: deferred global hash table enabled global hash table size 100 shared library mapped private disabled shared vtable support disabled segments: index type address flags size 5 text 04000000 ----c D (default) 6 data 40000000 ---m- L (largest possible) executable from stack: D (default) kernel assisted branch prediction enabled lazy swap allocation for dynamic segments disabled For Format 2, for a text segment, use the following: chatr +si 5 +m enable a.out or chatr +sa 04000000 +m enable a.out For Format 1, use the following: chatr +mi enable a.out WARNINGSThis release of the chatr command no longer supports the following options:
SEE ALSOMiscellaneous
Texts and Tutorials
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
