All of lore.kernel.org
 help / color / mirror / Atom feed
* setoolsv4: tracking origin of a policy element
@ 2015-10-26 11:20 Elena Reshetova
  2015-10-26 13:16 ` Christopher J. PeBenito
  0 siblings, 1 reply; 4+ messages in thread
From: Elena Reshetova @ 2015-10-26 11:20 UTC (permalink / raw)
  To: SELinux; +Cc: filippo.bonazzi, William Roberts

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

Hi,

While looking into the policy parser from setools v4, we noticed one thing
that is missing: origin of a policy element. For example, given a certain
rule or attribute, it would be great to know in what source file it was
defined.

In Android you can find this information by looking at produced policy.conf
and its comment lines that indicate source file. However I don't know if it
is the same for desktop selinux policy.

Would it be acceptable to have this information as part of python class
representing the parsed policy? It would be really useful for tools like
policy linter, because it would be very much needed to point to the exact
file where some improvements might be desirable.

Best Regards,
Elena.

[-- Attachment #2: Type: text/html, Size: 834 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: setoolsv4: tracking origin of a policy element
  2015-10-26 11:20 setoolsv4: tracking origin of a policy element Elena Reshetova
@ 2015-10-26 13:16 ` Christopher J. PeBenito
  2015-11-10 15:45   ` Filippo Bonazzi
  0 siblings, 1 reply; 4+ messages in thread
From: Christopher J. PeBenito @ 2015-10-26 13:16 UTC (permalink / raw)
  To: Elena Reshetova, SELinux; +Cc: filippo.bonazzi

On 10/26/2015 7:20 AM, Elena Reshetova wrote:
> While looking into the policy parser from setools v4, we noticed one
> thing that is missing: origin of a policy element. For example, given a
> certain rule or attribute, it would be great to know in what source file
> it was defined.
> 
> In Android you can find this information by looking at produced
> policy.conf and its comment lines that indicate source file. However I
> don't know if it is the same for desktop selinux policy.
> 
> Would it be acceptable to have this information as part of python class
> representing the parsed policy? It would be really useful for tools like
> policy linter, because it would be very much needed to point to the

That would be acceptable.  Past versions of SETools supported that, but
it has not yet been a priority for v4.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: setoolsv4: tracking origin of a policy element
  2015-10-26 13:16 ` Christopher J. PeBenito
@ 2015-11-10 15:45   ` Filippo Bonazzi
  2015-11-10 16:33     ` Christopher J. PeBenito
  0 siblings, 1 reply; 4+ messages in thread
From: Filippo Bonazzi @ 2015-11-10 15:45 UTC (permalink / raw)
  To: Christopher J. PeBenito, Elena Reshetova, SELinux

>> given a certain rule or attribute, it would be great to know in what source file it was defined.
> Past versions of SETools supported that, but it has not yet been a priority for v4.
Which previous version(s) of SETools supported origin file/line information?

I have scoured the setools3 libqpol source files for this, and I have
found that the file/line information from the m4 synclines is parsed by
Lex at libqpol/src/policy_scan.l:272-273. However, this information is
only used in the yyerror and yywarn functions, and is not actually
propagated in the policy.

Furthermore, I have searched the SELinux libsepol source files to see
where that information could be saved, and I found that only the avrule
data structure (libsepol/include/sepol/policydb/policydb.h:258) supports
saving origin file/line information in the source_filename(:287) and
source_line(:288) fields.
All other rules, attributes, types etc. do not contain this information.

How could one then parse, save and expose origin file/line information
for all or most policy elements?

Thank you

Filippo Bonazzi


On 10/26/2015 03:16 PM, Christopher J. PeBenito wrote:
> On 10/26/2015 7:20 AM, Elena Reshetova wrote:
>> While looking into the policy parser from setools v4, we noticed one
>> thing that is missing: origin of a policy element. For example, given a
>> certain rule or attribute, it would be great to know in what source file
>> it was defined.
>>
>> In Android you can find this information by looking at produced
>> policy.conf and its comment lines that indicate source file. However I
>> don't know if it is the same for desktop selinux policy.
>>
>> Would it be acceptable to have this information as part of python class
>> representing the parsed policy? It would be really useful for tools like
>> policy linter, because it would be very much needed to point to the
> That would be acceptable.  Past versions of SETools supported that, but
> it has not yet been a priority for v4.
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: setoolsv4: tracking origin of a policy element
  2015-11-10 15:45   ` Filippo Bonazzi
@ 2015-11-10 16:33     ` Christopher J. PeBenito
  0 siblings, 0 replies; 4+ messages in thread
From: Christopher J. PeBenito @ 2015-11-10 16:33 UTC (permalink / raw)
  To: Filippo Bonazzi, Elena Reshetova, SELinux

On 11/10/2015 10:45 AM, Filippo Bonazzi wrote:
>>> given a certain rule or attribute, it would be great to know in what source file it was defined.
>> Past versions of SETools supported that, but it has not yet been a priority for v4.
> Which previous version(s) of SETools supported origin file/line information?

I should have been clearer.  The support in setools3 for line numbers
was limited to the final source file for monolithic policies
(policy.conf).  So you loaded a policy.conf, you could get the line
number in policy.conf and that's it.  There was no traceback to policy
module (*.pp) nor to source module (*.te).



> I have scoured the setools3 libqpol source files for this, and I have
> found that the file/line information from the m4 synclines is parsed by
> Lex at libqpol/src/policy_scan.l:272-273. However, this information is
> only used in the yyerror and yywarn functions, and is not actually
> propagated in the policy.
> 
> Furthermore, I have searched the SELinux libsepol source files to see
> where that information could be saved, and I found that only the avrule
> data structure (libsepol/include/sepol/policydb/policydb.h:258) supports
> saving origin file/line information in the source_filename(:287) and
> source_line(:288) fields.
> All other rules, attributes, types etc. do not contain this information.
> 
> How could one then parse, save and expose origin file/line information
> for all or most policy elements?
> 
> Thank you
> 
> Filippo Bonazzi
> 
> 
> On 10/26/2015 03:16 PM, Christopher J. PeBenito wrote:
>> On 10/26/2015 7:20 AM, Elena Reshetova wrote:
>>> While looking into the policy parser from setools v4, we noticed one
>>> thing that is missing: origin of a policy element. For example, given a
>>> certain rule or attribute, it would be great to know in what source file
>>> it was defined.
>>>
>>> In Android you can find this information by looking at produced
>>> policy.conf and its comment lines that indicate source file. However I
>>> don't know if it is the same for desktop selinux policy.
>>>
>>> Would it be acceptable to have this information as part of python class
>>> representing the parsed policy? It would be really useful for tools like
>>> policy linter, because it would be very much needed to point to the
>> That would be acceptable.  Past versions of SETools supported that, but
>> it has not yet been a priority for v4.
>>
> 


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-11-10 16:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-26 11:20 setoolsv4: tracking origin of a policy element Elena Reshetova
2015-10-26 13:16 ` Christopher J. PeBenito
2015-11-10 15:45   ` Filippo Bonazzi
2015-11-10 16:33     ` Christopher J. PeBenito

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.