[tech] Grsec

[Bernard Blackham]

> - ucc is not _much_ safer with grsec as there are other ways to get in.

It helps. The PaX patches mean that most traditional heap/stack
overflow exploits don't work. The idea is that the binary itself is
marked with this flag, so it can't do anything bad whilst executing.
Of course if somebody gets root, they could turn off these
protection flags but at that point you're already screwed.

If you're running into PaX issues, just run "chpax -xperms <binary>"
on your program (even put it in the Makefile) and all PaX protection
is turned off.

The other advantage is that many exploits out in the wild for
various bugs will not work as is on grsec kernels (some take a fair
bit of modification, and some just can't fundamentally work).  Hence
your average script kiddie will be left stumped.

> - the main point: people can no longer hack happily on the affected
> machines. The grsec kernel is too panicky and kills off any processes
> that are using unsafe syscalls.

Not true. Unsafe syscalls are only caught if you tell them to be,
using systrace. The idea behind systrace is that you execute an
untrusted binary, or some other daemon under it and only then will
"unsafe" syscalls be stopped in their tracks.

> This obviates the usefulness of the ucc, making our machines as
> restrictive as cs boxen.

CS machines are restrictive? :)

> Also, the side effects can be very obscure and hard to pinpoint. Another
> thing to add to someone who's developing experimental/pre-release code
> that's buggy anyway.

I've yet to find any bugs that were directly caused by grsec and not
logged in dmesg as being a PaX restriction. You'll see something
like:

kernel: PAX: terminating task: /home/b/dev/test(test):13346, uid/euid: 1000/1000, PC: 0fff007a, SP: 5cfff130

in dmesg, meaning that you should disable one of the pax flags with
chpax. Or run "chpax -xperms <binary>" to disable them all (for
development).

On the other hand, if you see a line like:
kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (wine.bin:3811) UID(1000) EUID(1000), parent (zsh:3792) UID(1000) EUID(1000)

then your program segfaulted anyway, and grsec decided to make a
note of this and wouldn't let it coredump. You can turn on coredumps
with ulimit. gdb should still work to find out where it crashed, as
will printf() :)

> So, please post your views so we can come to a solution and get back to
> hacking ;)

If you want to let me know how exactly you think it's getting in the
way, I'll be happy to have a look at it. But with the exception of
PaX (which is easily solvable), I haven't been convinced that it is
interfering with much.

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>