Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
When I came onto this site I noticed the release of the lq3 kernel. No I read that grsecurity was put into and I read up on it a a little and though to myself "Why would anyone really need this?" or at least why would a beginner need this. So could anyone kick me in the head and then explain this to me? I'd rather have a patch that hardened alot of the default kernel's dumb stack overflow vulnerabilities. Instead of an ACL system.
P.S. That stinks about your car Trickykid. Can you tell I'm bored.
Last edited by tarballedtux; 09-23-2002 at 08:41 PM.
"Why would anyone really need this?" or at least why would a beginner need this.
Because it is the least painfull option around to patch the kernel to enable your system to run with better security features (if configured well, ofcourse). (note to self: put up annotated sysctl)
I'd rather have a patch that hardened alot of the default kernel's dumb stack overflow vulnerabilities. Instead of an ACL system.
Grsecurity isn't solely an ACL system. Read Documentation/Configure.help for the Grsecurity options.
Here's some curbing potential BO holes:
Openwall Non-executable Stack (STACK)
Deny your system from executing code on the stack leaving only a few other ways to try and exploit running code.
Full Address Space Layout Randomization (RANDMMAP)
Randomize address layout for programs per execution.
Deny access to /dev/kmem (KMEM)
Like it sez. See wellknown LKM docs by Silvio Cesare.
Proc Restrictions (PROC.* options)
Deny/restrict access to /proc against processes/users snooping around. Merged from Solar Designers OpenWall patches.
Deny * in chroot (.*CHROOT options)
Makes it harder to break out of chroots.
Are the non-ACL options of grsecurity (The ones you mentioned) Sane patches that won't interfere at all with the normal operational of my box? That would be great if the patches didn't change they way I operate my box, but stop easy exploits.
I don't know how you operate your box, so I don't know what kind of interference you're suspecting, but Grsec applies cleanly (ie no .rej's) to a current clean kernel source. Unlike with other CVS projects even CVS versions of Grsec should run cleanly because they're tested and run *before* committing.
Yes, they're sane patches. Haven't had any real trouble running Grsec the last 1.5 yrs on both 2.2x, 2.4x, UNI and SMP.
Tbt, you shouldn't tack on OT questions, add a new thread, and since it ain't about security, it should be in /General.
For scheduler Google for "linux scheduler" or "Ingo Molnar scheduler". He's at people.redhat.com/~ingo or something like that, for rmap Google for "Rik van Riel rmap" and or look at surriel.com. Major sites like LWN do carry trheads from the kernel mailinglists or review new kernel features so it would be weird if nuttin's showin up.