Commit Graph

24 Commits

Author SHA1 Message Date
Chad Sellers
88a57ca14b Bump policycoreutils to 2.0.76
Bump libsepol to 2.0.41
Bump libsemanage to 2.0.42
2009-11-18 16:44:55 -05:00
Manoj Srivastava
8627ab66a7 Author: Manoj Srivastava
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>
2009-11-18 14:46:03 -05:00
Eamon Walsh
7cdfd6e659 Bump libsepol to 2.0.40, libselinux to 2.0.89, libsemanage to 2.0.41. 2009-10-29 15:33:37 -04:00
Eamon Walsh
12777502c6 Add pkgconfig files for libsepol, libselinux, and libsemanage.
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>
2009-10-22 14:50:07 -04:00
Eamon Walsh
0857e3e478 Add subdirectory .gitignore files.
These take care of executables and generated source files.

Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
2009-10-20 21:25:55 -04:00
Joshua Brindle
f3c3bbd16a bump checkpolicy to 2.0.20, libsepol to 2.0.39, sepolgen to 1.0.18 2009-10-14 15:54:16 -04:00
Paul Nuzzi
505c75aad7 libsepol: Add support for multiple target OSes
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>
2009-10-14 15:45:46 -04:00
Stephen Smalley
acc3a04145 libsepol 2.0.38 2009-09-01 10:03:46 -04:00
Stephen Smalley
a0440a66c3 Unchecked input leades to integer underflow
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>
2009-09-01 09:46:19 -04:00
Stephen Smalley
667edaa875 libsepol 2.0.37 2009-07-07 14:25:12 -04:00
Christopher Pardy
86a2f899cb libsepol: method to check disable dontaudit flag.
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>
2009-07-07 14:19:57 -04:00
Joshua Brindle
94dd6859c1 bump libsepol to 2.0.36 2009-03-21 11:13:59 -04:00
Joshua Brindle
3df79fc5eb Author: Joshua Brindle
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>
2009-03-21 11:11:52 -04:00
Joshua Brindle
46d0b2c939 bump libsepol to 2.0.35 2009-02-17 12:23:41 -05:00
Caleb Case
f7917ea9cf aliases for the boundry format
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>
2009-02-16 11:52:03 -05:00
Joshua Brindle
a73248ba81 remove reject file 2008-10-09 08:34:09 -04:00
Joshua Brindle
b04f2af251 bump checkpolicy to 2.0.17 and libsepol to 2.0.34 2008-10-09 08:31:43 -04:00
Joshua Brindle
f470207454 Author: KaiGai Kohei
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>
2008-10-08 06:58:40 -04:00
Joshua Brindle
e61b36a5c7 Author: Joshua Brindle
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:
2008-10-07 09:51:54 -04:00
Joshua Brindle
57671a59f2 bump libsepol to 2.0.33 2008-09-29 21:11:42 -04:00
Joshua Brindle
eeb520a045 Revert "Subject: remove expand_rule function"
This reverts commit 45e94541ec.
2008-09-29 21:09:17 -04:00
Joshua Brindle
45e94541ec Subject: remove expand_rule function
Send again with the right date and time ;)

This removes the (apparently) unused expand_rule function

Signed-off-by: Joshua Brindle <method@manicmethod.com>
2008-08-19 16:35:34 -04:00
Vesa-Matti J Kari
0915aeaaac selinux: conditional expression type validation was off-by-one
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>
2008-08-19 16:34:59 -04:00
Joshua Brindle
13cd4c8960 initial import from svn trunk revision 2950 2008-08-19 15:30:36 -04:00