On Sat, May 02, 2015 at 05:02:59PM +0200, Dominick Grift wrote: > Today i hit an bug in secilc, when compiled by policy with some modules excluded. > > My policy is rather complex, and so i find the issue hard to explain but i will try: > > In my github.com/doverride/laptop policy (the auth.cil module to be precise) i have a auth_pam_config_object_type() macro that > essentially associates the calling type with the auth_pam_config_object_type type attribute, which in turn is associated with > the auth_object_type attribute that is used to grant auth_admin() access to all "auth object types" > > The auth_pam_config_object_type() macro is called in various modules for various third party pam config files. > > For example, xserver maintains /etc/pam.d/xserver, which is associated with xserver_pam_config_t, and xserver_pam_config_t is > associated with auth_pam_config_object_type. > > This is just one example. > > By excluding the xserver.cil module, the whole auth_pam_config_object_type, and all rules associated with it vanishes. > I noticed today that on a system where i excluded xserver.cil i no longer had access to /etc/security/access.conf (which is > associated with pam_config_t, and pam_config_t is associated with auth_pam_config_object_type) > > By reincluding the xserver.cil module , the rules that allow auth_admin() to maintain auth_object_type files reappeared. > > To reproduce: > > clone my "laptop" policy and build it > > use "sesearch -A -s auth_admin_subject_type | grep auth_object_type" to confirm that auth_admin_subject_type is allowed > to maintain file objects associated with auth_object_type > > Now exclude the xserver.cil module > > use above sesearch command again and notice how the rules granting auth_admin_subject_type access to maintain file objects > associated with auth_object_type have vanished. > > P.S: > Another really strange thing i noticed is that i have a compiled policy with a bunch of modules excluded that is bigger than > a policy with little or no modules excluded. > I want to retract this. This was most likely a parens issue to begin with. Today i hit a similar issue and i decided to dig a little deeper. Granted the issue i hit today was much simpler to track down. Anyhow it turned out to be a misplaced parens which resulted in secilc removing a lot of policy that it thought was in one optional block. in reality they were many optional blocks but the first one wasnt closed properly! Yes, the secilc warning about "open without close" or "close without open" are annoying. but take my word for it. its much better to have secilc identify these issues then to have it not identify them and then when you decide to exclude a module a whole load of policy gets removed because secilc thought it was part of the single block! anyhow sorry for thinking this was a bug in secilc. it was my mistake. in my defense though: my policy is pretty complex and sometimes its not easy to identify the issue. Also parens arent that friendly to humans...
Attachment:
pgpF0fpZZ30ND.pgp
Description: PGP signature
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
