On 05/04/2015 11:19 AM, James Carter wrote: > On 05/03/2015 06:50 AM, Dominick Grift wrote: >> 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. >> >> <snip> >> >> I suspect the issue is something like the following: >> >> There are currently no rules associated with the >> pam_auth_config_object_type type attribute thus it will be removed >> from the policy by secilc >> >> However this may or may not change. I do have macros with rules assoc. >> with pam_auth_config_object_type, they are currently just not called >> by anything >> >> In my policy, the pam_auth_config_object_type type attribute currently >> only acts as a bridge to auth_object_type type attribute >> >> Example: pam_config_t (and many other types) is/are assoc. with >> auth_pam_config_object_type, auth_pam_config_object_type is associated >> with auth_object_type, and there are rules assoc. with auth_object_type >> >> (for example: auth_admin_subject_type auth_object_type >> (all_file_objects (all_file_perms_except))) >> >> The question remains, how does me exluding the xserver.cil affects all >> this. I actually commented out the only call to >> the auth.cil module ( (call auth_pam_config_object_type >> (xserver_pam_config_t)) ) from the xserver module and it turns out to not >> affect it. So it is not that macro call. >> >> It may instead be another ordering issue... >> > > There doesn't seem to be ordering issues related to typeattributeset > statements. See attached test policy if you're interested. > >> E.g. excluding the xserver.cil module may mess up the ordering of the >> modules to process in such a way that this rule vanishes >> >> Because that is what this issue boils down to: rules vanishing for no >> reason >> >> I made a screencast that tries to explain the issue: >> >> https://www.youtube.com/watch?v=XRp5z9aqLDo >> >> > > I think that it would be more helpful to me if I could see the policy. > Is it available anywhere? If not, could you send me at least the > auth.cil and xserver.cil modules? > I think this might be a reset issue, with classmappings or something related to classmappings not getting reset/re-resolved correctly. I've noticed that with xserver.cil removed, some optional fails and causes a re-resolve. Then when writing to the binary, the allow rule mentioned ends up with all perms being empty, and so the allow rule is never added. Note I also needed to modify EXCLUDE to exclude a handful of files due to dependencies with xserver. I've attached that file. - Steve
tests/ sources/modules/contrib/applications/setbacklight.cil sources/modules/contrib/applications/b43fwcutter.cil sources/modules/contrib/services/bluetooth.cil sources/modules/contrib/system/myqemu.cil sources/modules/contrib/system/tunctl.cil sources/modules/contrib/system/bridgeutil.cil sources/modules/contrib/applications/firefox.cil sources/modules/contrib/applications/qiv.cil sources/modules/contrib/applications/xpdf.cil sources/modules/contrib/applications/xutil.cil sources/modules/contrib/applications/dunst.cil sources/modules/contrib/applications/xlock.cil sources/modules/contrib/applications/xterm.cil sources/modules/contrib/applications/xbindkeys.cil sources/modules/contrib/applications/rp.cil sources/modules/contrib/applications/dbuslaunch.cil sources/modules/contrib/applications/ffmpeg.cil sources/modules/contrib/applications/mplayer.cil sources/modules/contrib/applications/cowsay.cil sources/modules/contrib/applications/atspi2.cil
_______________________________________________ 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.
