Grsecurity inclusion in LKPC

Discuss and suggest new grsecurity features

Grsecurity inclusion in LKPC

Postby GCS » Mon Mar 18, 2002 11:38 am

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
GCS
 
Posts: 7
Joined: Mon Mar 18, 2002 11:23 am

well

Postby spender » Mon Mar 18, 2002 4:13 pm

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: Grsecurity inclusion in LKPC

Postby PaX Team » Mon Mar 18, 2002 5:41 pm

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 ;-).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

hmm

Postby spender » Mon Mar 18, 2002 5:55 pm

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.
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: Grsecurity inclusion in LKPC

Postby GCS » Tue Mar 19, 2002 3:03 am

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.
:wink:

Cheers,
GCS
GCS
 
Posts: 7
Joined: Mon Mar 18, 2002 11:23 am

Re: well

Postby GCS » Tue Mar 19, 2002 3:17 am

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)?
GCS
 
Posts: 7
Joined: Mon Mar 18, 2002 11:23 am

..

Postby spender » Tue Mar 19, 2002 9:45 am

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
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: ..

Postby GCS » Mon Mar 25, 2002 5:33 am

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
GCS
 
Posts: 7
Joined: Mon Mar 18, 2002 11:23 am

hrmm

Postby spender » Mon Mar 25, 2002 8:49 am

i don't see why that's needed. doesn't the first tpe gid option do exactly what yours is trying to do?
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: hrmm

Postby GCS » Mon Mar 25, 2002 10:05 am

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
GCS
 
Posts: 7
Joined: Mon Mar 18, 2002 11:23 am

yea

Postby spender » Mon Mar 25, 2002 11:01 am

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Grsecurity is included

Postby GCS » Sun Apr 14, 2002 3:29 pm

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
GCS
 
Posts: 7
Joined: Mon Mar 18, 2002 11:23 am


Return to grsecurity development

cron