* 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.