Note that you cannot build a module with an older policy version.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
update .gitignore to include files that are normally created when
working and building inside the git repo
Sigend-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
There was no way to print all of the role transition rules in dispol.
Add that support.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
The formatting of dismod/dispol display of filename trans rules didn't
make a lot of sense. Make them more like the original rules.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Bump checkpolicy to 2.1.0
Bump libselinux to 2.1.0
Bump libsepol to 2.1.0
Bump libsemanage to 2.1.0
Bump policycoreutils to 2.1.0
Bump sepolgen to 1.1.0
When the link process is completed, the types type_set_t and roles
ebitmap in a role attribute are settled, then we could go on to scan
all role attributes in the base->p_roles.table checking if any non-zero
bit in its roles ebitmap is indeed another role attribute.
If this is the case, then we need to escalate the roles ebitmap of
the sub role attribute into that of the parent, and remove the sub role
attribute from parent's roles ebitmap.
Since sub-attribute's roles ebitmap may further contain other role
attributes, we need to re-scan the updated parent's roles ebitmap.
Also if a loop dependency is detected, no escalation of sub-attribute's
roles ebitmap is needed.
Note, although in the link stage all role identifiers defined in any
block/decl of any module would be copied into the base->p_roles.table,
the role-attribute relationships could still be recorded in the decl's
local symtab[SYM_ROLES] table(see get_local_role()), so before all above
escalation of sub role attribute's roles ebitmap into that of parent ever
happens, all decl in the base->global list except the global block would
have to be traversed so as to populate potential role-attribute
relationships from decl up to the base module.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
When the rolemap and pointer to the base module are available, if
a non-zero bit in role_set_t.roles is a role attribute, expand it
before remap.
Note, during module compile the rolemap may not be available, the
potential duplicates of a regular role and the role attribute that
the regular role belongs to could be properly handled by
copy_role_allow() and copy_role_trans() during module expansion.
Take advantage of the role_val_to_struct[] of the base module, since
when role_set_expand() is invoked, the role_val_to_struct[] of the
out module may have not been established yet.
Also cleanup the error handling of role_set_expand().
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
1. Add a uint32_t "flavor" field and an ebitmap "roles" to the
role_datum_t structure;
2. Add a new "attribute_role" statement and its handler to declare
a role attribute;
3. Modify declare_role() to setup role_datum_t.flavor according
to the isattr argument;
4. Add a new "roleattribute" rule and its handler, which will record
the regular role's (policy value - 1) into the role attribute's
role_datum_t.roles ebitmap;
5. Modify the syntax for the role-types rule only to define the
role-type associations;
6. Add a new role-attr rule to support the declaration of a single
role, and optionally the role attribute that the role belongs to;
7. Check if the new_role used in role-transition rule is a regular role;
8. Support to require a role attribute;
9. Modify symtab_insert() to allow multiple declarations only for
the regular role, while a role attribute can't be declared more than once
and can't share a same name with another regular role.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
The patch below allows filesystem names in fs_use_* and genfscon
statements to start with a digit, but still requires at least one
character to be a letter. A new token type for filesystem names is
created since these names having nothing to do with SELinux.
This patch is needed because some filesystem names (such as 9p) start
with a digit.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
This wraps the filename token in quotes to make parsing easier and more
clear. The quotes are stripped off before being passed to checkpolicy.
The quote wrapping is only used by filename transitions. This changes
the filename transition syntax to the following:
type_transition source target : object default_type "filename";
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
currently policy will not build if I define a module as 1
policy_module(dan,1) Fails
policy_module(dan,1.0) works
The attached patch makes the first one work.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
This patch adds support for using the last path component as part of the
information in making labeling decisions for new objects. A example
rule looks like so:
type_transition unconfined_t etc_t:file system_conf_t eric;
This rule says if unconfined_t creates a file in a directory labeled
etc_t and the last path component is "eric" (no globbing, no matching
magic, just exact strcmp) it should be labeled system_conf_t.
The kernel and policy representation does not have support for such
rules in conditionals, and thus policy explicitly notes that fact if
such a rule is added to a conditional.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
We just use random numbers to make menu selections. Use #defines and
names that make some sense instead.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Bump checkpolicy to 2.0.24
Bump libselinux to 2.0.102
Bump libsepol to 2.0.43
Bump policycoreutils to 2.0.86
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Add support to display the class field in the role_transition rule
in the checkpolicy/test/dismod program.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Handle the class field in the role_transition rule. If no class is
specified, then it would be set to the "process" class by default.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Email: justinmattock@gmail.com
Subject: checkpolicy Fix error: variable 'newattr' set but not used(and others as well)
Date: Tue, 6 Jul 2010 15:23:28 -0700
The below patch fixes some warning messages Im receiving
with GCC:(in this case some are erros due to -Werror)
policy_define.c: In function 'define_type':
policy_define.c:1216:6: error: variable 'newattr' set but not used
cc1: all warnings being treated as errors
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Chad Sellers <csellers@tresys.com>
Email: slawrence@tresys.com
Subject: Minor fixup of checkmodule man page.
Date: Fri, 11 Jun 2010 15:25:58 -0400
On Mon, 2010-05-03 at 13:45 -0400, Daniel J Walsh wrote:
> Quality Engineering is going through all commands on the system looking
> for mismatches between man page/usage and actual code.
>
> It found that checkmodule had a -d option that is unused and undocumented -h
Reviewed-by: Steve Lawrence <slawrence@tresys.com>
I'd just add the long --help option to the man page for completeness:
Signed-off-by: Chad Sellers <csellers@tresys.com>
Email: dwalsh@redhat.com
Subject: Minor fixup of checkmodule man page.
Date: Mon, 03 May 2010 13:45:30 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quality Engineering is going through all commands on the system looking
for mismatches between man page/usage and actual code.
It found that checkmodule had a -d option that is unused and undocumented -h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvfC7oACgkQrlYvE4MpobNPrACg0uP02CWYPs9YcdU87jts9YqT
hMAAn2QA1UWZpGLvvU4yxStmhUU1Kg1+
=topF
-----END PGP SIGNATURE-----
Signed-off-by: Chad Sellers <csellers@tresys.com>
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:
