On Wed, 2009-09-16 at 09:58 -0400, Joshua Brindle wrote:
> I'd rather have separate ocontext structs for each system. That way it
> is very easy to understand which ones apply to which system and you
> don't get a crazy out of context ocontext struct.
>
I looked into having separate ocontext structs but that would involve
changing a lot of files making the patch much larger and more intrusive.
> > } u;
> > union {
> > uint32_t sclass; /* security class for genfs */
> > @@ -313,6 +323,17 @@ typedef struct genfs {
> > #define OCON_NODE6 6 /* IPv6 nodes */
> > #define OCON_NUM 7
> >
> > +/* object context array indices for Xen */
> > +#define OCON_ISID 0 /* initial SIDs */
> > +#define OCON_PIRQ 1 /* physical irqs */
> > +#define OCON_IOPORT 2 /* io ports */
> > +#define OCON_IOMEM 3 /* io memory */
> > +#define OCON_DEVICE 4 /* pci devices */
> > +#define OCON_DUMMY1 5 /* reserved */
> > +#define OCON_DUMMY2 6 /* reserved */
> > +#define OCON_NUM 7
> > +
> > +
> >
> Should these be namespaced? What if <random other system> has io port
> objects? You'd have to align them with each other and you have a mess of
> keeping the numbers the same (you already do this with OCON_ISID)
Variables have been namespaced and there is no more overlap with
OCON_ISID.
> Also we are relying on having the same number of OCON's which isn't good
> I don't think. As much as I hate the policydb_compat_info (read: alot)
> why aren't we using that to say how many ocons a xen policy really has?
OCON_NUM is now dynamically read through policydb_compat_info.
> This is messy, why not an ocontext_selinux_free() and
> ocontext_xen_free() (note: I realize the xen_free() one won't do
> anything except freep the ocontext_t)
>
done.
> >
> > len = buf[1];
> > - if (len != strlen(target_str)&&
> > - (!alt_target_str || len != strlen(alt_target_str))) {
> > - ERR(fp->handle, "policydb string length %zu does not match "
> > - "expected length %zu", len, strlen(target_str));
> > + if (len> 32) {
> >
>
> magic number 32?
#defined.
Thanks for your input. Below is the updated patch for libsepol.
----
libsepol/include/sepol/policydb/policydb.h | 28 ++
libsepol/src/expand.c | 85 +++++++-
libsepol/src/policydb.c | 295
+++++++++++++++++++++++------
libsepol/src/policydb_internal.h | 1
libsepol/src/private.h | 4
libsepol/src/write.c | 93 ++++++++-
6 files changed, 443 insertions(+), 63 deletions(-)
Signed-off-by: Joshua Brindle <method@manicmethod.com>
The boundry format mapped the primary field to a boolean in the
properties bitmap. This is appropriate for the kernel policy, but in
modular policy the primary field may be an integer that indicates the
primary type that is being aliased. In this case, the primary value cannot
be assumed to be boolean.
This patch creates a new module format that writes out the primary value
as was done before the boundry format.
Signed-off-by: Caleb Case <ccase@tresys.com>
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: kaigai@ak.jp.nec.com
Subject: Thread/Child-Domain Assignment (rev.6)
Date: Tue, 07 Oct 2008 15:39:45 +0900
>> Hmm....
>> It seems to me what you pointed out is a bug of my patch. It prevents to deliver
>> actual number of type/attribute symbols to policy file, but it is unclear why does
>> it makes libsepol ignore the policyvers.
>> (I guess it may be a separated matter.)
>>
>>> Rather than trying to calculate the length without attributes I just removed
>>> the attribute check. This causes attributes to be written for all versions,
>>> but this should not cause any problems at all.
>> The reason why I injected such an ad-hoc code is that we cannot decide the policy
>> version written when type_attr_remove() is invoked.
>> Is it impossible to move it to policydb_write()?
>> It is invoked after the policyvers is fixed by caller.
>
> It isn't impossible. You are going to have to make it walk to type
> symbol table to calculate the length without attributes, then write
> that length instead of the total symtab length.
The attached patch enables to fixup the number of type/attribute entries
to be written. The type_attr_uncount() decrements the number of attribute
entries skipped at type_write().
At first, I had a plan to invoke type_attr_remove() with
hashtab_map_remove_on_error(), but it means the given policydb structure
is modified at policydb_write() and implicit changes to external interface.
Differences from the previous version are here:
Signed-off-by: Joshua Brindle <method@manicmethod.com>
This is the same off-by-one bug that was already fixed in the kernel.
(According to my understanding neither of these bugs has security
implications)
Signed-off-by: Vesa-Matti Kari <vmkari@cc.helsinki.fi>
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Paul Nuzzi
Caleb Case
Joshua Brindle
Vesa-Matti J Kari