I don't think a claim like "you are probably not fit to discuss kernel security" is out of place here. While it's certainly not polite, sometimes you have to forcefully push a point across. When someone is so unfamiliar with a given technology, but speaks with such an air of familiarity, merely saying they are wrong and trying to explain why tends not to work. They will interpret it as an invitation to an argument where their point actually holds a basis. In a case like this, that's not true, and they must be told in some way that they are *completely* wrong forcefully enough that they are taken aback and actually think for a second why they are making the claims they are making.
While obviously personal experience is just an anecdote in this instance, I will say that people being quite forceful has helped me greatly. I use to be somewhat of a script kiddie, very inexperienced and very arrogant. If it weren't for enough security folk telling me I was completely full of shit, I likely would still be like that today, convinced I understood what I was talking about. But because they shook me out of that delusion, I stepped back and realized I may really be ignorant, and I took steps to learn and improve my own understanding.
I won't argue more about this, as it's a fairly common debate in the FOSS community. There are plenty of resources explaining arguments both for and against such forceful language, mostly as a result of people questioning or defending Linus' methods for telling people they are wrong and to stop wasting his time.
I do think however that a better/more complete explanation should have been given. I'll try to help explain for the OP of this thread:
>The problem that I have with the want to add more code (GRSecurity keeps coming back) is that it is basically obfuscation. grsecurity is not about obfuscation. Security through obscurity (which is implied by obfuscation) is defined as security which is based on the implementation being secret. The fact that grsecurity is open source does not give a significant advantage to attackers, since it relies on randomization (which is no more obfuscation or obscurity than a strong symmetric cipher like AES is). Here are a few examples: - UDEREF: Many exploits rely on putting executable code in userland, and tricking the kernel into following a pointer there and executing it in kernelspace (the highest privilege level in the traditional 3 ring system), as if it were part of the kernel itself. You can think of this like a mere civilian writing fake presidential orders, and tricking a member of the federal government into reading and believing those orders. UDEREF completely mitigates this problem, on i386 by separating ring 3 and ring 0 code into their own discrete areas of memory. This ensures that no matter what, you cannot trick the kernel into dererferencing a pointer to userland while in kernelmode. - RANDSTACK: Puts all structures of certain types into a randomized order. This forces an attacker to guess the locations, and even a single failure results in the attack being detected and crashing the kernel. This is not obfuscation because the randomization is based on "real" entropy collected by the system. If you do not know the seed, you will not have any way to know the order of these structures such that you can exploit them. - PaX ASLR: Basically the same as normal ASLR, but resistant to entropy exhaustion, and it randomizes more structures in a process (such as the kernel stack). This, like ASLR, will completely mitigate many exploit classes like ROP. Note that in the case of ASLR, infoleaks are not uncommon, so ROP is only killed so long as the ASLR holds strong. Plugins that may be released in the future such as RAP can completely mitigate ROP without depending on ASLR. - STACKLEAK and SANITIZE: Cleans many structures in the kernel stack as it transitions back to userspace. This ensures that those in-kernel structures cannot be leaked to the process, even if such a leak could normally be triggered. It simply removes these structures. If they are not there, an attacking process cannot read them. That is not obfuscation, it is removal of sensitive data. - CONSTIFY: Sets variables which are not going to be changed to "const", which prevents them from being modified. This is not obfuscation because an attacker can easily know which variables are const, but knowing that does not let them modify them. For example, structs related to whether or not various LSMs are enabled can be made read-only. That way an attacker cannot simply toggle selinux_enabled to 0, because it simply cannot be written to. The knowledge that it cannot be written to does not give them any advantage. Note that I may be mixing this example up with another feature of grsecurity, but it still applies. - Security backports: Not many people realize that grsecurity isn't just proactive defense mechanisms, but also includes numerous security backports. Unfortunately, the kernel team seems to fix exploitable bugs without a clear "this is a security issue" commit message for distribution kernel maintainers to read. As a result, many exploitable bugs remain in popular distribution kernels, and the amount of effort required to find and patch the bugs is unnecessarily duplicated. People are told "just use the most recent kernels", but that is obviously not practical (and often comes with security issues on its own). grsecurity contains these backported fixes, so you can be sure that exploitable bugs are far less likely to be present in a grsecurity kernel. - Miscellaneous changes: Many kernel behaviors are harmful to security, due to increasing attack surface area or leaking sensitive information. grsecurity often fixes these by disabling them, or requiring higher privileges to access. For example, the kcmp() system call is completely disabled in grsecurity, because it allows processes to gain information about the current state of the kernel. Ironically, kcmp() actually does attempt obfuscation to reduce the impact of infoleaks, but it is woefully ineffective. This is not documented as far as I can tell, except for in the source code. The perf_event_open() syscall is limited to CAP_SYS_ADMIN only, because it has a history of severe vulnerabilities, and has multiple unpatched issues which enable side-channel attacks (such as gaining password information via context switch counts). Another example is the bpf() syscall, which is additionally disabled under grsecurity, but in the future may be made accessible to processes with CAP_SYS_ADMIN.
There are many, many more which I have not described, and likely further which I simply do not yet know about. If I made any mistakes, I hope someone will correct me. I'm sure reading through some of the documentation can explain far better than I can. Here's a neat PDF on some kernel-self protections in grsecurity and PaX which are totally unrelated to obfuscation: https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-self-protection.pdf
>People don't generally understand file permissions, yet we add SELinux and practically no one understands that, so we add more stuff like containers, vms over the top. SELinux is infamous for being hard to understand, yet there are many premade policies. However, other MAC (Mandatory Access Control) frameworks are much easier to understand, such as AppArmor, TOMOYO, and SMACK. As for containers, those are designed for very low resource pseudo-virtualization. As for VMs, those are not meant for security either. They are not a replacement for a MAC framework, they are used to allow you to utilize multiple untrusted systems on a single piece of hardware, or to snoop on the internals of a running operating system without slow and difficult to use technologies such as JTAG (a type of connection to a CPU which allows for controlling it like a puppet, for very low-level debugging).
>If we can't build a secure system using the simple UNIX chmod features without making mistakes, what is the probability that the more complicated systems will be better? Simple UNIX permissions (called DAC, for Discretionary Access Controls) is actually quite solid. It has not had a major bug in a very very long time. The only issue with it is it is not complicated enough to provide sufficiently fine-grained protections. Furthermore, grsecurity is not something which requires advanced configuration, with the exception of the optional grsecurity RBAC framework it provides. However even this framework has many sanity checks to ensure you *do* use it right and cannot make big mistakes in configuration. The rest of grsecurity just works out of the box. Also, grsecurity *does* extend the ability of DAC to protect a system, with a feature called TPE (Trusted Path Execution), which prevents a user from accidentally or intentionally allowing another user to place executable code in its path.
Please educate yourself on how systems can be made more secure. It is not just about code correctness, it is about defense in depth such that even in the case of existing exploitable situations, no compromise can occur. I suggest you read up on the basics of ASLR (Address Space Layout Randomization), NX (No-Execute, also called DEP on Windows), SSP (Stack Smashing Protection), RELRO (Read-only Relocations), Bind-Now, etc. These are all popular protections that do not require grsecurity, but can be thought of as inferior implications of many grsecurity features. These features are easy to understand. From this, you can delve into more complicated stuff, such as the mitigations grsecurity provides. Until then, please realize that you will likely be called out for making major mistakes regarding existing security technologies.
tl;dr grsecurity is not obfuscation and OP doesn't know what he's talking about
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: IMO you can't solve security by adding more stuff
Date: 2015-11-23 04:14 am (UTC)While obviously personal experience is just an anecdote in this instance, I will say that people being quite forceful has helped me greatly. I use to be somewhat of a script kiddie, very inexperienced and very arrogant. If it weren't for enough security folk telling me I was completely full of shit, I likely would still be like that today, convinced I understood what I was talking about. But because they shook me out of that delusion, I stepped back and realized I may really be ignorant, and I took steps to learn and improve my own understanding.
I won't argue more about this, as it's a fairly common debate in the FOSS community. There are plenty of resources explaining arguments both for and against such forceful language, mostly as a result of people questioning or defending Linus' methods for telling people they are wrong and to stop wasting his time.
I do think however that a better/more complete explanation should have been given. I'll try to help explain for the OP of this thread:
>The problem that I have with the want to add more code (GRSecurity keeps coming back) is that it is basically obfuscation.
grsecurity is not about obfuscation. Security through obscurity (which is implied by obfuscation) is defined as security which is based on the implementation being secret. The fact that grsecurity is open source does not give a significant advantage to attackers, since it relies on randomization (which is no more obfuscation or obscurity than a strong symmetric cipher like AES is). Here are a few examples:
- UDEREF: Many exploits rely on putting executable code in userland, and tricking the kernel into following a pointer there and executing it in kernelspace (the highest privilege level in the traditional 3 ring system), as if it were part of the kernel itself. You can think of this like a mere civilian writing fake presidential orders, and tricking a member of the federal government into reading and believing those orders. UDEREF completely mitigates this problem, on i386 by separating ring 3 and ring 0 code into their own discrete areas of memory. This ensures that no matter what, you cannot trick the kernel into dererferencing a pointer to userland while in kernelmode.
- RANDSTACK: Puts all structures of certain types into a randomized order. This forces an attacker to guess the locations, and even a single failure results in the attack being detected and crashing the kernel. This is not obfuscation because the randomization is based on "real" entropy collected by the system. If you do not know the seed, you will not have any way to know the order of these structures such that you can exploit them.
- PaX ASLR: Basically the same as normal ASLR, but resistant to entropy exhaustion, and it randomizes more structures in a process (such as the kernel stack). This, like ASLR, will completely mitigate many exploit classes like ROP. Note that in the case of ASLR, infoleaks are not uncommon, so ROP is only killed so long as the ASLR holds strong. Plugins that may be released in the future such as RAP can completely mitigate ROP without depending on ASLR.
- STACKLEAK and SANITIZE: Cleans many structures in the kernel stack as it transitions back to userspace. This ensures that those in-kernel structures cannot be leaked to the process, even if such a leak could normally be triggered. It simply removes these structures. If they are not there, an attacking process cannot read them. That is not obfuscation, it is removal of sensitive data.
- CONSTIFY: Sets variables which are not going to be changed to "const", which prevents them from being modified. This is not obfuscation because an attacker can easily know which variables are const, but knowing that does not let them modify them. For example, structs related to whether or not various LSMs are enabled can be made read-only. That way an attacker cannot simply toggle selinux_enabled to 0, because it simply cannot be written to. The knowledge that it cannot be written to does not give them any advantage. Note that I may be mixing this example up with another feature of grsecurity, but it still applies.
- Security backports: Not many people realize that grsecurity isn't just proactive defense mechanisms, but also includes numerous security backports. Unfortunately, the kernel team seems to fix exploitable bugs without a clear "this is a security issue" commit message for distribution kernel maintainers to read. As a result, many exploitable bugs remain in popular distribution kernels, and the amount of effort required to find and patch the bugs is unnecessarily duplicated. People are told "just use the most recent kernels", but that is obviously not practical (and often comes with security issues on its own). grsecurity contains these backported fixes, so you can be sure that exploitable bugs are far less likely to be present in a grsecurity kernel.
- Miscellaneous changes: Many kernel behaviors are harmful to security, due to increasing attack surface area or leaking sensitive information. grsecurity often fixes these by disabling them, or requiring higher privileges to access. For example, the kcmp() system call is completely disabled in grsecurity, because it allows processes to gain information about the current state of the kernel. Ironically, kcmp() actually does attempt obfuscation to reduce the impact of infoleaks, but it is woefully ineffective. This is not documented as far as I can tell, except for in the source code. The perf_event_open() syscall is limited to CAP_SYS_ADMIN only, because it has a history of severe vulnerabilities, and has multiple unpatched issues which enable side-channel attacks (such as gaining password information via context switch counts). Another example is the bpf() syscall, which is additionally disabled under grsecurity, but in the future may be made accessible to processes with CAP_SYS_ADMIN.
There are many, many more which I have not described, and likely further which I simply do not yet know about. If I made any mistakes, I hope someone will correct me. I'm sure reading through some of the documentation can explain far better than I can. Here's a neat PDF on some kernel-self protections in grsecurity and PaX which are totally unrelated to obfuscation: https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-self-protection.pdf
>People don't generally understand file permissions, yet we add SELinux and practically no one understands that, so we add more stuff like containers, vms over the top.
SELinux is infamous for being hard to understand, yet there are many premade policies. However, other MAC (Mandatory Access Control) frameworks are much easier to understand, such as AppArmor, TOMOYO, and SMACK. As for containers, those are designed for very low resource pseudo-virtualization. As for VMs, those are not meant for security either. They are not a replacement for a MAC framework, they are used to allow you to utilize multiple untrusted systems on a single piece of hardware, or to snoop on the internals of a running operating system without slow and difficult to use technologies such as JTAG (a type of connection to a CPU which allows for controlling it like a puppet, for very low-level debugging).
>If we can't build a secure system using the simple UNIX chmod features without making mistakes, what is the probability that the more complicated systems will be better?
Simple UNIX permissions (called DAC, for Discretionary Access Controls) is actually quite solid. It has not had a major bug in a very very long time. The only issue with it is it is not complicated enough to provide sufficiently fine-grained protections. Furthermore, grsecurity is not something which requires advanced configuration, with the exception of the optional grsecurity RBAC framework it provides. However even this framework has many sanity checks to ensure you *do* use it right and cannot make big mistakes in configuration. The rest of grsecurity just works out of the box. Also, grsecurity *does* extend the ability of DAC to protect a system, with a feature called TPE (Trusted Path Execution), which prevents a user from accidentally or intentionally allowing another user to place executable code in its path.
Please educate yourself on how systems can be made more secure. It is not just about code correctness, it is about defense in depth such that even in the case of existing exploitable situations, no compromise can occur. I suggest you read up on the basics of ASLR (Address Space Layout Randomization), NX (No-Execute, also called DEP on Windows), SSP (Stack Smashing Protection), RELRO (Read-only Relocations), Bind-Now, etc. These are all popular protections that do not require grsecurity, but can be thought of as inferior implications of many grsecurity features. These features are easy to understand. From this, you can delve into more complicated stuff, such as the mitigations grsecurity provides. Until then, please realize that you will likely be called out for making major mistakes regarding existing security technologies.
tl;dr grsecurity is not obfuscation and OP doesn't know what he's talking about