Is this a bug in sesearch, or ...?

Is this a bug in sesearch, or ...?

[Dominick Grift]

I was explaining the concept of (type) attributes using the domain type
attribute as an example on IRC, and a sharp person embarrassed me by
noting that the following rule returns nothing where he would have
expected something:

sesearch -A -d -s domain -c process -p fork

Why does this not return anything? Is is because the target is "self"?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is this a bug in sesearch, or ...?

[Joshua Brindle]

Dominick Grift wrote:
> I was explaining the concept of (type) attributes using the domain type
> attribute as an example on IRC, and a sharp person embarrassed me by
> noting that the following rule returns nothing where he would have
> expected something:
>
> sesearch -A -d -s domain -c process -p fork
>
> Why does this not return anything? Is is because the target is "self"?

"self" is resolved by the compiler, it isn't present in the kernel binary.

You specified -d "do not search for type's attributes" and then gave an 
attribute as the source. I'm not sure what the intended behavior was but 
excluding the -d gave me back a large set of rules.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is this a bug in sesearch, or ...?

[Dominick Grift]

On Sun, 2013-09-15 at 12:54 -0400, Joshua Brindle wrote:
> Dominick Grift wrote:
> > I was explaining the concept of (type) attributes using the domain type
> > attribute as an example on IRC, and a sharp person embarrassed me by
> > noting that the following rule returns nothing where he would have
> > expected something:
> >
> > sesearch -A -d -s domain -c process -p fork
> >
> > Why does this not return anything? Is is because the target is "self"?
> 
> "self" is resolved by the compiler, it isn't present in the kernel binary.
> 
> You specified -d "do not search for type's attributes" and then gave an 
> attribute as the source. I'm not sure what the intended behavior was but 
> excluding the -d gave me back a large set of rules.

The result i expected would have been the exact (direct) rule as
specified in the policy:

allow domain self : process fork;

So not the large list that one gets without the -d option because that
is not the direct rule

> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is this a bug in sesearch, or ...?

[Stephen Smalley]

On 09/16/2013 03:35 AM, Dominick Grift wrote:
> On Sun, 2013-09-15 at 12:54 -0400, Joshua Brindle wrote:
>> Dominick Grift wrote:
>>> I was explaining the concept of (type) attributes using the domain type
>>> attribute as an example on IRC, and a sharp person embarrassed me by
>>> noting that the following rule returns nothing where he would have
>>> expected something:
>>>
>>> sesearch -A -d -s domain -c process -p fork
>>>
>>> Why does this not return anything? Is is because the target is "self"?
>>
>> "self" is resolved by the compiler, it isn't present in the kernel binary.
>>
>> You specified -d "do not search for type's attributes" and then gave an 
>> attribute as the source. I'm not sure what the intended behavior was but 
>> excluding the -d gave me back a large set of rules.
> 
> The result i expected would have been the exact (direct) rule as
> specified in the policy:
> 
> allow domain self : process fork;
> 
> So not the large list that one gets without the -d option because that
> is not the direct rule

direct means "granted to an individual type, not via attribute".  So it
omits any rules written in terms of attributes.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is this a bug in sesearch, or ...?

[Dominick Grift]

On Mon, 2013-09-16 at 07:57 -0400, Stephen Smalley wrote:
> On 09/16/2013 03:35 AM, Dominick Grift wrote:
> > On Sun, 2013-09-15 at 12:54 -0400, Joshua Brindle wrote:
> >> Dominick Grift wrote:
> >>> I was explaining the concept of (type) attributes using the domain type
> >>> attribute as an example on IRC, and a sharp person embarrassed me by
> >>> noting that the following rule returns nothing where he would have
> >>> expected something:
> >>>
> >>> sesearch -A -d -s domain -c process -p fork
> >>>
> >>> Why does this not return anything? Is is because the target is "self"?
> >>
> >> "self" is resolved by the compiler, it isn't present in the kernel binary.
> >>
> >> You specified -d "do not search for type's attributes" and then gave an 
> >> attribute as the source. I'm not sure what the intended behavior was but 
> >> excluding the -d gave me back a large set of rules.
> > 
> > The result i expected would have been the exact (direct) rule as
> > specified in the policy:
> > 
> > allow domain self : process fork;
> > 
> > So not the large list that one gets without the -d option because that
> > is not the direct rule
> 
> direct means "granted to an individual type, not via attribute".  So it
> omits any rules written in terms of attributes.
> 

Thanks, alright this is probably last attempt to understand this but really that is not my experience:

Take for example this comparison:

# sesearch -A -d -t file_type  | head -n 3
Found 383 semantic av rules:
   allow prelude_lml_t file_type : filesystem getattr ; 
   allow files_unconfined_type file_type : filesystem { mount remount
unmount getattr relabelfrom relabelto transition associate quotamod
quotaget } ; 

# sesearch -A -t file_type  | head -n 3
Found 40415 semantic av rules:
   allow mscan_var_run_t mscan_var_run_t : filesystem associate ; 
   allow xguest_usertype tetex_data_t : lnk_file { read getattr } ; 

