* [SECILC] does not seem to filter redundant attributes and rules @ 2016-11-09 12:40 Dominick Grift 2016-11-09 14:52 ` James Carter 0 siblings, 1 reply; 6+ messages in thread From: Dominick Grift @ 2016-11-09 12:40 UTC (permalink / raw) To: selinux [-- Attachment #1.1: Type: text/plain, Size: 1078 bytes --] I am in the process of a DSSP rewrite, taking a different approach this time. However I encountered something that seems suboptimal: SECILC seems to not filter redundant attributes and rules Example i have a type attribute and it has rules associated with it. However, the type attribute is not associated with any types. I was hoping that SECILC would be smart enough to determine that it might as well filter both the type attribute as well as the rules associated with it. To reproduce: git clone https://github.com/DefenSec/dssp1-base.git cd dssp1-base secilc `ls *.cil` sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30 seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30 Am i expecting the impossible by expecting SECILC to be smart enough to determine that something is redundant, and that it can be filtered out until it becomes applicable? -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 648 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SECILC] does not seem to filter redundant attributes and rules 2016-11-09 12:40 [SECILC] does not seem to filter redundant attributes and rules Dominick Grift @ 2016-11-09 14:52 ` James Carter 2016-11-09 18:17 ` Gary Tierney 2016-11-14 10:11 ` Dominick Grift 0 siblings, 2 replies; 6+ messages in thread From: James Carter @ 2016-11-09 14:52 UTC (permalink / raw) To: Dominick Grift, selinux On 11/09/2016 07:40 AM, Dominick Grift wrote: > I am in the process of a DSSP rewrite, taking a different approach this > time. > > However I encountered something that seems suboptimal: > > SECILC seems to not filter redundant attributes and rules > > Example i have a type attribute and it has rules associated with it. > However, the type attribute is not associated with any types. > > I was hoping that SECILC would be smart enough to determine that it > might as well filter both the type attribute as well as the rules > associated with it. > > To reproduce: > > git clone https://github.com/DefenSec/dssp1-base.git > cd dssp1-base > secilc `ls *.cil` > sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30 > seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30 > > > Am i expecting the impossible by expecting SECILC to be smart enough to > determine that something is redundant, and that it can be filtered out > until it becomes applicable? > > I don't think that it would be too hard to remove attributes that have no types associated with them along with rules containing those attributes. I have this nagging feeling, though, that there is a reason that we didn't do that. I'll have to think about it a bit. Jim > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > -- James Carter <jwcart2@tycho.nsa.gov> National Security Agency ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SECILC] does not seem to filter redundant attributes and rules 2016-11-09 14:52 ` James Carter @ 2016-11-09 18:17 ` Gary Tierney 2016-11-09 18:53 ` James Carter 2016-11-14 10:11 ` Dominick Grift 1 sibling, 1 reply; 6+ messages in thread From: Gary Tierney @ 2016-11-09 18:17 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 2731 bytes --] On Wed, Nov 09, 2016 at 09:52:35AM -0500, James Carter wrote: > On 11/09/2016 07:40 AM, Dominick Grift wrote: > >I am in the process of a DSSP rewrite, taking a different approach this > >time. > > > >However I encountered something that seems suboptimal: > > > >SECILC seems to not filter redundant attributes and rules > > > >Example i have a type attribute and it has rules associated with it. > >However, the type attribute is not associated with any types. > > > >I was hoping that SECILC would be smart enough to determine that it > >might as well filter both the type attribute as well as the rules > >associated with it. > > > >To reproduce: > > > >git clone https://github.com/DefenSec/dssp1-base.git > >cd dssp1-base > >secilc `ls *.cil` > >sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30 > >seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30 > > > > > >Am i expecting the impossible by expecting SECILC to be smart enough to > >determine that something is redundant, and that it can be filtered out > >until it becomes applicable? > > > > > > I don't think that it would be too hard to remove attributes that have no > types associated with them along with rules containing those attributes. I > have this nagging feeling, though, that there is a reason that we didn't do > that. I'll have to think about it a bit. > > Jim > I had a hack 'n' slash attempt at this earlier for just avrules by adding naive checks in avrule_write (libsepol/src/write.c) to check if both the source and target type_set bitmaps have a cardinality of 0, though couldn't help but think I was missing something else. That didn't work in any case, and didn't seem like the codepath is ever hit when a CIL policy is written to disk (maybe it's only module policy avrule_write is called for?). Any hints on where I can start prodding? Would be nice to get an idea of how the binary policy is serialized too. > > > > >_______________________________________________ > >Selinux mailing list > >Selinux@tycho.nsa.gov > >To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > >To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > > > > > -- > James Carter <jwcart2@tycho.nsa.gov> > National Security Agency > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. -- Gary Tierney GPG fingerprint: 412C 0EF9 C305 68E6 B660 BDAF 706E D765 85AA 79D8 https://sks-keyservers.net/pks/lookup?op=get&search=0x706ED76585AA79D8 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SECILC] does not seem to filter redundant attributes and rules 2016-11-09 18:17 ` Gary Tierney @ 2016-11-09 18:53 ` James Carter 0 siblings, 0 replies; 6+ messages in thread From: James Carter @ 2016-11-09 18:53 UTC (permalink / raw) To: selinux, Gary Tierney On 11/09/2016 01:17 PM, Gary Tierney wrote: > On Wed, Nov 09, 2016 at 09:52:35AM -0500, James Carter wrote: >> On 11/09/2016 07:40 AM, Dominick Grift wrote: >>> I am in the process of a DSSP rewrite, taking a different approach this >>> time. >>> >>> However I encountered something that seems suboptimal: >>> >>> SECILC seems to not filter redundant attributes and rules >>> >>> Example i have a type attribute and it has rules associated with it. >>> However, the type attribute is not associated with any types. >>> >>> I was hoping that SECILC would be smart enough to determine that it >>> might as well filter both the type attribute as well as the rules >>> associated with it. >>> >>> To reproduce: >>> >>> git clone https://github.com/DefenSec/dssp1-base.git >>> cd dssp1-base >>> secilc `ls *.cil` >>> sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30 >>> seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30 >>> >>> >>> Am i expecting the impossible by expecting SECILC to be smart enough to >>> determine that something is redundant, and that it can be filtered out >>> until it becomes applicable? >>> >>> >> >> I don't think that it would be too hard to remove attributes that have no >> types associated with them along with rules containing those attributes. I >> have this nagging feeling, though, that there is a reason that we didn't do >> that. I'll have to think about it a bit. >> >> Jim >> > > I had a hack 'n' slash attempt at this earlier for just avrules by adding > naive checks in avrule_write (libsepol/src/write.c) to check if both the > source and target type_set bitmaps have a cardinality of 0, though couldn't > help but think I was missing something else. That didn't work in any case, > and didn't seem like the codepath is ever hit when a CIL policy is > written to disk (maybe it's only module policy avrule_write is called for?). > > Any hints on where I can start prodding? Would be nice to get an idea of how > the binary policy is serialized too. >> In libsepol/src/write.c:policydb_write(), avtab_write(), and avtab_write_item() checks could be added, but I am not sure off the top of my head what they would look like. This would cause the rules to be removed for all kernel policies. For CIL only, in libsepol/cil/src/cil_binary.c:__cil_avrule_to_avtab() you could add a check for the src and tgt like the function below: static int cil_check_unused_attribute(struct cil_symtab_datum *datum) { struct cil_tree_node *node = datum->nodes->head->data; if (node->flavor == CIL_TYPEATTRIBUTE) { struct cil_typeattribute *attr = (struct cil_typeattribute *)datum; if (ebitmap_cardinality(attr->types) == 0) { return CIL_TRUE; } } return CIL_FALSE; } Jim >>> >>> _______________________________________________ >>> Selinux mailing list >>> Selinux@tycho.nsa.gov >>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. >>> >> >> >> -- >> James Carter <jwcart2@tycho.nsa.gov> >> National Security Agency >> _______________________________________________ >> Selinux mailing list >> Selinux@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > > > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > -- James Carter <jwcart2@tycho.nsa.gov> National Security Agency ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SECILC] does not seem to filter redundant attributes and rules 2016-11-09 14:52 ` James Carter 2016-11-09 18:17 ` Gary Tierney @ 2016-11-14 10:11 ` Dominick Grift 2016-11-14 11:18 ` Dominick Grift 1 sibling, 1 reply; 6+ messages in thread From: Dominick Grift @ 2016-11-14 10:11 UTC (permalink / raw) To: James Carter, selinux [-- Attachment #1.1: Type: text/plain, Size: 2542 bytes --] On 11/09/2016 03:52 PM, James Carter wrote: > On 11/09/2016 07:40 AM, Dominick Grift wrote: >> I am in the process of a DSSP rewrite, taking a different approach this >> time. >> >> However I encountered something that seems suboptimal: >> >> SECILC seems to not filter redundant attributes and rules >> >> Example i have a type attribute and it has rules associated with it. >> However, the type attribute is not associated with any types. >> >> I was hoping that SECILC would be smart enough to determine that it >> might as well filter both the type attribute as well as the rules >> associated with it. >> >> To reproduce: >> >> git clone https://github.com/DefenSec/dssp1-base.git >> cd dssp1-base >> secilc `ls *.cil` >> sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30 >> seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30 >> >> >> Am i expecting the impossible by expecting SECILC to be smart enough to >> determine that something is redundant, and that it can be filtered out >> until it becomes applicable? >> >> > > I don't think that it would be too hard to remove attributes that have > no types associated with them along with rules containing those > attributes. I have this nagging feeling, though, that there is a reason > that we didn't do that. I'll have to think about it a bit. > > Jim Have you given this some thought? I suspect this could have significant impact. consider the following: CIL encourages the use of attributes to the fullest extent, and with dssp1 i have taken this to heart. This should make dssp1 very scale-able. The more an identifier is used the greater the potential benefit. Attributes and templates are at the heart of dssp1 and if the dssp1 model turns out to work (it is still a work in progress and I dont quite see where this is eventually taking me) then this would be a very welcome feature. If you want to see the current state of dssp1: git clone https://github.com/DefenSec/dssp1-base.git cd dssp1-base secilc `ls *.cil` seinfo policy.30 > > >> >> _______________________________________________ >> Selinux mailing list >> Selinux@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to >> Selinux-request@tycho.nsa.gov. >> > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 648 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SECILC] does not seem to filter redundant attributes and rules 2016-11-14 10:11 ` Dominick Grift @ 2016-11-14 11:18 ` Dominick Grift 0 siblings, 0 replies; 6+ messages in thread From: Dominick Grift @ 2016-11-14 11:18 UTC (permalink / raw) To: selinux [-- Attachment #1.1: Type: text/plain, Size: 2871 bytes --] On 11/14/2016 11:11 AM, Dominick Grift wrote: > On 11/09/2016 03:52 PM, James Carter wrote: >> On 11/09/2016 07:40 AM, Dominick Grift wrote: >>> I am in the process of a DSSP rewrite, taking a different approach this >>> time. >>> >>> However I encountered something that seems suboptimal: >>> >>> SECILC seems to not filter redundant attributes and rules >>> >>> Example i have a type attribute and it has rules associated with it. >>> However, the type attribute is not associated with any types. >>> >>> I was hoping that SECILC would be smart enough to determine that it >>> might as well filter both the type attribute as well as the rules >>> associated with it. >>> >>> To reproduce: >>> >>> git clone https://github.com/DefenSec/dssp1-base.git >>> cd dssp1-base >>> secilc `ls *.cil` >>> sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30 >>> seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30 >>> >>> >>> Am i expecting the impossible by expecting SECILC to be smart enough to >>> determine that something is redundant, and that it can be filtered out >>> until it becomes applicable? >>> >>> >> >> I don't think that it would be too hard to remove attributes that have >> no types associated with them along with rules containing those >> attributes. I have this nagging feeling, though, that there is a reason >> that we didn't do that. I'll have to think about it a bit. >> >> Jim > > Have you given this some thought? > > I suspect this could have significant impact. > > consider the following: > > CIL encourages the use of attributes to the fullest extent, and with > dssp1 i have taken this to heart. > > This should make dssp1 very scale-able. The more an identifier is used > the greater the potential benefit. > > Attributes and templates are at the heart of dssp1 and if the dssp1 > model turns out to work (it is still a work in progress and I dont quite > see where this is eventually taking me) then this would be a very > welcome feature. > > If you want to see the current state of dssp1: > > git clone https://github.com/DefenSec/dssp1-base.git > cd dssp1-base > secilc `ls *.cil` > seinfo policy.30 Here is a 10 minute demo that tries to explain the benefits and the current drawbacks of this approach (for anyone interested) https://www.youtube.com/watch?v=MdqjVgjXvM8 > >> >> >>> >>> _______________________________________________ >>> Selinux mailing list >>> Selinux@tycho.nsa.gov >>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>> To get help, send an email containing "help" to >>> Selinux-request@tycho.nsa.gov. >>> >> >> > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 648 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-11-14 11:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-09 12:40 [SECILC] does not seem to filter redundant attributes and rules Dominick Grift 2016-11-09 14:52 ` James Carter 2016-11-09 18:17 ` Gary Tierney 2016-11-09 18:53 ` James Carter 2016-11-14 10:11 ` Dominick Grift 2016-11-14 11:18 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.