This patch is proposed to solve Ticket #1 [1672486] (command line
binaries should support --version and --help).
It adds handling of -h, -V and the long formats --help and --version to
all binaries (checkpolicy/checkmodule).
It also adds handling of long options for some of the available options.
Manual pages have also been updated accordingly (and a few undocumented
options have been documented).
Guido Trentalancia
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: method@manicmethod.com
Subject: libsepol: Add support for multiple target OSes
Date: Tue, 13 Oct 2009 15:56:39 -0400
Paul Nuzzi wrote:
> 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.
>
Acked-by: Joshua Brindle <method@manicmethod.com>
for the entire patchset with the following diff on top:
diff --git a/checkpolicy/checkpolicy.c b/checkpolicy/checkpolicy.c
index 76d8ed3..e76bb1a 100644
--- a/checkpolicy/checkpolicy.c
+++ b/checkpolicy/checkpolicy.c
@@ -100,8 +100,8 @@ unsigned int policyvers = POLICYDB_VERSION_MAX;
void usage(char *progname)
{
printf
- ("usage: %s [-b] [-d] [-U handle_unknown (allow,deny,reject) [-M]"
- "[-c policyvers (%d-%d)] [-o output_file] [-t platform]"
+ ("usage: %s [-b] [-d] [-U handle_unknown (allow,deny,reject)] [-M]"
+ "[-c policyvers (%d-%d)] [-o output_file] [-t target_platform (selinux,xen)]"
"[input_file]\n",
progname, POLICYDB_VERSION_MIN, POLICYDB_VERSION_MAX);
exit(1);
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>
On Tue, 2008-10-14 at 02:00 +0000, korkishko Tymur wrote:
> I have checked policy_parse.y. It has following rule for genfscon:
>
> genfs_context_def : GENFSCON identifier path '-' identifier security_context_def
> {if (define_genfs_context(1)) return -1;}
> | GENFSCON identifier path '-' '-' {insert_id("-", 0);} security_context_def
> {if (define_genfs_context(1)) return -1;}
> | GENFSCON identifier path security_context_def
> {if (define_genfs_context(0)) return -1;}
>
> The rule for path definition (in policy_scan.l) has already included '-' (dash):
>
> "/"({alnum}|[_.-/])* { return(PATH); }
>
> In my understanding (maybe wrong), path is parsed first (and path might include '-') and only then separate '-' is parsed.
> But it still produces an error if path definition is correct and includes '-'.
>
> Any ideas/patches how to fix grammar rules are welcomed.
This looks like a bug in policy_scan.l - we are not escaping (via
backslash) special characters in the pattern and thus the "-" (dash) is
being interpreted rather than taken literally. The same would seemingly
apply for "." (dot), and would seem relevant not only to PATH but also
for IDENTIFIER. The patch below seems to fix this issue for me:
