[grsec] grsecurity 2.0.3-2.6.9 test release

John Logsdon j.logsdon at quantex-research.com
Tue Dec 21 12:11:18 EST 2004


Happy Xmas and New Year to all, particularly Brad

Does this announcement mean that 2.4 and 2.6 CVS kernels are more or less
synchronised again - ie are the patches already in 2.4 CVS?

Best wishes

John

John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
j.logsdon at quantex-research.com              a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


On Mon, 20 Dec 2004, Brad Spengler wrote:

> I've placed a grsecurity 2.0.3 patch for Linux 2.6.9 at:
> http://grsecurity.net/~spender/
> New patches will be uploaded if problems are reported with the current 
> patch.  New patches will have the date and time represented in the 
> filename so it is easier to tell when a new patch is available.
> 
> If you've been reading changelogs recently or watching in #grsecurity on 
> irc.oftc.net, you've noticed I have been pretty busy working on 
> grsecurity 2.0.3.  Among these changes in the upcoming 2.0.3 are:
> 
> * New configuration file for full learning: /etc/grsec/learn_config
> From the documentation provided in the file:
> 
> #This configuration file aids the learning process by tweaking
> #the learning algorithm for specific paths.
> #
> #It accepts lines in the form of <command> <pathname>
> #Where <command> can be inherit-learn, no-learn, or inherit-no-learn.
> #
> #inherit-learn changes the learning process for the specified path
> #by throwing all learned accesses for every binary executed by the
> #processes contained in the pathname into the subject specified
> #by the pathname.  This is useful for cron in the case of full
> #system learning, so that scripts that eventually end up executing
> #mv or rm with privilege don't cause the root policy to grant
> #that privilege to mv or rm in all cases.
> #
> #no-learn allows processes within the path to perform any operation
> #that normal system usage would allow without restriction.  If
> #a process is generating a huge number of learning logs, it may be
> #best to use this command on that process and configure its policy
> #manually.
> #
> #inherit-no-learn combines the above two cases, such that processes
> #within the specified path will be able to perform any normal system
> #operation without restriction as will any binaries executed by
> #these processes.
> 
> I hope for the default learn_config to be applicable for any system so 
> that full learning can be used without any configuration.  With this in 
> mind, if you have any applications that perform in similar ways to cron 
> scripts (executing lots of normal apps with privilege), let me know 
> about them, so they can be added to the configuration.
> 
> * Learning heuristics have been optimized to better detect temporary 
>   file usage and reduce appropriately.
> * Learning heuristics have been modified to weight against reducing
>   certain additional important directories.
> * User/group ID transitions have been added to the learning system.
>   Any subject transitioning to less than 3 different users or 3 
>   different groups that has CAP_SETUID or CAP_SETGID will have ID
>   transitions added.  This is useful to automatically secure 
>   applications that only transition to one or few users/groups like
>   nobody/nogroup.
> * /proc/<pid>/* accesses are automatically rewritten as /proc by grlearn 
>   before being cached and written to disk
> * The inherit-based learning usable through the learning configuration 
>   file is usable through a regular policy as well simply by adding "i"
>   instead of "l" to a subject for learning.
> * Inheritance is preserved whenever possible across uid/gid changes when
>   the role resulting from the uid/gid change is no different from that
>   before the change.
> * A complete ~95-99% efficient LFU-hash hybrid caching system has been 
>   added that greatly reduces the number of full object lookups by 
>   caching the result.  The cache essentially mimics the filesystem 
>   around where applications are operating: nearly equivalent to having 
>   an object for every file and directory on the system, but without the 
>   wasted memory.  The cache is invalidated on creates and deletes that 
>   cause a change in policy (through policy re-creation) and on renames
>   of directories or symlinks.
> * Memory usage for non-full learning has been significantly reduced and 
>   all memory leaks have been plugged.
> * Interactive performance of full-learning has improved by ~15% by 
>   reducing the number of context switches caused by grlearn doing small 
>   disk writes by using a write buffer (writing more once instead of 
>   less 1000 times) and keeping track of log entry lengths for quicker 
>   string matching.  A signal handler was added to grlearn so that when
>   learning is stopped, the write buffer is flushed to disk.
> * Kernel headers are no longer used for gradm
> * Bugfixes for things mentioned on the list, etc
> 
> If you're going to use the 2.6.9 patch and want to use the RBAC system, 
> you'll have to grab gradm2 from CVS.  If you don't want to use 2.6 but 
> still want to try out the new features of 2.0.3, grab grsecurity2 from 
> CVS.
> 
> Happy holidays
> 
> -Brad
> 



More information about the grsecurity mailing list