<snip> > > >> On May 6, 2016 11:58 AM, "James Carter" <jwcart2@xxxxxxxxxxxxx> wrote: > > >>> > > >>> The removal of attributes that are only used in neverallow rules > > >>> is hindering AOSP adoption of the CIL compiler. This is because > > >>> AOSP extracts neverallow rules from its policy.conf for use in the > > >>> Android compatibility test suite. These neverallow rules are > > >>> applied against the binary policy being tested to check for a > > >>> violation. Any neverallow rules with an attribute that has been > > >>> removed cannot be > > checked. > > >>> > > >>> Now attributes are kept unless they are not used in any allow rule > > >>> and they are auto-generated or named "cil_gen_require" or do not > > >>> have any types associated with them. > > >> > > >> I see now, you’re keeping them unless they are generated or marked. > > > > > > I'm still not convinced this does what's on the tin. In the case of > > > AOSP, the Attributes are not used in any allow rules, they are not > > > auto-generated or named cil_gen_require And they will not have any > > > types > > associated with them. So I see them being discarded. > > > > > > > If they don't have types associated with them, then I misunderstood > > the problem and we will have to keep the attributes without types around. > > This is pretty much all my understanding on this issue is from this link: > > Per sds: > https://android-review.googlesource.com/#/c/145034/ > > "CIL also deletes unused attributes from the kernel policy, which is a problem for > the Android neverallow checking. It considers an attribute that is only referenced > by a neverallow rule to be unused since neverallows are not included in the > kernel policy, so this drops data_file_type from the kernel policy. But we then > would lose checking of the various neverallows on data_file_type by CTS." - sds > > Looking through the policy in file.te: > > file.te:151:type app_data_file, file_type, data_file_type; file.te:153:type > system_app_data_file, file_type, data_file_type, mlstrustedobject; > file.te:169:type asec_apk_file, file_type, data_file_type, mlstrustedobject; > file.te:171:type asec_public_file, file_type, data_file_type; file.te:173:type > asec_image_file, file_type, data_file_type; file.te:175:type backup_data_file, > file_type, data_file_type, mlstrustedobject; > > Data file type does have type associations, but it does NOT have allow rules. > > So when this gets generated to cil, how is indicated in cil intermediary not to > discard that data_file_type attribute? > That’s not the question I meant to ask. The cardinality check would be sufficient there. In other words, this LGTM. I am going to restore sds's changes and try this. Thanks. <snip> _______________________________________________ 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.
