Bug 152123

Okay, had some playings w/ AppArmor.. though it doesn't solve all problems and is enough pain to enable it on everything (or at least all crytical) things (as also enough pain to change working model for some daemons (i.e. postfix))..
BTW: is there a good AppArmor admin quick trick FAQ?

So, anyway, I gotta to get back to my best - the grsecurity enabled kernel w/ custom security settings, as I usually do at home and at work. =) 

Okay, ran yast.. Got _no_ results from finding both grsecurity and PaX with yast->software management. :/ 

No even howto/warnings/listing of things that . Got nothing, but one page w/ annotation of SESUSE searching from open suse web.. Where can I get SuSE (not kernel org!) kernel w/ grsecurity or at least PaX (it's part of grsec) 
applied? :?

The grsecurity (or at least _parts_ of its functionality) is A MUST for any system concerned on security.

Well, there're lots of questions while talking to the kernel patches (at least for me - not a professional coder). I didn't even tried to play w/ that stuff yet, since, I guess, this may interfere w/ AppArmor, but since I'm not a professional coder I can't just get into the source. Well,
step by step:

1. Is grsec compatible w/ current SuSE kernels? If not - in wich parts?

2. Is PaX compatible w/ current SuSE kernels? If not - in wich parts?

3. If I get a current kernel from the kernel.org - what will be broken in my system right after I run it?

4. Say I'll get the kernel source suse rpm & get all patches applied to the kernel from there and will try to apply them on top of grsec. Would I then get rejects? Is it the right way? Guess no. That magic should be cleared w/ some FAQ for developers and advanced admins w/ declaring of correlations between a list of patches applied to the kernel within a generic SuSE system and all popular
security enhancement systems. At least the following things should be definitely overviewed by such a FAQ: RSBAC(and clones), PaX, grsecurity, AppArmor .

Yes, I can download and try the kernel.org plain current kernel, patch w/ grsec and.. stay w/ missing of some cute things, I guess..

Yes I will do that w/ SuSE system installed on x86 server. Hope most of server
required things would not broke (any comments?). Though I prefer to not doing that on my home SuSE workstation.

Well, setting the following flags:

1. Common_Criteria: because the lesser exploits work on my system the better it is. Please don't tell me that grsec is the wrong way. It _is_ the right way, or at least partially it is. :/

2. documentation: This really needs at least a quick FAQ (see questions above).

3. security: obviouse.

4. Usability: The system w/o grsecurity should not (for me - cannot) be used in aggressive network environments.

Related readings: 

http://old.lwn.net/1998/0806/a/linus-noexec.html 

and after that:

========== grsec ===========
CONFIG_GRKERNSEC_PAX_RANDMMAP:
   By saying Y here the kernel will use a randomized base address for
   mmap() requests that do not specify one themselves.  As a result
   all dynamically loaded libraries will appear at random addresses
   and therefore be harder to exploit by a technique where an attacker
   attempts to execute library code for his purposes (e.g. spawn a
   shell from an exploited program that is running at an elevated
   privilege level).

   Furthermore, if a program is relinked as a dynamic ELF file, its
   base address will be randomized as well, completing the full
   randomization of the address space layout.  Attacking such programs
   becomes a guess game.  You can find an example of doing this at
   <http://pax.grsecurity.net/et_dyn.zip> and practical samples at
   <http://www.grsecurity.net/grsec-gcc-specs.tar.gz> . 
========== grsec ===========

That's why I say, that, at least a part of grsecurity stuff is a must.

As you see from above (not a secret for any developer though), that new 
hardware with non executable pages would solve only part of a problem (I'm about CPUs w/ NX flag(AFAIR it's called NX %))).

As about complains to the 'partial solvage' I can say that at least these patches try to solve the problem with a class of exploits, and give a need to adopt hardly most others. At least with the grsecurity enabled kernel I feel relatively safe from a kiddie w/ "n3w 3l33t spl017" just ripped from full disclosure mailing list or so. Non working standard exploits - that is a 
really good improvement for me (Assuming that I'm not a vary interesting tagret for pen test professionals. ;-)) ) and many other people will agree w/ me I guess.

http://en.opensuse.org/SESUSE - the only one page found on opensuse. Though that says that developers know about the topic. That's good. But where's the patched kernel w/ other SuSE patches applied to it???

The search on suse.com (redirected as usually) does nothing interesting - opened all links.

For those who donno anything (are there any? guess noone, but anyway):
http://pax.grsecurity.net/
http://grsecurity.net/

Heh.. this post was on todo list for at least a half month - had not enough time..