[grsec] Development/documentation update

[Brad Spengler]

Hi all,

The PaX Team and I have been rapidly developing new features for PaX and 
grsecurity for the past many months. Though many of the new features 
won't be news to those of you following the test releases (which I hope 
is most of you), I thought it would be good to provide a summary of what 
we've been working on recently.

One of the things I've been working on recently has been documenting the 
various aspects of grsecurity, including the RBAC system. I've built off 
the great Wikibook a grsecurity user, Meev0, spent a great deal of time 
creating. The Wikibook is available at: 
http://en.wikibooks.org/wiki/Grsecurity. Contained in the Wiki is notes 
on proper bug reports, extensive listings of RBAC features, explanations 
of policy syntax, policy writing suggestions, how to use the learning 
mode, etc. I encourage everyone to contribute to the Wiki in areas where 
the content is currently lacking.

Most recently, the PaX Team and myself have been able to improve on some 
work we did several years ago -- porting grsecurity/PaX features to a 
number of different architectures. With sponsorship returning to normal 
levels, I've been able to purchase hardware for some architectures we 
supported fully some years ago (but haven't been able to since because 
the machines died). I've replaced a dead PowerMAC G3 (ppc32) with a 
PowerMAC G5 (ppc64). I've also been able to acquire a recent ARM 
development board, so expect to see grsecurity and PaX coming to your 
cell phone or other embedded devices soon (MIPS-based embedded devices 
too as soon as I'm able to obtain a suitable development board). The 
grsecurity webserver (currently a 333mhz sparc64 server) will be 
upgraded shortly as well (I'll send out another email before the 
changeover occurs).

So far, with the new hardware and a couple days of extensive work, we 
have:

    * Fixed PAGEEXEC support in 2.6 kernels on sparc32/sparc64/ppc32/ppc64

    * Updated EMUPLT to support recent versions of glibc (this is a 
      non-x86 feature)

    * Added USERCOPY (a feature I developed that I'll discuss below) to 
      sparc32/sparc64/ppc32/ppc64

    * Added REFCOUNT to sparc64 (thanks to twiz for his great help with this)

    * Added NOELFRELOCS support to ppc64

    * Removed mmap_min_addr for the sparc architecture, as it's 
      unnecessary (the sparc architecture catches invalid userland 
      accesses, unlike some other architectures) and can break 
      applications if configured improperly


Aside from non-x86 improvements to our projects, we've also created a 
number of important new features and changed others:

    * PAX_USERCOPY: this feature I developed (which was improved and 
      added within PaX) performs bounds checking on kernel objects, when 
      copying into or out of them via userland. The feature provides the 
      most protection for objects located on the heap (the feature 
      supports all current allocators: SLAB, SLUB, and SLOB, with the 
      strictest checks existing for SLUB). For objects located on the 
      stack, the bounds checking is less strict -- mainly to prevent 
      infoleaking of the entire kernel's memory space. The bounds 
      checking on stack objects will improve in future versions of the 
      feature.

    * Prevention of some integer overflows involving kernel allocators: 
      (e.g. "kmalloc(sizeof(somestruct) * attacker_controlled_len), 
      GFP_KERNEL);") This feature that I developed (which is enabled by 
      default with no configuration option) covers all the kernel 
      allocators which accept a size as an argument, failing the 
      allocation and logging the attempt upon detection of an integer 
      overflow.

    * Harden module auto-loading: By learning from the recent exploits 
      that generally involved causing an unused module to be loaded into 
      the kernel that was then exploited, I developed 
      GRKERNSEC_MODHARDEN. It prevents non-root users from causing 
      modules to be auto-loaded into the kernel. The option shouldn't 
      cause any incompatibilities (and any incompatibilities are easily 
      fixed): a desktop edition of Fedora Core 11 can be booted fully 
      without a non-root user attempting to auto-load a module.

    * Automated required steps for GRKERNSEC_HIDESYM: The documentation 
      for GRKERNSEC_HIDESYM has always mentioned restricting access to 
      kernel image paths, as they can be abused by an attacker to 
      determine targets for exploits just as /proc/kallsyms can be used. 
      By enabling GRKERNSEC_HIDESYM, non-root users will automatically 
      be prevented from reading kernel images/modules in /boot, 
      /lib/modules, and the kernel source tree currently being built 
      from.

    * Improved signal logging: the name of the signal being forced on a 
      process is reported instead of the signal number (easier to read 
      for inexperienced users). It will also now report the address 
      that caused the signal to be forced on every architecture.

    * GRKERNSEC_HARDEN_PTRACE: this feature was pulled from a feature 
      that has existed for years within the RBAC system, just adapted 
      for use outside of the RBAC system. It prevents non-root users 
      from ptracing arbitrary processes that they own. The point of this 
      is to defeat ptrace-based process/tty sniffers/monitors floating 
      around in the wild that steal keystrokes and SSH/GPG passwords. At 
      the same time, it still allows the most common legitimate uses of 
      ptrace, such as strace ./binary or gdb ./binary.

    * GRKERNSEC_BLACKHOLE: The stealth netfilter module has been removed 
      and replaced with a much easier to use feature that performs the 
      same task, ignores blackholing for the loopback interface, and has 
      much better performance. This feature is used to reduce the 
      effectiveness of certain types of DoS attacks.

    * Hundreds of function pointer tables in the kernel have been made 
      read-only (protected by KERNEXEC). I've developed a script that 
      will find and fix the markings on tables of vm_operations_struct, 
      file_operations, inode_operations, dentry_operations, 
      seq_operations, address_space_operations, and more.

    * FORTIFY_SOURCE was evaluated for use in the kernel, but 
      demonstrated poor performance (30% coverage when utilizing it 
      fully and properly marking allocators -- 40% after some internal 
      modifications). Based on my analysis, it wasn't protecting useful 
      areas of the kernel (only trivial unexploitable cases), so its 
      inclusion was scrapped. As a result of this work however, I 
      reported a weakness to Red Hat about the inability of 
      __builtin_object_size (which FORTIFY_SOURCE uses) to determine the 
      size of arrays within structures. A fix for this issue 
      will eventually make it out to the compilers vendors ship, 
      improving userland security for everyone.

    * copy_to/from_user was hardened on every architecture.

    * PAX_MEMORY_UDEREF now will co-exist with VMware guests using 
      HW-assisted virtualization

    * KERNEXEC and PAX_MEMORY_UDEREF now support paravirtualization

    * Additional analysis was added to gradm to detect poorly configured 
      policies

    * ip_override: Overriding INADDR_ANY for subjects in the RBAC system 
      was added, to force all programs within a given chroot to use a 
      specific IP, for instance.


I've also expanded the Research section of the website, where we list 
academic papers referencing grsecurity or PaX. The current count is 152!

I've surely left out some other minor changes to the code, but the above 
should be a good general summary of what we've been up to lately. As 
always, if you're interested in sponsoring further work of this type 
(we have some really great things in the pipeline), email me at 
spender at grsecurity.net.

Thanks,
-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20090927/749e724c/attachment.pgp