| 
 Home
Download
Features
Support
Links
Donations
Sponsors
Books
Research
Papers
Contact
|
[03/22] Website update
Grsecurity development continues: last week I added a feature to the RBAC system which provides functionality equivalent to a BSD jail feature, but with more fine-grained control. Within RBAC policies, you now have the ability to force a given subject to use a specified source IP address when it listens on a port or connects out of the machine.
I've also made some improvements to the website. I've consolidated the download links, improved the test patch page (added a button to subscribe to the test patch RSS feed), and created a new section for support which describes the different ways to get help with grsecurity.
In addition to this, I've created two new links on the side -- "Books" and "Research". The "Books" section provides links to security books that mention grsecurity. Buying these books helps support grsecurity. The "Research" section includes links to PDFs (or abstracts if no PDF was available) for all academic research papers I've been able to find that discuss grsecurity or PaX. If you know of, or are the author of, any academic paper which is missing from my list, please let me know.
|
|
[02/06] Drobo update
|
Last last night (after three weeks of being locked out of years worth of data) I was sent a modified firmware that allowed me to recover all my previously unaccessible data. I've just finished responding to everyone I could find who has emailed me over the past three weeks. If you haven't received a response from me, please send me another email -- it's possible yours was lost in my spam filter.
|
|
[01/25] Drobo failure: when it rains, it pours
Thank you to everyone who has mailed me so far offering support and sponsorship opportunities. Based on the response received, the project will continue development.
On to other business, recently I've been dealing with the loss of a significant amount of data which was supposedly "protected" by a device called Drobo (http://www.drobo.com). A perfectly good drive was marked as failed by the device, and instead of rebuilding from data on the other two drives (since it's supposed to handle single drive "failure"), I've been locked out of my data for nearly two weeks. Due to the proprietary nature of their device, any proper recovery of the data depends on them (it's not a simple RAID5 configuration that can be recovered with third-party tools).
I know there are several emails still needing a response, and I will get to them as soon as I get this whole mess sorted out. Obviously, losing 7 years worth of personal data, backups from the website, old patches, mail archives, etc, is pretty troubling. I'll provide an update based on how the situation progresses.
|
|
[12/27] New (final?) grsecurity release and important announcement
grsecurity 2.1.12 has been released for the 2.4.37 and 2.6.27.10 versions of the Linux kernel.
Changes since 2.1.11 include numerous bugfixes to both grsecurity and PaX. Support for capabilities
introduced in newer 2.6 kernels has been added to the RBAC system. A case where incorrect subject
flags were used in policies generated from learning has been corrected. Handling of corner cases in
vma mirroring has been improved. A new feature has been added to PaX in the 2.6 patch:
PAX_REFCOUNT. This new feature prevents the exploitation of most reference count overflow
vulnerabilities in the kernel. The feature exists for both 32 and 64-bit x86 platforms and is
enabled in the medium and high security settings of grsecurity. Sanity checking has been added at
build time for grsecurity to detect too-common misconfigurations of PaX we've seen mentioned on the
forums. A kernel command line parameter, "pax_nouderef" has been added to selectively disable PaX's
UDEREF feature at boot time.
Requirements/Known Issues:
- Binutils 2.18 is required for this release, as older versions are incompatible with PaX. This requirement is enforced at build time.
- PaX, even when completely disabled, is incompatible with a VirtualBox/VMWare host (it can still be used on a guest OS). The source of the incompatibility is not yet known.
- ATI binary video drivers trigger the UDEREF protection. Whether an exploitable scenario exists within the driver has not been determined.
Due to the current economic situation, grsecurity recently lost its primary sponsor. After
discussing the situation for some time with the PaX team, I have come to two scenarios for the
future of the project. If within the next few months I can find one or more sponsors to get the
project back to its previous level of sponsorship, I'll continue development on the project and keep
up to date with the latest kernels as I've done in the past. If I am unable to find anyone
interested in sponsoring the project, development and availability of the software will end on March
31st. Further public development of PaX will be uncertain.
Sponsoring grsecurity has many benefits:
- I will personally respond to any support requests (you can call me if you wish)
- You are able to make feature requests to improve the usefulness of grsecurity to your organization
Some examples of RBAC features written through this offer included hostname support, invertedsocket policies, virtual interface support, and PAM authentication support
- Upon request, I will review your RBAC policy and report vulnerabilities or make suggestions
- A logo and a link to your organization will be listed on the sponsors page
- Helping continue a project with a circle of influence far outside its own userbase
To illustrate this last point, we've put together a graph that shows how grsecurity and PaX have
influenced security system implementations in nearly every mainstream operating system. Over the
past eight years of our existence, we have not only managed to stay relevant to the current state of
an ever-evolving industry, but have advanced the state of the art and provided real security based
on results and not what was most commercially profitable. The graph is available here.
I'd like to thank all sponsors of grsecurity, past and present, for their help in continuing an important project.
To discuss possible sponsorship, please contact me at spender@grsecurity.net.
|
|
[04/21] grsecurity 2.1.11 patches updated, 2.6.24.5 supported
|
The 2.6 patch has been updated to 2.6.24.5 and fixes a serious RBAC system flaw where user_transition_deny/allow rules were being ignored. Both the 2.4 and the 2.6 patches have been updated to fix the return values of sys_setfsuid and sys_setfsgid.
|
|
[04/17] grsecurity 2.1.11 patch for 2.6.24.4 updated
|
The 2.1.11 patch for Linux 2.6.24.4 has been updated to fix a deadlock scenario with setpgid() and CONFIG_GRKERNSEC_CHROOT_FINDPROC discovered during an internal audit.
|
|
[04/14] grsecurity 2.1.11 released for Linux 2.4.36.2/2.6.24.4
A new stable version of grsecurity has been released for the 2.4.36.2 and 2.6.24.4 versions of the Linux kernel. This release is a maintenance release (due to the work required in porting such a large patchset to each new 2.6 kernel as we have with the test patches), though we continue to welcome suggestions for additional features for grsecurity. Changes in this release include:
- Many bugfixes, including fixes for RBAC auditing and RBAC policy recreation from renaming.
- Relaxed restrictions for the 'd' subject flag in the RBAC system -- a task may now access its own /proc/<pid>/fd and mem entries.
- Forced compiler errors on mistaken PaX configuration (such as enabling PAX_NOEXEC but not enabling SEGMEXEC nor PAGEEXEC).
- Extended username limits in the RBAC system
- Improved policy verification and base policy enforcement
- Added support for new capabilities added in Linux 2.6
- Updated default policy and learning configuration
- Corrected policy support on files larger than 2gb prior to the RBAC system being enabled
- An update to the latest version of PaX which includes numerous bugfixes
Due to Linux kernel developers continuing to silently fix exploitable bugs (in particular, trivially exploitable NULL ptr dereference bugs continue to be fixed without any mention of their security implications) we continue to suggest that the 2.6 kernels be avoided if possible.
It is not clear if the PaX Team will be able to continue supporting future versions of the 2.6 kernels, given their rapid rate of release and the incredible amount of work that goes into porting such a low-level enhancement to the kernel (especially now in view of the reworking of the i386/x86-64 trees). It may be necessary that grsecurity instead track the Ubuntu LTS kernel so that users can have a stable kernel with up-to-date security fixes. I will update this page when a final decision has been reached.
In the meantime, please email pageexec@freemail.hu and let him know how much you appreciate the hard work he has put in for the past 8 years. The accomplishments of the PaX Team have extended far beyond just Linux, and have today found their way into all mainstream operating systems.
|
|
[06/18] Note on PaX support for x86-64 kernels on Socket 478 Celeron D processors
|
The 64-bit Socket 478 Intel Celeron D processors lack NX support unlike other 64bit Intel/AMD chips. PaX currently only utilizes NX on 64bit kernels, but since the mentioned Celeron processors lack NX support, PaX's PAGEEXEC feature, though able to be selected in the kernel configuration, will not be active in the built kernel. Since the specific processor can only be detected at runtime, it's not possible to restrict the PAGEEXEC option in the kernel config. Owners of these CPUs are urged to build 32bit kernels and use SEGMEXEC to make full use of PaX with the smallest performance hit.
|
|
[01/22] Update on PaX expand_stack() vulnerability, updated patches
The recently updated grsecurity patches for 2.4 and 2.6 series kernels fixes the bug mentioned in the recently announced expand_stack() security advisory. To clear up some ambiguities and misleading statements from the advisory, the vulnerability actually does not exist within the expand_stack() function, it applies only to systems with the SEGMEXEC feature enabled (i386 arch only as x86-64 uses PAGEEXEC), and applies to both the 2.4 and 2.6 patches released prior to 01/21.
We are erring on the side of caution and calling this bug exploitable, though we believe reliable exploitation of the bug (in the privilege escalation sense, not the DoS sense) to be very difficult, especially in the presence of KERNEXEC/UDEREF.
Using the RBAC system's PaX flag support to enforce system-wide MPROTECT enabling could have prevented triggering of the bug, since it requires the creation of an executable stack to trigger the vma mirroring bug.
|
|
[01/12] grsecurity 2.1.10 released for Linux 2.4.34/2.6.19.2
grsecurity 2.1.10 was released today for Linux 2.4.34 and 2.6.19.2. Changes in this release include:
- Fixes to PaX flag support in RBAC system
- PaX updates for non-x86 architectures in 2.4.34 patch
- Fix for setpgid in chroot problem reported on forums
- Removal of randomized PIDs feature, since it provides no useful additional security and wastes memory with the 2.6 kernel's pid bitmap
- Fixed /proc usage in a chroot in 2.6 patch
- Added admin role to generated policy from full learning
- Resync of PaX code in 2.4 patch
|
|
[12/15] grsecurity 2.1.9 updated for Linux 2.4.33.4/2.6.19.1
|
grsecurity has been updated for the 2.4.33.4 and 2.6.19.1 Linux kernels. Changes include PaX updates involving the removal of RANDEXEC from the codebase (which had been removed from the configuration for several releases), and x86_64 support for disabling of raw I/O. There have been no changes to gradm.
|
|
[10/07] grsecurity 2.1.9 updated for Linux 2.6.18
|
grsecurity has been updated for the 2.6.18 Linux kernel. Gradm has been updated as well to perform an additional check for bad policies.
|
|
[09/03] grsecurity 2.1.9 updated for Linux 2.4.33.3/2.6.17.11
|
grsecurity 2.1.9 has been updated for the 2.4.33.3 and 2.6.17.11 Linux kernels. Changes include minor PaX changes, stealth module fixes for 2.6, and a change to the patch for the 2.4 Makefile so that each upcoming 2.4.x.y release won't require a new grsecurity patch to patch all files cleanly.
|
|
[08/23] grsecurity 2.1.9 updated for Linux 2.4.33.2/2.6.17.11
|
grsecurity 2.1.9 has been updated for the 2.4.33.2 and 2.6.17.11 kernels. A bug in the 2.4 kernel that caused the kernel not to boot when UDEREF was enabled has been fixed. Other minor changes were made to PaX and gradm.
|
|
[08/13] grsecurity 2.1.9 updated for Linux 2.4.33/2.6.17.8
|
grsecurity 2.1.9 has been updated for the 2.4.33 and 2.6.17.8 Linux kernels. Changes were minor: fix a crash on shutdown with PaX's uderef feature, correct sysctl error code in grsecurity, and fixed compiler warnings in the stealth module on the 2.6 patch.
|
|
|
 |
