[SECILC] does not seem to filter redundant attributes and rules

[SECILC] does not seem to filter redundant attributes and rules

[Dominick Grift]

[-- 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 --]

Re: [SECILC] does not seem to filter redundant attributes and rules

[James Carter]

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

Re: [SECILC] does not seem to filter redundant attributes and rules

[Gary Tierney]

[-- 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 --]

Re: [SECILC] does not seem to filter redundant attributes and rules

[James Carter]

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

Re: [SECILC] does not seem to filter redundant attributes and rules

[Dominick Grift]

[-- 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 --]

Re: [SECILC] does not seem to filter redundant attributes and rules

[Dominick Grift]

[-- 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 --]