GrSecurity issues

I finally bit the bullet and compiled a grsecurity kernel for my netbook.

(Speaking of compiling kernels, does 'make mrproper' do some hardware detection? It seems to always enable the correct ATA chipset driver.)

Anyway, first thing I noticed after booting was that Firefox segfaulted on start. Second thing was that VLC segfaulted. Third was that Opera segfaulted. Fourth was that Wine, of all things, worked fine (at least so far).

Mind, this was without even having RBAC enabled...

So I did some searching on the GrSec wiki (from another computer). Looks like Firefox 3 has problems with PaX and needs something called "mprotect" disabled. But I've no idea how to do that. I suspect I need paxctl, but I neglected to install it, which means I'll have to sneakernet it into the netbook and hope it compiles with full PaX restrictions in place... Oh joy.

Is stuff like this still normal with GrSec, or did I do something wrong? Because (other than that Xorg is running) this reminds me a lot of my experience with the patchset ~4 years ago...

 

Install paxctl and use it to disable mprotect.

This is all highly dependent on the settings used when you compiled. Some will cause issues, some won't.

You could always compile without mprotect restrictions and still have a really safe system.

Which distro btw?

edit: Can't you jsut boot in with another kenerl?

 

I can disable mprotect in the kernel config? D'oh. Think I'll install paxctl though.

Salix, i.e. Slackware for lazy slackers - it's Slack 13.37 with dependency resolution and a preconfigured desktop. Nice if you like to compile stuff.

(And yes, I could have just rebooted with the default kernel... Duh. I must have forgotten to boot my brain up this morning.)

Anyway I got paxctl installed, and Firefox and VLC now work fine. Hurray.

 

mrpotect restrictions are more of a 'consistency' mitigation more than something critical like ASLR. I wouldn't quite call it a pseudo mitigation, more of a reinforcement of policy. There are a few areas of Grsecurity that reinforce policies already there.

PaxCTL is easy as hell to use.

Glad you got it working.

 

Out of curiosity, how "safe" would you say a GrSecurity system without RBAC is, compared to a good AppArmor setup? What sort of vulnerabilities would AppArmor catch that PaX/GrSec wouldn't and vice versa?

Hmm. From what (little) I've read, it looks like W^X and such are only useful without mprotect (or equivalent) due to the laziness of attackers. So running with W^X and no mprotect is apparently a form of security through obscurity.

Oh, other things of note:

- Firefox needing mprotect off is apparently due to the Javascript JIT compiler. Turning that off is supposed to eliminate the need for disabling mprotect.

- Flash doesn't work at all - hangs Firefox and doesn't even load in Opera. Apparently this can be fixed for Firefox by disabling mprotect for *all* Firefox libraries; not sure about Opera. I'll probably deal with it by uninstalling Flash, since I don't actually need it.

- There does actually seem to be noticeable overhead, but only from some applications. Firefox is decidedly less responsive, Opera not so much. I suspect this reflects how compliant the code is with PaX mechanisms, or something like that.

 

There are local bypasses of apparmor. There are also situations where apparmor simply can't work - truecrypt for example is useless to apparmor because it has to mount and the sandbox is just really loose.

Pulseaudio is one example of a SUID'd program. So if you apparmor it you end up giving it capabilities like Kill and SysAdmin, which give an attacker a huge amount of room.

PaX and Grsecurity work together, they reinforce each other. For example teh grsecurity patch contains 'exploit bruteforce prevention', which reinforces PaX ASLR.

Both of the patches work to both prevent exploits outright, make exploits unusable, and contain exploits.

There are very very few and very very specific cases where PaX/grsecurity can't protect you. If you start looking around for "bypassing grsecurity" you aren't going to find a hell of a lot.

Check out http://pax.grsecurity.net/docs/pax-future.txt

Sort of. It's more that mprotect restrictions reinforces W^X. It's a cool feature:
http://forums.grsecurity.net/viewtopic.php?f=7&t=2939

Not surprising as JIT'd code has to be executable. It might interfere with JIT hardening where the permissions get changed? Not sure. Probably simpler than that.

There shouldn't be much performance overhead. But I've always found Firefox to be considerably slower on Linux compared to Chrome.

 

Thanks, interesting reading, though much of it is over my head. I do like that bit about implementing something like PaX in SMM space - maybe that could put the kibosh on certain types of hardware rootkits, that also would (theoretically) operate in SMM space.

But not as important as ASLR, I see. Thanks.

Edit: BTW I should also note that programs that use DRI seem to need memory protections removed. Not surprising, anything 3D is fairly insecure as I understand it.

 

Graphics drivers aren't designed with security in mind. Unfortunate as there's been a big booming increase in programs that make use of the GPU.

 

Is it possible to slack more than a slack user? LOL

 

Okay, bumping this thread because I have a small issue... PaX's on/off flags are built into each binary, so when programs are updated, my paxctl settings go poof.

Is there a better way of dealing with this? I'm thinking I could disable mprotect globally ( assuming that's possible with kernel parameters) but something more reasonable would be better.