diff options
| author |   Seemant Kulleen <seemant@gentoo.org> | 2004-02-11 08:40:49 +0000 |
|---|---|---|
| committer | Seemant Kulleen <seemant@gentoo.org> | 2004-02-11 08:40:49 +0000 |
| commit | f67557ba714fb5826240256ffc5eea3f29f6a3dc (patch) | |
| tree | 9816b3b176b0af241ff59d1042c3c4221d27ac37 /xml | |
| parent | some minor corrections (diff) | |
| download | gentoo-f67557ba714fb5826240256ffc5eea3f29f6a3dc.tar.gz gentoo-f67557ba714fb5826240256ffc5eea3f29f6a3dc.tar.bz2 gentoo-f67557ba714fb5826240256ffc5eea3f29f6a3dc.zip | |
extensive corrections
Diffstat (limited to 'xml')
| -rw-r--r-- | xml/htdocs/proj/en/hardened/grsecurity.xml | 164 |
1 files changed, 82 insertions, 82 deletions
diff --git a/xml/htdocs/proj/en/hardened/grsecurity.xml b/xml/htdocs/proj/en/hardened/grsecurity.xml index 9397560214..0e26190712 100644 --- a/xml/htdocs/proj/en/hardened/grsecurity.xml +++ b/xml/htdocs/proj/en/hardened/grsecurity.xml @@ -93,7 +93,7 @@ syntax! <p> grSecurity also has better chroot restrictions, improved protection against buffer exploits, a tight address space protection scheme (PaX), -improved auditing possibilities, randomisation-improvements for the +improved auditing possibilities, randomization-improvements for the TCP/IP-stack and PIDs, <path>/proc</path> restrictions, ... </p> @@ -127,7 +127,7 @@ link="/doc/en/prelink-howto.xml">Prelink HOWTO</uri> for more details. <body> <p> -Since grSecurity is a kernelpatch, you need to install, configure and +Since grSecurity is a kernel patch, you need to install, configure and use a Linux kernel with the grSecurity patch in it. On Gentoo, several kernel-ebuilds provide grSecurity. You can choose between <c>grsec-sources</c>, <c>gentoo-sources</c>, <c>hardened-sources</c> and <c>xfs-sources</c>. @@ -143,13 +143,13 @@ or </pre> <note> - grsec-sources is simply vanilla-sources with grsecurity patch added, + grsec-sources is simply vanilla-sources with grSecurity patch added, but should always be the most up-to-date version of the kernel and patch. - Also note that when merging grsec-sources the version you get depends on + Also note that when emerging grsec-sources the version you get depends on your arch keywords, thus if you are using x86 you will get grsec-sources stable version and when using ~arch keywords you will get the - development versions of the next generation of grsecurity. + development versions of the next generation of grSecurity. </note> <p> Now wasn't that easy ? :) </p> @@ -172,13 +172,13 @@ you know everything works as expected. </p> <pre caption="Configuring the kernel"> -<codenote>Make sure /usr/src/linux points to the correct sourcetree</codenote> +<codenote>Make sure /usr/src/linux points to the correct source tree</codenote> # <i>cd /usr/src/linux</i> # <i>make menuconfig</i> </pre> <p> -You'll notice that there are 2 new sections in comparison with the +You will notice that there are two new sections in comparison with the vanilla kernel: <i>Cryptography support (CryptoAPI)</i> and <i>Grsecurity</i>. In this document, we will only talk about the latter section. @@ -210,19 +210,19 @@ step. <body> <p> -Lots of exploits and known disfunctionalities are based on how the Linux -kernel handles memory. The Address Space is the first 3 Gb of the +Lots of exploits and known malfunctions are based on the Linux +kernel's memory handling. The Address Space is the first 3 GB of the virtual memory that Linux can address, and is solely used for applications. Protecting this area is one of the most important tasks of the grSecurity patches. </p> <p> -Linux per default doesn't know about executables pages: if a page is -readable, it is executable. Because of this flaw known exploits +By default, Linux doesn't know about executable pages: if a page is +readable, it is executable. Because of this flaw, known exploits can inject executable code in memory regions which shouldn't really be executable. If you select <c>Enforce non-executable pages</c> you receive -some new features who fix this implementation. However, do note that +some new features which fix this implementation. However, do note that some tools assume that memory assignment functions return executable memory (which they should not). </p> @@ -240,27 +240,27 @@ There are 2 implementations available: <ul> <li> <c>Paging based non-executable pages</c> is an implementation based -on the paging features of the CPU. There is however variable performance +on the paging features of the CPU. There is, however, some variable performance impact on the ix86 architecture, so you should carefully test your applications before using this. </li> <li> <c>Segmentation based non-executable pages</c> has little performance -impact, but will split the address space in 2, meaning that applications -will only have a 1.5 Gb address space instead of the normal 3 Gb. +impact, but will split the address space into two, giving applications +only a 1.5 GB address space instead of the normal 3 GB. </li> </ul> <p> -Some tools require to execute very small snippets of code from a +Some applications need to execute small snippets of code from a non-executable memory page; activating any of the above implementations will break these tools (some parts of <c>gcc</c> and the Linux kernel use this). If you activate <c>Emulate trampolines</c> then you can use <c>chpax</c> to enable the trampoline emulation for these programs without losing the protection provided by any of the above -implementations. If you don't select this, you can still use those tools -if you disable any of the above implementations using <c>chpax</c>. -</p> +implementations. If you don't select this, but have disabled any of the +above implementations, you can still use <c>chpax</c> to make your +applications work. <p> If you select <c>Restrict mprotect()</c>, programs will not be able to @@ -273,9 +273,9 @@ comes to the rescue if you want to control this on a per file basis. There are still "loopholes" in which attackers can execute malicious code. Activating <c>Disallow ELF text relocations</c> will force your system to use PIC (<e>Position Independent Code</e>) ELF libraries only. -If you are confident that your system only uses PIC ELF libraries (which -is most of the time <e>not</e> the case) you can activate this feature. -Note that you cannot use <c>prelink</c> on those systems. +If you are confident that your system only uses PIC ELF libraries (be warned +that most of the time, this is <e>NOT</e> the case) you can activate this +feature. Note that you cannot use <c>prelink</c> on those systems. </p> <p> @@ -283,12 +283,12 @@ Many exploits are only effective if they know the exact return addresses in the attacked program. Activating <c>Address Space Layout Randomization</c> will give you the following algorithms that randomize the memory addresses. With this activated, the exploits will most likely -just crash the application, which you can catch and react upon. +just crash the application, which you can then catch and react upon. </p> <ul> <li> -<c>Randomize kernel stack base</c> will randomize's every task's kernel +<c>Randomize kernel stack base</c> will randomize every task's kernel stack on every system call. This can however lead to unexpected stack overflows, so test it first. You cannot use this on a per file basis. </li> @@ -305,7 +305,7 @@ code for his purposes. This randomization is also true for dynamic ELF files. You can control this using <c>chpax</c> on a per file basis. If you select <c>Randomize ET_EXEC base</c> too, then normal ELF executables will also have a randomized base address. This will cause -performance degradation though, so this should be used as a transistion +performance degradation though, so this should be used as a transition solution until all programs are relinked as dynamic ELF files. </li> </ul> @@ -319,15 +319,15 @@ the accompanying "< Help >". </p> <p> -To disable the possibility for tools to modify the running kernel (using +To disable the possibility for applications to modify the running kernel (using ioperm and iopl calls) you should select <c>Disable privileged I/O</c>. -There are some tools who need this, such as (again) <c>xfree</c>. +There are some tools which need this, such as (again) <c>xfree</c>. </p> <p> -If you use one of the randomisation algorithms for address space layout, +If you use one of the randomization algorithms for address space layout, you <e>must</e> select <c>Remove addresses from /proc/pid/maps</c>, as -this would otherwise make the randomisation useless. +this would otherwise make the randomization useless. </p> <p> @@ -346,7 +346,7 @@ like the kernel image and <path>System.map</path> and remove <p> Here you can configure a small set of general ACL options, namely hiding -kernelprocesses, setting the maximum tries before (ACL) password lockout and +kernel processes, setting the maximum tries before (ACL) password lockout and the time to wait after the maximum (ACL) password failures. </p> @@ -364,7 +364,7 @@ a very important part. <p> The <path>/proc</path> filesystem is a big source of information and -sometimes subject of exploits. By selecting <c>Proc restrictions</c> you +sometimes the subject of exploits. By selecting <c>Proc restrictions</c> you can choose any of the following restrictions: </p> @@ -372,11 +372,11 @@ can choose any of the following restrictions: <li> <c>Restrict to user only</c> will make sure users can only view information about their own processes and will not be able to read -network- and kernelrelated information. +network and kernel related information. </li> <li> -<c>Additional restrictions</c> will also hide cpu- and -device-information. +<c>Additional restrictions</c> will also hide CPU and +device information. </li> </ul> @@ -395,7 +395,7 @@ FIFO or directory). You can control this setting with a sysctl option. <p> If you use chroot-jails on your system, enabling the <c>Chroot jail -restrictions</c> would be a good action. It will give you the choice of +restrictions</c> would be a good choice. It will give you the option of activating several chroot restrictions. All choices can be controlled by setting the appropriate sysctl option. </p> @@ -473,14 +473,14 @@ If you use sysctl, you need to echo this GID into the proper <body> <p> -The default Linux TCP/IP-stack has some properties that makes it more -vulnerable to prediction-based hacks. By randomizing several items +The default Linux TCP/IP-stack has some properties that make it more +vulnerable to prediction-based hacks. By randomizing several items, predicting the behaviour will be a <e>lot</e> more difficult. All -options can be controlled through their respective sysctl option. +options can be controlled through their respective sysctl options. </p> <p> -<c>Larger entropy pools</c> doubles the poolsize. This is recommended if +<c>Larger entropy pools</c> doubles the pool size. This is recommended if you use any other options here. </p> @@ -542,7 +542,7 @@ able to run server applications from your machine. With this selected, you will be able to activate or deactivate grSecurity options on the fly on your running system without having to recompile your kernel. However, this does require you to be extra -carefull with what you do, since this feature reduces the effectiveness +careful with what you do, since this feature reduces the effectiveness of the added security if there is no ACL system in place. </p> @@ -553,7 +553,7 @@ of the added security if there is no ACL system in place. <body> <p> -In this section you can limit how fast and how much messages the +In this section you can limit how fast and how many messages the kernel will generate in a certain timeframe. </p> @@ -564,14 +564,14 @@ kernel will generate in a certain timeframe. <chapter> <title>ACL Configuration and Specification</title> <section> -<title>With all the above, why do we still need ACLs?</title> +<title>With all of the above, why do we still need ACLs?</title> <body> <p> First of all, ACLs provide you with greater flexibility and more -control, even if you don't use the sysctl optoins. Perhaps you aren't -convinced now, but after reading the following sections, I'm sure you -will be :) +control, even if you do not use the sysctl options. You may not be +convinced now, but after reading the following sections, you just might +be. :) </p> <p> @@ -581,7 +581,7 @@ Otherwise an attacker can simply deactivate all protections we provide. <warn> You <e>must</e> make sure that all initscripts are read-only and that -root doesn't have access to adding modules or performing raw i/o +root doesn't have the priveleges to add modules or perform raw I/O operations. All sysctl options must be set at startup, and after setting all these options, the grsec_lock entry <e>must</e> be activated. </warn> @@ -644,7 +644,7 @@ next to the restrictions you entered for "<path>/usr/bin/sendmail</path>". <p> If a subject has object restrictions which are also restricted by a -parent ACL structure, then the restriction of the first subject have +parent ACL structure, then the restriction of the first subject has a higher priority than the inherited restrictions on those objects. </p> @@ -678,7 +678,7 @@ PaX on this subject</ti></tr> <tr><ti>X</ti><ti>ENABLES the RANDEXEC (Randomize ET_EXEC base) feature of PaX on this subject</ti></tr> <tr><ti>O</ti><ti>Override the mmap() and ptrace() checks for this subject</ti></tr> -<tr><ti>A</ti><ti>Protect the shared memory of this subject. No other processes but processes contained within this subject may access the shared memory of this subject.</ti></tr> +<tr><ti>A</ti><ti>Protect the shared memory of this subject. None except the processes contained within this subject may access the shared memory of this subject.</ti></tr> <tr><ti>K</ti><ti>When processes belonging to this subject generate an alert, kill the process</ti></tr> <tr><ti>C</ti><ti>When processes belonging to this subject generate an alert, kill the process and all processes belonging to the IP of the attacker (if there was an IP attached to the process)</ti></tr> <tr><ti>T</ti><ti>Ensures this process can never execute any trojaned code</ti></tr> @@ -697,7 +697,7 @@ The following table explains the possible object modes. <table> <tr><th>Mode</th><th>Description</th></tr> -<tr><ti>r</ti><ti>This object can be opened for reading. This is default +<tr><ti>r</ti><ti>This object can be opened for reading. This is the default if no flags are given.</ti></tr> <tr><ti>w</ti><ti>This object can be opened for writing or appending.</ti></tr> <tr><ti>x</ti><ti>This object can be executed (or mmapd with PROT_EXEC into a task).</ti></tr> @@ -722,9 +722,9 @@ if no flags are given.</ti></tr> On every event, the kernel will check the ACLs for the executed process (and <e>if</e> that isn't available <e>or</e> it inherits permissions, it will check the ACLs for the directory that process is located in -and so on untill it reaches the ACL for <path>/</path>) and the requested +and so on until it reaches the ACL for <path>/</path>) and the requested object (or the parent ACLs if there is no ACL for the object). Only if -both ACLs allow the event it will be executed. +both ACLs allow the event will it be executed. </p> </body> @@ -754,9 +754,9 @@ the following resource definitions: </table> <p> -After the system resource you must define 2 values. The first one is the +After the system resource you must define two values. The first one is the "soft limit", meaning that the user running that process will receive a -warning that he has crossed the resource limit. The second one is the +warning that the resource limit has been crossed. The second one is the "hard limit", which is the actual enforced limit. </p> @@ -771,7 +771,7 @@ warning that he has crossed the resource limit. The second one is the <p> You have to define a default ACL for your system first. The following -can be used as default ACL: +can be used as a default ACL: </p> <pre caption = "Default ACL: /"> @@ -837,10 +837,10 @@ can be used as default ACL: </pre> <p> -The reason that a default ACL is needed is because of the forementioned -inheritance. Note that permissions on an ACL system is controlled both +The reason that a default ACL is needed is because of the aforementioned +inheritance. Note that permissions on an ACL system are controlled both by the ACL on an object <e>and</e> the DAC (Discretionary Access -Control) permission (rwxrwxrwx). Only if both systems agree access is +Control) permission (rwxrwxrwx). Only if both systems agree is access granted. </p> @@ -969,14 +969,14 @@ obvious reasons. </p> <p> -We also allow <c>apache</c> to connect to a DNS server, and bind to 2 +We also allow <c>apache</c> to connect to a DNS server, and to bind to 2 ports: 80 (http) and 443 (https). </p> <p> You can see that the subject mode is different from <c>init</c>'s: <c>oXA</c>. This means that we override the default ACL, enable the -RANDEXEC feature of PaX and restrict the use of it's shared memory to +RANDEXEC feature of PaX and restrict the use of its shared memory to objects described in this ACL. </p> @@ -1057,7 +1057,7 @@ system. Luckily for you there is a learning mode in grSecurity. <p> In the learning mode grSecurity will audit everything a certain process does, and log it into a temporary ACL. Afterwards, you can dump it -into an ACL file and, if necessary, make further adjustements. +into an ACL file and, if necessary, make further adjustments. </p> <p> @@ -1092,12 +1092,12 @@ single process while the rest of the system remains protected as usual. </p> <p> -To enable process-base learning mode on a subject we would first need to -add it to our ACL system. +To enable process-base learning mode on a subject you first need to +add it to your ACL system. </p> <note> -We can change the flags on an ACL at any given time when we are in admin +You can change the flags on an ACL at any given time when you are in admin mode. </note> @@ -1153,7 +1153,7 @@ A more restrictive ACL for learning mode might look like this: </pre> <p> -Now we reload the grSecurity ACL system with <c>gradmn</c>. +Now you reload the grSecurity ACL system with <c>gradmn</c>. </p> <pre caption = "Reloading the ACL system"> @@ -1163,9 +1163,9 @@ Now we reload the grSecurity ACL system with <c>gradmn</c>. <p> You should now use this application as thouroughly as possible, since the learning mode uses a threshold-based system to determine the ACLs. -If the application is something that uses authentification you should +If the application is something that uses authentication you should log on/off to that service which will cause it to do its necessary -authentification calls. +authentication calls. </p> <p> @@ -1192,7 +1192,7 @@ repeated about 4 times. <p> When you think the tool has been run long enough, go in admin mode with <c>gradm -a</c> (or disable the ACL system with <c>gradm -D</c>) and dump -the ACLs into a file. The following will append the new learned ACLs to +the ACLs into a file. The following will append the newly learned ACLs to <path>output.acl</path>. </p> @@ -1202,7 +1202,7 @@ the ACLs into a file. The following will append the new learned ACLs to </pre> <p> -You should read the proposed ACL thouroughly and make changes if deemed +You should read the proposed ACL thoroughly and make the changes you deem necessary. If you know your service will be doing name service lookups you might want to add the following to the final ACLs result. </p> @@ -1226,7 +1226,7 @@ you might want to add the following to the final ACLs result. <p> With sysctl, you can "talk" to the kernel by inserting values in files provided by <path>/proc</path>, or with the <c>sysctl</c> command. It -provides you with a flexible way to change kernelvariables on the fly +provides you with a flexible way to change kernel variables on the fly without the need for recompiling and rebooting a kernel. </p> @@ -1237,13 +1237,13 @@ without the need for recompiling and rebooting a kernel. <body> <p> -As you read previously, several grSecurity options can be enabled/disabled -on the fly using sysctl. There are 4 ways in which you can change the -sysctl variables. +As has been mentioned previously, several grSecurity options can be +enabled and disabled on the fly using sysctl. There are four ways in which +you can change the sysctl variables. </p> <p> -The first one is hardcoding the values in <path>/etc/sysctl.conf</path>, +The first one is hardcoding the values into <path>/etc/sysctl.conf</path>, using the following syntax: </p> @@ -1253,7 +1253,7 @@ place.of.the.variable = value </pre> <p> -For instance, to deny using pivotroot in chrootjails, you would set +For instance, to deny using pivotroot in chroot jails, you would set the following: </p> @@ -1285,7 +1285,7 @@ you can use: </pre> <p> -The fourth way is by <c>echo</c>'ing the variable's value into the +The fourth way is by <c>echo</c>ing the variable's value into the appropriate file in <path>/proc/sys</path>. For instance, to restrict the usage of <c>dmesg</c>: </p> @@ -1304,7 +1304,7 @@ usage of <c>dmesg</c>: <body> <p> -Now that you know how to write or change ACLs, it is time to install the +Now that you know how to write and change ACLs, it is time to install the Gentoo ACLs on your system. Don't forget to use a kernel with grSecurity compiled-in! </p> @@ -1378,7 +1378,7 @@ Password written in /etc/grsec/pw. <p> To lock the grSecurity options, you should set <c>kernel.grsecurity.lock = 1</c>. However, this is a <e>lock</e> in the -pure meaning of it's word. If you activate it, you <e>won't</e> be able +pure meaning of its word. If you activate it, you <e>won't</e> be able to make changes to the ACL system (<e>including</e> activating, restarting or shutting down) or grSecurity options. So you <e>must</e> activate the ACL system <e>before</e> setting the lock. @@ -1425,17 +1425,17 @@ file owner ID must be equal to the user ID, except where CAP_FSETID is applicable. It doesn't override MAC and DAC restrictions. 04. CAP_FSETID -Overrides the following restrictions, that the effective user ID shall -match the file owner ID, when setting the S_ISUID and S_ISGID bits on +Overrides the following restrictions that the effective user ID shall +match the file owner ID when setting the S_ISUID and S_ISGID bits on that file; that the effective group ID (or one of the supplementary group IDs) shall match the file owner ID when setting the S_ISGID bit on that file; that the S_ISUID and S_ISGID bits are cleared on successful return from chown(2) (not implemented). 05. CAP_KILL -Overrides the restriction, that the real or effective user ID of a -process, sending a signal, must match the real or effective user ID -of the process, receiving the signal. +Overrides the restriction that the real or effective user ID of a +process sending a signal must match the real or effective user ID +of the process receiving the signal. 06. CAP_SETGID Allows setgid(2) manipulation; |