On Tue, Feb 22, 2022 at 9:17 AM Christian Göttsche
<cgzones@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
> ---
> 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
