grsecurity forums

Hi all,

I am doing a small collection of patches at http://lkpc.sourceforge.net/ . I have been asked, and it meets my plans to include a security related patch - Grsecurity. I have not tried to merge it yet, but I expect some trouble. Thus it would be good if Grsecurity is available as parts ( ACLs, random PID, etc).
If there is no such thing, only a big patch, then is it possible to get contact with one of you and ask sometimes?

Thanks,
GCS

nope, there's only the one big patch...since some parts rely on each other (though the kernel code is only changed if options are enabled...i've been very strict about that)

feel free to post any questions you have with failed patches

-Brad

GCS wrote:I am doing a small collection of patches at http://lkpc.sourceforge.net/ . I have been asked, and it meets my plans to include a security related patch - Grsecurity. I have not tried to merge it yet, but I expect some trouble.

since your page talks about a rock stable patch, a note of caution regarding PaX: it has not yet been proven to be rock stable, you should be careful about including it. of course if you (and/or your users) are willing to take up the testing, all the better for us and we will appreciate the feedback .

I haven't had any problems with PaX as of the newer versions. I've disabled it on programs where it generates annoying messages, but then again, it's really only necessary to enable it on running daemons and suid/sgid apps. With that configuration, I haven't had any problems.

Hi!

PaX Team wrote:since your page talks about a rock stable patch, a note of caution regarding PaX: it has not yet been proven to be rock stable, you should be careful about including it. of course if you (and/or your users) are willing to take up the testing, all the better for us and we will appreciate the feedback .

Sure, I would like to keep it as stable as possible. But as I know, PaX is stable enough and do not forget that 100% stability just does not exists, even the core kernel can give you Ooops rarely. Also, as it was said, more users -> more feedback -> faster bug hunting. On the other hand, it may create more bugs, as it is more complex because the added patch.


Cheers,
GCS

Hi Brad!

spender wrote:nope, there's only the one big patch...since some parts rely on each other (though the kernel code is only changed if options are enabled...i've been very strict about that)

feel free to post any questions you have with failed patches

Ok, I understand. Btw, there are some patches that do not rely on an other group of extensions in Grsecurity. One question: sysctl support turns off the features if I see right from the patch. Why?

I think most of the problems will be about your ACL implementation, LKPC already contains an implementation, but this one only support filesystem ACLs. An other one would cause trouble, thus I should remove it from the core Grsecurity. Would you mind doing the inclusion without your ACL implementation (the ACL debug, password protection also needs to be removed, or altered to support the already included ACL system)?

Thanks,
GCS
Ps: How's the status involves (newbie/magister)?

yes, if sysctl is enabled, all features are disabled by default. It's then the user's responsibilty to enable them with a boot-time script, and then set the grsec_lock entry after they're done setting the sysctl values. I did it this way because some people might want to enable all the grsecurity options as sysctl options, and then just enable some of them at bootup, and not all of them (as some might cause problems during the bootup itself).

I don't mind you doing the acl stuff, but I can't help you with it. I'm busy enough as it is, and certainly can't free up time to help take out code that Mike's worked so hard on to get in.

i just made up some special ranks and such...everyone else has regular ranks...you'll see what they are when you get there.

spender wrote:I don't mind you doing the acl stuff, but I can't help you with it. I'm busy enough as it is, and certainly can't free up time to help take out code that Mike's worked so hard on to get in.

I have removed it some time ago, and it is working quite well for me. I may send you the changes if you are interested.
But the main reason I write you is that I have a patch for Grsecurity. The problem was that if you do not have sysctl support, then the TPE restriction forced the user to restrict all non root users. Now s/he can choose the favour s/he likes. I am going to send it to you in private for approval. Hope you will include it.

Cheers,
GCS

i don't see why that's needed. doesn't the first tpe gid option do exactly what yours is trying to do?

spender wrote:i don't see why that's needed. doesn't the first tpe gid option do exactly what yours is trying to do?

I do not understand. Which first tpe gid option do you refer to? I am talking about 'Partially restrict non-root users'. It turns on

Code: Select all

CONFIG_GRKERNSEC_TPE_ALL

Which set

Code: Select all

int grsec_enable_tpe_all = 1;

Next comes the protection itself:

Code: Select all

if(grsec_enable_tpe_all?current->uid:in_group_p(grsec_tpe_gid))

But as grsec_enable_tpe_all is constant one if you have the TPE restriction on without sysctl, the above is equals to

Code: Select all

if(current->uid)

So all non root users are affected, and you can not change it without the patch I have sent to you. Is it more clear now?
Bye, GCS

yea i understand. basically you want an additional group for the lower restriction. I was just following the TPE specification itself. I'm not sure if another gid is really needed. If we do do something like that, it will be when we move the tpe feature to the acl system.

-Brad

Hi all,

Finally I managed a release as I had several problems in my life. Life is not easy with two workplaces.
Also, I still have a problem with writing on loop mounted filesystems. But I hope it will be fixed soon. Download from http://sourceforge.net/project/showfiles.php?group_id=47856 or see the changelog at http://sourceforge.net/project/shownotes.php?release_id=77560.
Cheers,
GCS