hardened-sources-3.2.6 problems
 

On 24 Feb 2012 at 10:32, "Tóth Attila" wrote:
> Even after change to another user (mail or dovecot). It seems the kernel
> incorrectly recognized the change of the UID.

wasn't that already fixed with:

commit 4fd554e3a097b22c5049fcdc423897477deff5ef
Author: Brad Spengler <spender@grsecurity.net>
Date: Mon Feb 20 09:17:57 2012 -0500

Fix wrong logic on capability checks for switching roles, broke policies
Thanks to Richard Kojedzinszky for reporting

hardened-sources-3.2.6 problems
 

On 02/24/2012 07:36 AM, PaX Team wrote:

On 24 Feb 2012 at 10:32, "Tóth Attila" wrote:

Even after change to another user (mail or dovecot). It seems the kernel
incorrectly recognized the change of the UID.


wasn't that already fixed with:

commit 4fd554e3a097b22c5049fcdc423897477deff5ef
Author: Brad Spengler<spender@grsecurity.net>
Date: Mon Feb 20 09:17:57 2012 -0500

Fix wrong logic on capability checks for switching roles, broke policies
Thanks to Richard Kojedzinszky for reporting



I'm testing 3.2.7 right now. I'll have it up soon.

@pipacs, I've had reports of 3.2.2-r1 kernels having problems booting.
idl0r gave me a bzImage which will not boot in qemu. Using the same
kernel config, 3.2.7 *will* boot. The problem occurs shortly after
decompression but before any early printk. Is this a known issue that
has been fixed or should I continue to try to isolate the problem? As I
said it seems to be gone in later kernels.


our hardened-sources-3.2.2-r1 = grsecurity-2.2.2-3.2.2-201201272014

the 3.2.7 which I will put up in a bit is the very latest which came out
today.


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

hardened-sources-3.2.6 problems
 

On 25 Feb 2012 at 14:40, Anthony G. Basile wrote:

> @pipacs, I've had reports of 3.2.2-r1 kernels having problems booting.
> idl0r gave me a bzImage which will not boot in qemu. Using the same
> kernel config, 3.2.7 *will* boot. The problem occurs shortly after
> decompression but before any early printk. Is this a known issue that
> has been fixed or should I continue to try to isolate the problem? As I
> said it seems to be gone in later kernels.

hmm, i don't recall such issues but if you can get me a bzImage and vmlinux
i can take a look and tell you what it is.