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. Copy the flavor flag into its counterpart in the out module;
2. Fix all role attributes in the base module:
2.1 remap the roles ebitmap and merge into its counterpart in the
out module;
2.2 escalate the types.types ebitmap of its counterpart in the out
module, to the counterparts for all the regular roles that belongs
to the current role attribute.
The role_fix_callback() must be called after role_copy_callback()
so that state->rolemap[] is available.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Make the flavor flag and the roles ebitmap in role_datum_t structure
properly handled during module link process:
1. the flavor flag is copied into the base module;
2. if both the current module and the base module have defined or
required the same role, check if there is a discrepency in flavor;
3. remap the roles ebitmap and merge into its counterpart in the
base module;
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Add support to read/write the flavor flag and roles ebitmap in the
role_datum_t structure from/to policy module, if its version is no less
than MOD_POLICYDB_VERSION_ROLEATTRIB.
Since the role ebitmap would be expanded and won't be written into
policy.X, neither is the flavor flag, kernel SELinux security server
needs no change, the maximum version number for policy.X needs no bump.
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>
When writing the roletrans rules, rules are dropped when not supported,
but the number of rules is not decreased. This sets the number of
elements to the actual number of rules that will be written.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Although the role trans code had support to handle the kernel policy
when the version was less that roletrans such support was not in the
module read/write code. This patch adds proper support for role trans
in modules.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
This patch adds libsepol support for filename_trans rules. These rules
allow one to make labeling decisions for new objects based partially on
the last path component. They are stored in a list. If we find that
the number of rules grows to an significant size I will likely choose to
store these in a hash, both in libsepol and in the kernel. But as long
as the number of such rules stays small, this should be good.
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 class support to various functions to handle role_trans_rule_t
structures.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Add the class support to various functions that handle role_trans
structure.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Introduce the class support to role_trans and role_trans_rule
structures, which could be the subject class("process") or the
class that the newly created object belongs to.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Email: justinmattock@gmail.com
Subject: libsepol
Date: Tue, 6 Jul 2010 15:23:29 -0700
Going through these warning messages Im getting:
(example 1 of many)
booleans.c: In function 'sepol_bool_count':
booleans.c:106:39: error: parameter 'handle' set but not used
cc1: all warnings being treated as errors
seems most of these go to NULL; Which tells me that these are here for
future use and/or need to be there for some other reason.
The biggest problem I have is Im getting errors out of these as opposed
to just a warning(-Werror) so marking the variable with a GCC
__attribute__ ((unused)) gets things going.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Chad Sellers <csellers@tresys.com>
This test must have been disabled a very long time ago, before attributes were present in the kernel policy. Since the attributes are now present this unit test should be turned back on, unless I'm missing something pretty major (it looks reasonable and is successful when run).
Signed-off-by: Joshua Brindle <jbrindle@tresys.com>
On 02/24/2010 02:24 PM, Daniel J Walsh wrote:
>
Ignore the first patch it was missing pc.in files.
Acked-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: srivasta@debian.org
Subject: cannnot -> cannot and suport -> support
Date: Tue, 17 Nov 2009 10:27:57 -0600
This was reported after a lintian check found this on any package
linked with libsepol. Closes: #556390
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
Signed-off-by: Chad Sellers <csellers@tresys.com>
Having a pkgconfig files allows the pkg-config tool to be used to
query the presence of the library (or a particular version of it),
and to obtain the C flags and linker arguments to build with it.
Based on Debian patches by Manoj Srivastava <srivasta@debian.org>.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
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>
On Mon, 2009-08-31 at 08:55 -0500, Manoj Srivastava wrote:
> On Mon, Aug 31 2009, Stephen Smalley wrote:
>
> > On Sun, 2009-08-30 at 10:19 -0500, Manoj Srivastava wrote:
> >> Hi,
> >>
> >> This bug was discovered, and the analysis done, buy Max
> >> Kellermann. I have never been able to replicate the problem, so I can't
> >> help debug this error.
> >>
> >> Strace:
> >> --8<---------------cut here---------------start------------->8---
> >> brk(0x3233000) = 0x3233000
> >> mmap(NULL, 18446744073703178240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> >> mmap(NULL, 18446744073703313408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> >> mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fdfda316000
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> > 0xffffffffff9ec000 == 18446744073703178240 (the size of the first
> >> > large allocation). It's also equal to -6373376. This just looks like
> >> > an integer underflow, doesn't it?
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> Breakpoint 4, 0x00007f9bc4c05400 in mmap64 () from /lib/libc.so.6
> >> (gdb) p $rsi
> >> $25 = -6373376
> >> (gdb) bt
> >> #0 0x00007f9bc4c05400 in mmap64 () from /lib/libc.so.6
> >> #1 0x00007f9bc4baf6bb in _int_malloc () from /lib/libc.so.6
> >> #2 0x00007f9bc4bb0a78 in malloc () from /lib/libc.so.6
> >> #3 0x00007f9bc5301a8e in sepol_module_package_read (mod=0xb1d170, spf=0xb202e0, verbose=0) at module.c:533
> >> #4 0x00007f9bc4ea7838 in ?? () from /lib/libsemanage.so.1
> >>
> >> (gdb) frame 3
> >> #3 0x00007f9bc5301a8e in sepol_module_package_read (mod=0xb1d170, spf=0xb202e0, verbose=0) at module.c:533
> >> 533 module.c: No such file or directory.
> >> in module.c
> >> (gdb) p len
> >> $26 = 18446744073703176358
> >> (gdb) p i
> >> $27 = 3
> >> (gdb) p nsec
> >> $30 = 4
> >> (gdb) p offsets[i+1]
> >> $28 = 8192
> >> (gdb) p offsets[i]
> >> $29 = 6383450
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> > line 456:
> >> > len = offsets[i + 1] - offsets[i];
> >>
> >> > Voila, integer underflow. The function module_package_read_offsets()
> >> > reads the offsets from the input file, but does not verify them.
> >> > off[nsec] = policy_file_length(file);
> >> > Here, the check is missing.
> >>
> >> We should probably have:
> >> --8<---------------cut here---------------start------------->8---
> >> off[nsec] = policy_file_length(file);
> >> if (off[nsec] < off[nsec-1]) {
> >> ERR(file->handle, "file size smaller than previous offset (at %u, "
> >> "offset %zu -> %zu", nsec, off[nsec - 1],
> >> off[nsec]);
> >> return -1;
> >> }
> >> --8<---------------cut here---------------end--------------->8---
> >
> > Perhaps I am missing something, but module_package_read_offsets()
> > already checks that the offsets are increasing and aborts if not.
>
> Well, almost. It does check for most of the offsets:
> --8<---------------cut here---------------start------------->8---
>
> 406 for (i = 0; i < nsec; i++) {
> 407 off[i] = le32_to_cpu(buf[i]);
> 408 if (i && off[i] < off[i - 1]) {
> 409 ERR(file->handle, "offsets are not increasing (at %u, "
> 410 "offset %zu -> %zu", i, off[i - 1],
> 411 off[i]);
> 412 return -1;
> 413 }
> 414 }
> --8<---------------cut here---------------end--------------->8---
> So far, so good.
> --8<---------------cut here---------------start------------->8---
> 415
> 416 free(buf);
> 417 off[nsec] = policy_file_length(file);
> 418 *offsets = off;
> 419 return 0;
> --8<---------------cut here---------------end--------------->8---
>
> The problem is line 417, where there is no check; and in the
> case reported, the file length was less than the previous offset, and
> this resulted in a negative number passed to the memory allocator,
> which resulted in a huge allocation request.
>
> Above, I just propose adding a check after line 417.
Check the last offset against the file size, and ensure that we free the
buffer and offset array in the error cases.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This patch adds the ability to check on the value of the disable_dontaudit flag in the sepol handle. In the past the only way to know the value of this was to directly read the values from the handle. The get function provides a setter-getter symmetry similar to other functions found in libsepol.
Signed-off-by: Christopher Pardy <cpardy@redhat.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Email: method@manicmethod.com
Subject: libsepol: fix boolean state smashing
Date: Wed, 18 Mar 2009 10:47:34 -0400
If a boolean is encountered in a require block before the place where it is
declared it currently gets created with the state set to false no matter what
the declared state was. This only affects booleans in modules where the boolean
was also required in another module. Patch below:
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>
Email: method@manicmethod.com
Subject: BUGREPORT: A type alias of invisible primary one
Date: Mon, 22 Sep 2008 16:43:04 -0400
KaiGai Kohei wrote:
> Joshua Brindle wrote:
>> KaiGai Kohei wrote:
>>> I found a strange type_datum_t object which has 0 for its s.value
>>> during development of new type hierarchy checks.
>>>
>>> The strange one is "xguest_javaplugin_default_xproperty_t" which
>>> is an alias type of "xguest_javaplugin_xproperty_t".
>>>
>>> I doubted my patch at first, but it can be reproduced on the normal
>>> libsepol. It seems to me an original matter which is not exposed yet,
>>> and I am innocence. :-)
>>>
>>> During tracing the matter, I noticed the primary type is invisible
>>> at expand_module(), but the aliased one is visible. It can make the
>>> strange type_datum_t object.
>>>
>>> * at the expand_module()
>>> 1. The expand_state_t which includes typemap is initialized.
>>>
>>> 2. The type_copy_callback is invoked for any types via hashtab_map.
>>> It only copies primary and visible types into newer hashtab,
>>> and set up typemap to translate between old and new s.value.
>>> Thus, the given primary type is invisible, its slot of typemap
>>> is kept to zero.
>>> (*) is_id_enabled() for "xguest_javaplugin_xproperty_t" returned false.
>>>
>>> 3. The alias_copy_callback is invoked for any types via hashtab_map.
>>> It only copies alias and visible types into newer hashtab.
>>> Here is no check whether the primary side is visible, or not.
>>> A copied type_datum_t object for the given alias has new s.value
>>> which is picked up from state->typemap.
>>>
>>> 4. However, the target slot of state->typemap was zero, because
>>> its primary one is invisible. The aliased type has a strange
>>> s.value.
>>>
>>> 5. Type hierarchy checks got a segmentation fault, due to
>>> "p->type_val_to_name[datum->s.value - 1]".
>>> ^^^^^^^^^^^^^^^^^^ == -1
>>> Yes, we can identify cause of the matter.
>> Do you have a policy that can be used to reproduce this?
>
> Yes, the following policy can reproduce the matter.
> - - - - [ cut here ] - - - -
> policy_module(baz, 1.0)
>
> optional_policy(`
> gen_require(`
> type invisible_primary_t;
> ')
> typealias invisible_primary_t alias visible_alias_t;
> ')
> - - - - - - - - - - - - - - -
>
> The attached patch can inject some of printf()'s.
> You can see that invisible_primary_t is skipped at type_copy_callback()
> and an incorrect s.value is assigned at alias_copy_callback().
>
> Thanks,
>
This should fix it. I tested with and without your patchset on a few policies. Let me know if it doesn't work for you:
Send again with the right date and time ;)
This removes the (apparently) unused expand_rule function
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>
