Duplicate subject

[Stephane]

Hi all,

Starting to play (just to understand) with the full system learning mode and getting some duplicate subjects :
Duplicate subject found for "/sbin/ifup" in role root, on line 267 of /etc/grsec/policy.
"/sbin/ifup" references the same object as "/sbin/ifdown" specified on an earlier line.
The RBAC system will not load until this error is fixed.

Here is the policy generated :

# Role: root
subject /sbin/ifdown o {
/ h
/etc h
/etc/ld.so.cache r
/etc/network/interfaces r
/lib h
/lib/x86_64-linux-gnu/ld-2.15.so x
/lib/x86_64-linux-gnu/libc-2.15.so rx
/run h
/run/network/ifstate ra
/sbin h
/sbin/ifdown x
-CAP_ALL
bind disabled
connect disabled
}


# Role: root
subject /sbin/ifup o {
/ h
/etc h
/etc/ld.so.cache r
/etc/network/interfaces r
/lib h
/lib/x86_64-linux-gnu/ld-2.15.so x
/lib/x86_64-linux-gnu/libc-2.15.so rx
/run h
/run/network/ifstate ra
/sbin h
/sbin/ifup x
-CAP_ALL
bind disabled
connect disabled
}

So the same rules are generated for both ifup & ifdown (and ifquery...) what is the problem ? Can you help me figuring it out ?
Thank you

PS: I've seen an old topic talking about issues with LXC containers, is it fixed now ?

[spender]

Those binaries are all hardlinked versions of the same binary. As long as the policy is the same for all of them, just remove the reported duplicate subjects -- the resulting policy should work fine. I will need to add some code to gradm to prevent generation of these duplicate subjects from learning.

Mount namespaces are still not supported, though other namespaces should work fine with RBAC.

-Brad

[Stephane]

Ok great, thank you Brad for these precisions

[Stephane]

Hi again,

One more question :
gradm -E :
Viewing access is allowed by role root to /etc/grsec, the directory which stores RBAC policies and RBAC password information.
There were 1 holes found in your RBAC configuration. These must be fixed before the RBAC system will be allowed to be enabled.

But I can't find the line allowing root to view /etc/grsec/ in my policy (it seems to be hidden everywhere) :

root@myhost:/etc/grsec# grep grsec policy
define grsec_denied {
/dev/grsec h
/etc/grsec h
$grsec_denied
/dev/grsec h
/etc/grsec h
/etc/grsec h
/dev/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/dev/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h
/etc/grsec h


Thank you for your help

PS : Will it work if I patch my kernel with both grsec/PaX and the Con Kolivas low latency patch ?

[Stephane]

Ok, I erased my policy, then made gradm re-learn all paying attention not to go in /etc/grsec/ and it worked, great...
So now my root account is really limited and that's what I want to do basically, just gradm -a admin ... but now for me to undestand, if I missed something and I want to allow at least root to restart apache2 for exemple, what's the best practise to do so ? Writing a new policy by hand or re-learn all while root is restarting the service ?

Thank you

[spender]

Do the restarting under the admin role (unless you want to create a special role specifically for doing this restarting of apache) and remember to gradm -u immediately after restarting apache.

-Brad

[Stephane]

Ok thank you, actually I want to create a special domain (I'm reading the doc at the same time) for a group of users to allow them to restart apache ...
So I'd begin by :

domain restartapache g daemon bin www-data myAdminGroup (where myAdminGroup is the admin group name on a remote openldap)
Then how can I generate the subject ? Should I ask for this in the "RBAC policy development" part of the forum ?

[Stephane]

Ok, still reading the doc ... so as far as I understand to do so I have to use the process & role based learning mode so :

domain restartapache g daemon bin www-data myAdminGroup
subject /usr/sbin/apache2 l