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