The former does not "expand" the target type attribute whereas the
latter expands the type attribute









--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is this a bug in sesearch, or ...?

[Dominick Grift]

On Mon, 2013-09-16 at 14:07 +0200, Dominick Grift wrote:
> On Mon, 2013-09-16 at 07:57 -0400, Stephen Smalley wrote:
> > On 09/16/2013 03:35 AM, Dominick Grift wrote:
> > > On Sun, 2013-09-15 at 12:54 -0400, Joshua Brindle wrote:
> > >> Dominick Grift wrote:
> > >>> I was explaining the concept of (type) attributes using the domain type
> > >>> attribute as an example on IRC, and a sharp person embarrassed me by
> > >>> noting that the following rule returns nothing where he would have
> > >>> expected something:
> > >>>
> > >>> sesearch -A -d -s domain -c process -p fork
> > >>>
> > >>> Why does this not return anything? Is is because the target is "self"?
> > >>
> > >> "self" is resolved by the compiler, it isn't present in the kernel binary.
> > >>
> > >> You specified -d "do not search for type's attributes" and then gave an 
> > >> attribute as the source. I'm not sure what the intended behavior was but 
> > >> excluding the -d gave me back a large set of rules.
> > > 
> > > The result i expected would have been the exact (direct) rule as
> > > specified in the policy:
> > > 
> > > allow domain self : process fork;
> > > 
> > > So not the large list that one gets without the -d option because that
> > > is not the direct rule
> > 
> > direct means "granted to an individual type, not via attribute".  So it
> > omits any rules written in terms of attributes.
> > 
> 
> Thanks, alright this is probably last attempt to understand this but really that is not my experience:
> 
> Take for example this comparison:
> 
> # sesearch -A -d -t file_type  | head -n 3
> Found 383 semantic av rules:
>    allow prelude_lml_t file_type : filesystem getattr ; 
>    allow files_unconfined_type file_type : filesystem { mount remount
> unmount getattr relabelfrom relabelto transition associate quotamod
> quotaget } ; 
> 
> # sesearch -A -t file_type  | head -n 3
> Found 40415 semantic av rules:
>    allow mscan_var_run_t mscan_var_run_t : filesystem associate ; 
>    allow xguest_usertype tetex_data_t : lnk_file { read getattr } ; 
> 
> The former does not "expand" the target type attribute whereas the
> latter expands the type attribute
> 

Scratch the above. it now starts to sink in slowly here ( must be monday
)

So in that case would be nice if we have the functionality to query type
attribute av rules without them being expanded.

> 
> 
> 
> 
> 
> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is this a bug in sesearch, or ...?

[Stephen Smalley]

On 09/16/2013 08:07 AM, Dominick Grift wrote:
> On Mon, 2013-09-16 at 07:57 -0400, Stephen Smalley wrote:
>> On 09/16/2013 03:35 AM, Dominick Grift wrote:
>>> On Sun, 2013-09-15 at 12:54 -0400, Joshua Brindle wrote:
>>>> Dominick Grift wrote:
>>>>> I was explaining the concept of (type) attributes using the domain type
>>>>> attribute as an example on IRC, and a sharp person embarrassed me by
>>>>> noting that the following rule returns nothing where he would have
>>>>> expected something:
>>>>>
>>>>> sesearch -A -d -s domain -c process -p fork
>>>>>
>>>>> Why does this not return anything? Is is because the target is "self"?
>>>>
>>>> "self" is resolved by the compiler, it isn't present in the kernel binary.
>>>>
>>>> You specified -d "do not search for type's attributes" and then gave an 
>>>> attribute as the source. I'm not sure what the intended behavior was but 
>>>> excluding the -d gave me back a large set of rules.
>>>
>>> The result i expected would have been the exact (direct) rule as
>>> specified in the policy:
>>>
>>> allow domain self : process fork;
>>>
>>> So not the large list that one gets without the -d option because that
>>> is not the direct rule
>>
>> direct means "granted to an individual type, not via attribute".  So it
>> omits any rules written in terms of attributes.
>>
> 
> Thanks, alright this is probably last attempt to understand this but really that is not my experience:
> 
> Take for example this comparison:
> 
> # sesearch -A -d -t file_type  | head -n 3
> Found 383 semantic av rules:
>    allow prelude_lml_t file_type : filesystem getattr ; 
>    allow files_unconfined_type file_type : filesystem { mount remount
> unmount getattr relabelfrom relabelto transition associate quotamod
> quotaget } ; 
> 
> # sesearch -A -t file_type  | head -n 3
> Found 40415 semantic av rules:
>    allow mscan_var_run_t mscan_var_run_t : filesystem associate ; 
>    allow xguest_usertype tetex_data_t : lnk_file { read getattr } ; 
> 
> The former does not "expand" the target type attribute whereas the
> latter expands the type attribute

Interesting, I guess that's a bug to report to the setools folks.
So does it only behave differently on self rules or does it behave
differently on source vs target?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.