| Message ID | 20220222135435.31216-3-cgzones@googlemail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | fbba23933cac |
| Headers | show |
| Series | [RFC,v2,1/4] libsepol: add sepol_av_perm_to_string | expand |
On Tue, Feb 22, 2022 at 9:17 AM Christian Göttsche <cgzones@googlemail.com> wrote: > > Export functions needed for converting security identifiers from and to > strings and functions computing security server decisions. These can > be used to debug or run tests on binary policies without running on a > SELinux enabled kernel. > > TODO: > These functions have currently a non consistent return behavior: some > are returning -1 on failure and set errno most but not all of the time, > some return a negative errno like value. > Maybe this should be addressed before exporting them? > > Signed-off-by: Christian Göttsche <cgzones@googlemail.com> > --- > libsepol/src/libsepol.map.in | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/libsepol/src/libsepol.map.in b/libsepol/src/libsepol.map.in > index 0e05d606..844924fc 100644 > --- a/libsepol/src/libsepol.map.in > +++ b/libsepol/src/libsepol.map.in > @@ -274,3 +274,18 @@ LIBSEPOL_3.0 { > cil_write_resolve_ast; > cil_set_qualified_names; > } LIBSEPOL_1.1; > + > +LIBSEPOL_3.4 { > + global: > + sepol_av_perm_to_string; > + sepol_change_sid; > + sepol_compute_av; > + sepol_compute_av_reason; > + sepol_compute_av_reason_buffer; > + sepol_context_to_sid; > + sepol_member_sid; > + sepol_sid_to_context; > + sepol_string_to_av_perm; > + sepol_string_to_security_class; > + sepol_validate_transition_reason_buffer; > +} LIBSEPOL_3.0; > -- > 2.35.1 > I am a bit conflicted. I like this patch series and see the value in exporting these functions, but I really don't want to export functions from include/sepol/policydb/. We have three already that have slipped through: expand_module_avrules(), sepol_polcap_getnum(), and sepol_polcap_getname(). Keeping the exported functions in include/sepol makes it easier to see what is exported. At least in this case the data structures involved aren't going to cause problems later as sepol_security_id_t and sepol_access_vector_t are both unit32_t, sepol_security_class_t is a unit16_t, and even struct sepol_av_decision consists of sepol_access_vector_t and uint32_t members. We don't want external programs strongly relying on the details of the data structures in include/sepol/policydb. It was kind of a mess when the named transitions were moved from a list to a hash table. Since most of these functions are used in either checkpolicy or audit2why (or both), it is probably fine to export these, but I would appreciate any thoughts that Chris and others might have. Jim
diff --git a/libsepol/src/libsepol.map.in b/libsepol/src/libsepol.map.in index 0e05d606..844924fc 100644 --- a/libsepol/src/libsepol.map.in +++ b/libsepol/src/libsepol.map.in @@ -274,3 +274,18 @@ LIBSEPOL_3.0 { cil_write_resolve_ast; cil_set_qualified_names; } LIBSEPOL_1.1; + +LIBSEPOL_3.4 { + global: + sepol_av_perm_to_string; + sepol_change_sid; + sepol_compute_av; + sepol_compute_av_reason; + sepol_compute_av_reason_buffer; + sepol_context_to_sid; + sepol_member_sid; + sepol_sid_to_context; + sepol_string_to_av_perm; + sepol_string_to_security_class; + sepol_validate_transition_reason_buffer; +} LIBSEPOL_3.0;
Export functions needed for converting security identifiers from and to strings and functions computing security server decisions. These can be used to debug or run tests on binary policies without running on a SELinux enabled kernel. TODO: These functions have currently a non consistent return behavior: some are returning -1 on failure and set errno most but not all of the time, some return a negative errno like value. Maybe this should be addressed before exporting them? Signed-off-by: Christian Göttsche <cgzones@googlemail.com> --- libsepol/src/libsepol.map.in | 15 +++++++++++++++ 1 file changed, 15 insertions(+)