.gitignore | 1 + xen/xsm/flask/Makefile | 5 ++++- xen/xsm/flask/policy/mkselim.sh | 17 +++++++++++++++++ xen/xsm/flask/ss/sidtab.c | 3 ++- 4 files changed, 24 insertions(+), 2 deletions(-) create mode 100755 xen/xsm/flask/policy/mkselim.sh
Currently Xen lacks a defined largest number of security IDs it can potentially
use. The number of SIDs are naturally limited by number of security contexts
provided by a given security policy, i.e. how many combination of user, role
and type there can be, and is dependant on the policy being used.
Thus in Xen the number of allocated entries in sidtable is hard-limited by UINT_MAX.
However in the embedded environment configured for safety it is desirable to
avoid guest-triggered dynamic memory allocations at runtime, or at least limit
them to some decent amounts. So we seek to estimate this limit.
This patch suggests one way to do it using Xen's flask policy.
List of users, roles and types is read from binary policy using setools utils,
then it is used to count the No. of combinations these values can give.
This No. of combinations then can be used in code as a practical replacement
of UINT_MAX limit. Also it can be used later to pre-allocate sidtable at boot
and avoid runtime entries allocation altogether.
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
This RFC presents a concept of estimating a max possible sidtable size.
Can we discuss how valid this concept is? Currently it yields 420 as max SID,
is it a reasonable number? Or perhaps something not being taken into account?
(it lacks MLS/MCS support, because it's currently disabled in Xen's policy
and I'm not sure if it's usable)
-Sergiy
---
.gitignore | 1 +
xen/xsm/flask/Makefile | 5 ++++-
xen/xsm/flask/policy/mkselim.sh | 17 +++++++++++++++++
xen/xsm/flask/ss/sidtab.c | 3 ++-
4 files changed, 24 insertions(+), 2 deletions(-)
create mode 100755 xen/xsm/flask/policy/mkselim.sh
diff --git a/.gitignore b/.gitignore
index 53f5df0003..b03e63b7a0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -241,6 +241,7 @@ xen/xsm/flask/include/av_permissions.h
xen/xsm/flask/include/class_to_string.h
xen/xsm/flask/include/flask.h
xen/xsm/flask/include/initial_sid_to_string.h
+xen/xsm/flask/include/se_limits.h
xen/xsm/flask/policy.*
xen/xsm/flask/xenpolicy-*
tools/flask/policy/policy.conf
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 3fdcf7727e..8acc5efcf1 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -14,7 +14,7 @@ AV_H_DEPEND := $(srcdir)/policy/access_vectors
FLASK_H_FILES := flask.h class_to_string.h initial_sid_to_string.h
AV_H_FILES := av_perm_to_string.h av_permissions.h
-ALL_H_FILES := $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES))
+ALL_H_FILES := $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES) se_limits.h)
# Adding prerequisite to descending into ss/ folder only when not running
# `make *clean`.
@@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE
FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC)
cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@
+$(obj)/%/se_limits.h: $(obj)/policy.bin
+ $(srcdir)/policy/mkselim.sh $^ $@
+
clean-files := policy.* $(POLICY_SRC)
diff --git a/xen/xsm/flask/policy/mkselim.sh b/xen/xsm/flask/policy/mkselim.sh
new file mode 100755
index 0000000000..bda99727fa
--- /dev/null
+++ b/xen/xsm/flask/policy/mkselim.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+policy=$1
+output_file=$2
+ntypes=$(seinfo --flat $policy -t | wc -l)
+nroles=$(seinfo --flat $policy -r | wc -l)
+nusers=$(seinfo --flat $policy -u | wc -l)
+cat > $output_file << EOF
+/* This file is automatically generated. Do not edit. */
+#ifndef _SELINUX_LIMITS_H__
+#define _SELINUX_LIMITS_H__
+#define __SEPOL_USERS_MAX $nusers
+#define __SEPOL_ROLES_MAX $nroles
+#define __SEPOL_TYPES_MAX $ntypes
+#define SEPOL_SID_LIMIT ( __SEPOL_USERS_MAX * __SEPOL_ROLES_MAX * __SEPOL_TYPES_MAX )
+#endif
+EOF
diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c
index 69fc3389b3..0dbadc8cd7 100644
--- a/xen/xsm/flask/ss/sidtab.c
+++ b/xen/xsm/flask/ss/sidtab.c
@@ -13,6 +13,7 @@
#include "flask.h"
#include "security.h"
#include "sidtab.h"
+#include "se_limits.h"
#define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK)
@@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context,
if ( sid )
goto unlock_out;
/* No SID exists for the context. Allocate a new one. */
- if ( s->next_sid == UINT_MAX || s->shutdown )
+ if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown )
{
ret = -ENOMEM;
goto unlock_out;
--
2.25.1On 30.06.2025 10:55, Sergiy Kibrik wrote: > Currently Xen lacks a defined largest number of security IDs it can potentially > use. The number of SIDs are naturally limited by number of security contexts > provided by a given security policy, i.e. how many combination of user, role > and type there can be, and is dependant on the policy being used. > Thus in Xen the number of allocated entries in sidtable is hard-limited by UINT_MAX. > However in the embedded environment configured for safety it is desirable to > avoid guest-triggered dynamic memory allocations at runtime, or at least limit > them to some decent amounts. So we seek to estimate this limit. > > This patch suggests one way to do it using Xen's flask policy. > List of users, roles and types is read from binary policy using setools utils, > then it is used to count the No. of combinations these values can give. > This No. of combinations then can be used in code as a practical replacement > of UINT_MAX limit. Also it can be used later to pre-allocate sidtable at boot > and avoid runtime entries allocation altogether. > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > --- > This RFC presents a concept of estimating a max possible sidtable size. > Can we discuss how valid this concept is? Currently it yields 420 as max SID, > is it a reasonable number? As this is policy dependent - what policy did you use to obtain that 420? > --- a/xen/xsm/flask/Makefile > +++ b/xen/xsm/flask/Makefile > @@ -14,7 +14,7 @@ AV_H_DEPEND := $(srcdir)/policy/access_vectors > > FLASK_H_FILES := flask.h class_to_string.h initial_sid_to_string.h > AV_H_FILES := av_perm_to_string.h av_permissions.h > -ALL_H_FILES := $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES)) > +ALL_H_FILES := $(addprefix include/,$(FLASK_H_FILES) $(AV_H_FILES) se_limits.h) As a nit: Dashes in preference to underscores please in any new files' names. > @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE > FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC) > cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@ > > +$(obj)/%/se_limits.h: $(obj)/policy.bin > + $(srcdir)/policy/mkselim.sh $^ $@ Hmm, that's using the built-in policy, isn't it? What if later another policy is loaded? Wouldn't it be possible to have ... > --- a/xen/xsm/flask/ss/sidtab.c > +++ b/xen/xsm/flask/ss/sidtab.c > @@ -13,6 +13,7 @@ > #include "flask.h" > #include "security.h" > #include "sidtab.h" > +#include "se_limits.h" > > #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) > > @@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context, > if ( sid ) > goto unlock_out; > /* No SID exists for the context. Allocate a new one. */ > - if ( s->next_sid == UINT_MAX || s->shutdown ) > + if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown ) ... more than this many SIDs? What if CONFIG_XSM_FLASK_POLICY isn't even set? It also doesn't really become clear to me how you avoid or even (meaningfully) bound memory allocation here. A table of several hundred entries is still a decent size. If you really knew the max size up front, why couldn't the table be allocated statically. (Sadly the table allocation isn't in context, as you don't even touch that code, wherever it lives.) Jan
01.07.25 13:42, Jan Beulich: > On 30.06.2025 10:55, Sergiy Kibrik wrote: >> Currently Xen lacks a defined largest number of security IDs it can potentially >> use. The number of SIDs are naturally limited by number of security contexts >> provided by a given security policy, i.e. how many combination of user, role >> and type there can be, and is dependant on the policy being used. >> Thus in Xen the number of allocated entries in sidtable is hard-limited by UINT_MAX. >> However in the embedded environment configured for safety it is desirable to >> avoid guest-triggered dynamic memory allocations at runtime, or at least limit >> them to some decent amounts. So we seek to estimate this limit. >> >> This patch suggests one way to do it using Xen's flask policy. >> List of users, roles and types is read from binary policy using setools utils, >> then it is used to count the No. of combinations these values can give. >> This No. of combinations then can be used in code as a practical replacement >> of UINT_MAX limit. Also it can be used later to pre-allocate sidtable at boot >> and avoid runtime entries allocation altogether. >> >> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> >> --- >> This RFC presents a concept of estimating a max possible sidtable size. >> Can we discuss how valid this concept is? Currently it yields 420 as max SID, >> is it a reasonable number? > > As this is policy dependent - what policy did you use to obtain that 420? it's actually from my custom extended policy, for policy in Xen master branch it's 384. > >> @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE >> FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC) >> cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@ >> >> +$(obj)/%/se_limits.h: $(obj)/policy.bin >> + $(srcdir)/policy/mkselim.sh $^ $@ > > Hmm, that's using the built-in policy, isn't it? What if later another > policy is loaded? Wouldn't it be possible to have ... > >> --- a/xen/xsm/flask/ss/sidtab.c >> +++ b/xen/xsm/flask/ss/sidtab.c >> @@ -13,6 +13,7 @@ >> #include "flask.h" >> #include "security.h" >> #include "sidtab.h" >> +#include "se_limits.h" >> >> #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) >> >> @@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context, >> if ( sid ) >> goto unlock_out; >> /* No SID exists for the context. Allocate a new one. */ >> - if ( s->next_sid == UINT_MAX || s->shutdown ) >> + if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown ) > > ... more than this many SIDs? What if CONFIG_XSM_FLASK_POLICY isn't even set? > It's using a policy from tools/flask/policy, yes. But not a built-in policy, just reusing a bit of code from that code. The idea is that we can have CONFIG_XSM_FLASK_POLICY option disabled yet still be able to calculate SEPOL_SID_LIMIT. As for loading another policy at runtime -- the calculated SEPOL_SID_LIMIT=384 for current master flask policy is still pretty big limit. From what I can see -- much less No. contexts are being used on a running system, because most of calculated combinations of user/role/type are not really usable (e.g. contexts with xen_t or xenboot_t types and user_1 user are not expected etc). So there should be enough room even for more complex custom policies. > It also doesn't really become clear to me how you avoid or even (meaningfully) > bound memory allocation here. A table of several hundred entries is still a > decent size. If you really knew the max size up front, why couldn't the table > be allocated statically. (Sadly the table allocation isn't in context, as you > don't even touch that code, wherever it lives.) > As said before, this limit is crude and still far from the number of actually usable contexts. So allocating this memory beforehand can be kind of wasteful, as most of it will probably never be used. -Sergiy
On 04.07.2025 12:10, Sergiy Kibrik wrote: > 01.07.25 13:42, Jan Beulich: >> On 30.06.2025 10:55, Sergiy Kibrik wrote: >>> @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE >>> FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC) >>> cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@ >>> >>> +$(obj)/%/se_limits.h: $(obj)/policy.bin >>> + $(srcdir)/policy/mkselim.sh $^ $@ >> >> Hmm, that's using the built-in policy, isn't it? What if later another >> policy is loaded? Wouldn't it be possible to have ... >> >>> --- a/xen/xsm/flask/ss/sidtab.c >>> +++ b/xen/xsm/flask/ss/sidtab.c >>> @@ -13,6 +13,7 @@ >>> #include "flask.h" >>> #include "security.h" >>> #include "sidtab.h" >>> +#include "se_limits.h" >>> >>> #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) >>> >>> @@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context, >>> if ( sid ) >>> goto unlock_out; >>> /* No SID exists for the context. Allocate a new one. */ >>> - if ( s->next_sid == UINT_MAX || s->shutdown ) >>> + if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown ) >> >> ... more than this many SIDs? What if CONFIG_XSM_FLASK_POLICY isn't even set? >> > > It's using a policy from tools/flask/policy, yes. But not a built-in > policy, just reusing a bit of code from that code. The idea is that we > can have CONFIG_XSM_FLASK_POLICY option disabled yet still be able to > calculate SEPOL_SID_LIMIT. > > As for loading another policy at runtime -- the calculated > SEPOL_SID_LIMIT=384 for current master flask policy is still pretty big > limit. From what I can see -- much less No. contexts are being used on a > running system, because most of calculated combinations of > user/role/type are not really usable (e.g. contexts with xen_t or > xenboot_t types and user_1 user are not expected etc). So there should > be enough room even for more complex custom policies. But still there could be odd ones. Imo such a static limit can then only be introduced via Kconfig option. Jan
On 7/4/25 06:48, Jan Beulich wrote: > On 04.07.2025 12:10, Sergiy Kibrik wrote: >> 01.07.25 13:42, Jan Beulich: >>> On 30.06.2025 10:55, Sergiy Kibrik wrote: >>>> @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE >>>> FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC) >>>> cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@ >>>> >>>> +$(obj)/%/se_limits.h: $(obj)/policy.bin >>>> + $(srcdir)/policy/mkselim.sh $^ $@ >>> >>> Hmm, that's using the built-in policy, isn't it? What if later another >>> policy is loaded? Wouldn't it be possible to have ... >>> >>>> --- a/xen/xsm/flask/ss/sidtab.c >>>> +++ b/xen/xsm/flask/ss/sidtab.c >>>> @@ -13,6 +13,7 @@ >>>> #include "flask.h" >>>> #include "security.h" >>>> #include "sidtab.h" >>>> +#include "se_limits.h" >>>> >>>> #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) >>>> >>>> @@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context, >>>> if ( sid ) >>>> goto unlock_out; >>>> /* No SID exists for the context. Allocate a new one. */ >>>> - if ( s->next_sid == UINT_MAX || s->shutdown ) >>>> + if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown ) >>> >>> ... more than this many SIDs? What if CONFIG_XSM_FLASK_POLICY isn't even set? >>> >> >> It's using a policy from tools/flask/policy, yes. But not a built-in >> policy, just reusing a bit of code from that code. The idea is that we >> can have CONFIG_XSM_FLASK_POLICY option disabled yet still be able to >> calculate SEPOL_SID_LIMIT. >> >> As for loading another policy at runtime -- the calculated >> SEPOL_SID_LIMIT=384 for current master flask policy is still pretty big >> limit. From what I can see -- much less No. contexts are being used on a >> running system, because most of calculated combinations of >> user/role/type are not really usable (e.g. contexts with xen_t or >> xenboot_t types and user_1 user are not expected etc). So there should >> be enough room even for more complex custom policies. > > But still there could be odd ones. Imo such a static limit can then only be > introduced via Kconfig option. Jan, thank you for adding me on as the CC. Not having seen the original patch, but based on the discussion, I would say this should be a Kconfig option that by default maintains the existing bounds/limits allowing for the distro maintainer to impose tighter restrictions. Additionally, any there was dynamic allocation, this should remain (being the default) and static allocation should only happen via Kconfig system. v/r, dps
On Fri, 4 Jul 2025, Jan Beulich wrote: > On 04.07.2025 12:10, Sergiy Kibrik wrote: > > 01.07.25 13:42, Jan Beulich: > >> On 30.06.2025 10:55, Sergiy Kibrik wrote: > >>> @@ -54,4 +54,7 @@ $(obj)/policy.bin: FORCE > >>> FLASK_BUILD_DIR=$(FLASK_BUILD_DIR) POLICY_FILENAME=$(POLICY_SRC) > >>> cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@ > >>> > >>> +$(obj)/%/se_limits.h: $(obj)/policy.bin > >>> + $(srcdir)/policy/mkselim.sh $^ $@ > >> > >> Hmm, that's using the built-in policy, isn't it? What if later another > >> policy is loaded? Wouldn't it be possible to have ... > >> > >>> --- a/xen/xsm/flask/ss/sidtab.c > >>> +++ b/xen/xsm/flask/ss/sidtab.c > >>> @@ -13,6 +13,7 @@ > >>> #include "flask.h" > >>> #include "security.h" > >>> #include "sidtab.h" > >>> +#include "se_limits.h" > >>> > >>> #define SIDTAB_HASH(sid) ((sid) & SIDTAB_HASH_MASK) > >>> > >>> @@ -228,7 +229,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct context *context, > >>> if ( sid ) > >>> goto unlock_out; > >>> /* No SID exists for the context. Allocate a new one. */ > >>> - if ( s->next_sid == UINT_MAX || s->shutdown ) > >>> + if ( s->next_sid == SEPOL_SID_LIMIT || s->shutdown ) > >> > >> ... more than this many SIDs? What if CONFIG_XSM_FLASK_POLICY isn't even set? > >> > > > > It's using a policy from tools/flask/policy, yes. But not a built-in > > policy, just reusing a bit of code from that code. The idea is that we > > can have CONFIG_XSM_FLASK_POLICY option disabled yet still be able to > > calculate SEPOL_SID_LIMIT. > > > > As for loading another policy at runtime -- the calculated > > SEPOL_SID_LIMIT=384 for current master flask policy is still pretty big > > limit. From what I can see -- much less No. contexts are being used on a > > running system, because most of calculated combinations of > > user/role/type are not really usable (e.g. contexts with xen_t or > > xenboot_t types and user_1 user are not expected etc). So there should > > be enough room even for more complex custom policies. > > But still there could be odd ones. Imo such a static limit can then only be > introduced via Kconfig option. I was going to suggest the same approach as Jan. While I appreciate Sergiy's effort to calculate the limit automatically using mkselim.sh, I think that for our purposes, a simple Kconfig option specifying the maximum allocation limit is sufficient. This type of limit is typically chosen before moving into production, after extensive experimentation, measurements, and certifications. Therefore, it is not necessary to make it easier for users to configure it optimally based on policy. However, we do need a way to enforce a limit, and a straightforward Kconfig option would be adequate for that.
© 2016 - 2025 Red Hat, Inc.