Re: secilc bug

[Steve Lawrence <slawrence@tresys.com>]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

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

[-- Attachment #2: EXCLUDE --]
[-- Type: text/plain, Size: 959 bytes --]

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