When you use learning mode, gradm may complain that lib and lib64 objects are both present and equivalent, in implicitly generated subjects. gradm tries to do the right thing, but I think it may be assuming a multilib system. I've written an ugly, gentoo-amd64-specific patch. Reproducible: Always Steps to Reproduce: 1.Run learning mode for a role that can validate to gradm. 2.Try converting the logging output to a policy, using gradm. 3.Try to load the policy. Actual Results: Complaints of lib and lib64 being the same. Refusal to load. Expected Results: Loaded the policy. An ugly patch is attached.
Created attachment 40119 [details, diff] Patch for gradm-2.0.1-r1 on amd64 This patch is ugly, because the issue isn't really an "amd64" issue, but a filesystem structural problem. But the patch refers specifically to amd64.
lv: Can you look at this multilib change?
Is this patch still needed for gradm-2.1.0?
Created attachment 48982 [details, diff] workaround for amd64 multilib-noncompliance
I've provided the new patch for 2.1.0. This workaround won't be needed when amd64 goes fully multilib, but that probably won't be for several months.
This issue has been fixed in grsecurity CVS. The next grsecurity/gradm release should resolve this issue in portage as well.
