[rsbac] my 2.4.32pre2 +rsbac oops

[Murf]

Bencsath Boldizsar wrote:
> 
>>>Why do You think that rsbac and grsec cannot be used paralelly? E.g. I can
>>>make use of the chroot extensions, proc file system protection, ip
>>>randomization of grsec and the role based model of rsbac.
>>>
>>
>>You wrote you are using RBAC of GRSEC.
> 
> 
> Please, stay at least 1 second reading my email. I wrote clearly, that
> "role based model of rsbac".
> 
> 
> 
>>I would be suprised if it has. You know, RSBAC has
>>its own strong RC security model, so what are you using from
>>RSBAC if you are using RBAC from GRSEC?
> 
> 
> See above.
> 

This is misunderstanding. You mentioned "role(R) based(B) ....".
It points to RBAC model due to its name but RSBAC has
"role(R) compatible(C) model" intead.

> 
>>Random IP id or source ports sounds good in some cases,
>>but afaik its in 2.6 already, so probably you are talking
>>about 2.4 branch.
> 
> 
> I clearly stated that my problem is related to 2.4.32Pre2. I don't think
> it's too mistificated to guess, yes, it is a 2.4 branch kernel.
> 
> 
>>BTW. There is somewhere separate
>>patch for 2.4, if its the only thing that you are missing.
> 
> 
> 
> Very good. You advice to patch every single feature of grsecurity into a
> rsbac prepatched kernel from a stand-alone patch instead of patching with
> grsecurity, without any more reason that both patch have similar
> functions.

This is only one feature from the set you mentioned that
is not covered by RSBAC (see previous mail). So I suggested
to use rather one simple patch and no other complex security
kernel patch in addition.

> 
> 
>>You can enable /proc restriction in RSBAC too.
>>Process can access other processes proc data
>>only if it has GET_STATUS_DATA right to destination
>>process type. What other restriction did you mean?
>>
>>You can use JAIL module in RSBAC instead of chroot
>>and its extension from GRSEC.
>>
> 
> 
> Yes sure, You can do that too, I'm not trying to make an argument on this
> topic, RSBAC has lots of feautres, GRSEC has also lots of features and I'm
> sure that RSBAC simple cannot cover all the feature of grsecurity.
> Throwing out grsecurity because of the fear of patching a kernel with both
> is somewhat conservative...
> 

You mentioned features in the previous and I tried explain
you that it could be repleaced by something from RSBAC.
If you are so sure then tell me other features from
your huge set of features of GRSec that RSBAC has
not and i will try find solution in RSBAC. If you show
me real important security feature that is missing in RSBAC
and is contained in GRSecurity I maybe change my opinion :).
But you haven't done it yet.

> 
> 
>>Still didn't get the point of using it together.
>>
> 
> 
> There is no point NOT doing that.
> 

The only reason that i see is that you are making it
for fun or for thinking that you have real secure system
by using both patches. But its simply wrong.

Now I only see it as unusable due to stability issues
and also as a wasting your time. But its your choice
and your time, ofcourse.

> 
> 
>>If you are just playing with kernel patches with many rejects,
>>I have nothing againt it ;).
> 
> 
> To clarify it again, patching with both patch-sets works. I have problems
> only with 2.4.32pre2 patch, grsecurity and rsbac.
> 
> Of course, as this combination is VERY experimental, the reason of oops
> can be a version related problem between rsbac and the kernel, a bug in
> rsbac, or of course the reason can also be the bad resolution of the
> multiple patches.
> 
> I think the problem is more rsbac related than grsec or anything,
> therefore the goal of this report is NOT only to solve MY issue, rather
> than to identify a potential problem with 2.4.32 (final, if it comes out)
> and rsbac 1.2.4 + bugfixes.
> 
> On the other hand using 2.6 branch is not so simple. I don't know the
> current status of rsbac, but lately I found some instabilities. Except
> from that openswan with 2.6 had also several problems. Some addition to
> that is the migration from rsbac 1.2.3->1.2.4 which also rose errors
> sometimes. If I'll have more time, I'll test it again as new developer
> release openswan is available etc., but it is not just so simple to decide
> to use the 2.6 branch.

Thank you for clarification.

Rgds,

Murf