Flow of matches problem with vserver processes
Posted: Sun Jan 20, 2013 6:45 amHello,
I'm using grsec/gradm v2.2.2 with Linux kernel v2.6.38. I know this is a two year old version, but since I'm also using vserver and there isn't any newer kernel patches supporting both grsec and vserver, I have to stay with this grsec version.
During the creation of grsec policy (enable full lerning mode -> carry out all possible system tests -> let ACLs being generated by gradm -> repeat the system testing -> tune the ACLs manually), I have massive problems with flow of matches for some vserver processes (e.g. squid). In a sporadic manner I got grsec denied messages for some vserver processes although there were already matching ACLs in the exiting policy. This problem affects both subject and object hierarchies. To workaround the object hierarchy problem I have to add the missing permissions to the default object "/", although they were available to the more matching object. For the subject hierarchy problem I have to add the missing permissions to the default subject "/", although they were available to the matching process/subject name. It looks like in general this grsec v2.2.2 has problems dealing with vserver processes in terms of flow of matches for subjects as well as objects.
My questions here are, are there already similar findings in the past? And are there any solutions/workarounds for this problem without a grsec version update?
Furthermore grsec identifies the role name using Linux UID. For the vserver process either a wrong role name is shown in the policy if the same UID is available on host for a different user name or the role name nobody is used if no corresponding UID is defined on host. Is there any solutions for this problem?
Thanks and best regards
I'm using grsec/gradm v2.2.2 with Linux kernel v2.6.38. I know this is a two year old version, but since I'm also using vserver and there isn't any newer kernel patches supporting both grsec and vserver, I have to stay with this grsec version.
During the creation of grsec policy (enable full lerning mode -> carry out all possible system tests -> let ACLs being generated by gradm -> repeat the system testing -> tune the ACLs manually), I have massive problems with flow of matches for some vserver processes (e.g. squid). In a sporadic manner I got grsec denied messages for some vserver processes although there were already matching ACLs in the exiting policy. This problem affects both subject and object hierarchies. To workaround the object hierarchy problem I have to add the missing permissions to the default object "/", although they were available to the more matching object. For the subject hierarchy problem I have to add the missing permissions to the default subject "/", although they were available to the matching process/subject name. It looks like in general this grsec v2.2.2 has problems dealing with vserver processes in terms of flow of matches for subjects as well as objects.
My questions here are, are there already similar findings in the past? And are there any solutions/workarounds for this problem without a grsec version update?
Furthermore grsec identifies the role name using Linux UID. For the vserver process either a wrong role name is shown in the policy if the same UID is available on host for a different user name or the role name nobody is used if no corresponding UID is defined on host. Is there any solutions for this problem?
Thanks and best regards