Re: [gentoo-hardened] 2.4.22-hardened O1/Low-latency/EA/ACL/grsecurity/propolice

[Phil West]

Peter,

First, thanks for taking the time to look at the hardened-sources so
thoroughly.  I appreciate the comments.  For those of you that don't 
know me,
I've been helping out with hardened-sources and have worked on the
patchsets for 2.4.21 and 2.4.22.

Point #0
--------

I agree that the original patch naming/versioning should appear in the 
patch
file name.  I'm really not sure why I didn't name the ckbase patch 
using that
convention, but I seem to have followed that convention with the 
majority of
the other patches.

Point #1
--------

For the diff of sched.c, this seems to be a side effect of an earlier 
version
of the ck-base patch.  In fact, it looks like the latest patch changes 
this
yet again from (p)->sleep_timestamp to (p)->timestamp.

For your diff of sys.c, that is definitely not good.  My source tree 
still
shows set_user() as static and it should be static.

Making it non-static, as you probably know, would allow a it to be
called from anywhere in the kernel.  I'm probably just being paranoid 
because
of the recent backdoor attempt against the bk-kernel tree, but I'd 
verify your
checksums and make sure someone isn't fooling around with your sources. 
  I
have the following:

MD5 75dc85149b06ac9432106b8941eb9f7b linux-2.4.22.tar.bz2 29528612
MD5 cb58e57bf9c2115eb71745761209df97 patches-2.4.22-hardened.tar.bz2 
2592916

As for naming the patches, I'm not sure about the extra slots.  Given 
the
number of colliding patches and the complexity of them, I've been 
leaning
toward tagging any fixes at the end of the patch chain, to make sure 
the fix
does not either get reversed by a subsequent patch or break the 
following
patches in the chain.

I've been trying to come up with a better order for the patches in
hardened-sources.  For 2.4.23 I was thinking of taking a different 
approach,
namely, apply all of the common patches used by both the grsec and 
selinux
branches of the kernel, then apply the grsec/selinux specific patches.

It will make applying both the grsec and selinux patches fail horribly, 
but
after having gone through both 2.4.21 and 2.4.22, they both fail 
horribly
already with where they are now in the patch chain.  I don't think it 
will be
that much more work to apply them last and that will, hopefully, let us 
keep
nearly all the other patches in their original form.  Feedback on this
approach is welcome.

Point #2:
--------

The ea-acl-nfs patch I used has:

  /*
   * The swap-out function returns 1 if it successfully
   * scanned all the pages it was asked to (`count').
   * It returns zero if it couldn't do anything,
@@ -598,6 +642,7 @@
  #ifdef CONFIG_QUOTA
	shrink_dqcache_memory(DEF_PRIORITY, gfp_mask);
  #endif
+       shrink_other_caches(priority, gfp_mask);

	return nr_pages;
  }

So, this may be due to an older version of that patch.

Point #3
--------

This is interesting.  This spot in mmap.c is one of the places where 
there
are quite a few patch collisions.

After the ck patch the code should look like:

	remove_shared_vm_struct(mpnt);
	mm->map_count--;
		
	zap_page_range(mm, st, size, ZPR_COND_RESCHED);   /* sys_munmap() */

PAX (via grsec and selinux+pax) wants it to look like this:

	remove_shared_vm_struct(mpnt);
	zap_page_range(mm, st, size);

So, it looks like the proper thing to do is:

	zap_page_range(mm, st, size, ZPR_COND_RESCHED);   /* sys_munmap() */

and not:

	zap_page_range(mm, st, size, 0);

You probably have something here.  I'm having trouble thinking of why I
may have done this, but it's late.  It may be the case that I wanted to
be more conservative here since PAX splits munmap into two parts and 
that
is a fairly big change to mix in with the low latency patch.  But I'm
probably over analyzing because it's late and I'm just as likely to have
missed it while resolving a patch reject.  :)

Point #4
--------

I'm not sure if there is anything special about the guard or not.  
Maybe Matt
(frogger) can comment on this as he is the hardened propolice guru.  The
cleanup portion of your patch seems fine. :)

Thanks,

-Phil


--
gentoo-hardened@g.o mailing list