advantages of grsecurity?
 

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.

--tarballedtux





P.S. That stinks about your car Trickykid. Can you tell I'm bored.

Re: advantages of grsecurity?
 

You must be bored then checking out my own site. :D Oh by the way, there is another thread about this same topic that jeremy replied to.

Re: advantages of grsecurity?
 

"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.

Trusted path execution (TPE)
Deny running executables outside the system's $PATH

Randomized * (RAND.* options)
Randomize PID's for instance.

Deny * socket access (SOCKET.* options)
Like it sez. Deny creation of (client|server) sockets for certain users.

And *then* there's the ACL system...

HTH.

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.

--tarballedtux

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.

Alright so I'm grsecurity is not so bad. What do the rmap and O(1) scheduler do? A Google query is not helping me find any information.

--tarballedtux

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.