Last time I used gr-security (granted, that was a few years ago), I had to change the kernel configuration and recompile the kernel everytime I wanted to change something in the configuration. It reminds me of the arbitrary limitations of MS-Windows.
You've missed a lot then, as grsecurity has a complete RBAC system now, and it's had sysctl-tunable config options for at least 2 years.
With RSBAC, there are basically hardly any such hard-coded limitations. The JAIL module doesn't have to be perfect, because you can combine it with RC (Role Compatibility), ACLs and a number of other security modules.
Brad: Next time you have problems with getting RSBAC JAIL to work, join #rsbac or #adamantix, there are always people who are willing to try to help you out.
Oh, I didn't have much trouble last night setting up RSBAC on a vmware image with JAIL support compiled in, other than finding out how the jail was used, and then finding that the rsbac_jail application was unsuitable for my purposes and not wanting to have to include tons of rsbac code, searching through code to find out how to set up the jail with a single syscall (nothing that any user I know of would be willing to do, unless they were looking for vulnerabilities in RSBAC like me
) I modifed a test application to use the rsbac_jail like so:struct rsys_jail_t jail;
char *path = "/tmp";
unsigned int ip = 0;
jail.version = RSBAC_JAIL_VERSION;
jail.path = path;
jail.ip = ip;
jail.flags = 0;
syscall(__NR_security, RSBAC_VERSION_NR, RSYS_jail, &jail);
and then demonstrated a *vulnerability* in RSBAC wherein I could execute code outside of the jail. Given an application bug, I can also break out of the RSBAC jail, and I noted two other methods to corrupt data used by processes outside the jail. Of course, none of these apply to the chroot in grsecurity, which doesn't require any userland modification. When/if you find the vulnerabilities and fix them, I'll be sure to write an advisory in the same fashion as I did for systrace, where of course I'll have only favorable things to say about you.
The definition of stupid I use when referring to you is:
3 : marked by or resulting from unreasoned thinking or acting : SENSELESS
Your willing decision to remain ignorant on topics that you are giving opinion stated as fact makes you stupid. If you were truly ignorant, I would call you that instead.
I'm glad you changed your tune and admitted you know nothing about grsecurity. I don't see anything else useful that can be added to this thread at this point, so I'm closing it.
-Brad