All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Core dump
       [not found] <OF615DC251.A04042B9-ON4A256B61.007D0561-4A256B61.007D5D7B@au.ibm.com>
@ 2002-02-16  3:24 ` Michael Sinz
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Sinz @ 2002-02-16  3:24 UTC (permalink / raw)
  To: Peter Waltenberg; +Cc: Linux Kernel List

Peter Waltenberg wrote:
> 
> Whats to stop someone creating a process (or a nodename) with an inspired
> (tm) name, and trashing or overwriting system files ?
> 
>      %P      The Process ID (current->pid)
>         %U      The UID of the process (current->uid)
>         %N      The command name of the process (current->comm)
>         %H      The nodename of the system (system_utsname.nodename)
>         %%      A "%"
> 
> The flexibility is nice, but can you PROVE it doesn't have holes like that
> ?

Actually - yes.

First, I can not prevent some system admin from making the core pattern
a bad pattern.  For example, a pattern of /usr/bin/%N would be a bad thing (tm)

However, as long as the system admin (who is the person who can set the pattern)
does not do that, the code prevents a rouge name (hostname or command name)
from causing problems.

(I prevent the use of "/" in either the hostname or command name, for example)

I have tried most everything I could think of.  And, since the host name is
usually not setable by non-root, it makes it even less likely.

In fact, with a pattern like /corefiles/%H-%N-%P.core, there is even less
likelyhood that a coredump can cause problems since I can make the /corefiles
partition its own location and thus coredumps will not write to the key
filesystem.

BTW - both FreeBSD and OpenBSD have a simular format (I took my insperation
from FreeBSD, which I always liked better since the default there is %N.core)

> Just about everything we've had with variable logfile names has had holes
> like that. Samba is one of the more recent examples.

The key is to filter certain characters.  Mostly the '/' in any of the
variables.

However, there is always the problem of someone with root access making
a bad setting in the sysctl.  But then, if they have root, they don't
need to set some sysctl in order to cause damage.

-- 
Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com
A master's secrets are only as good as
	the master's ability to explain them to others.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* core dump
@ 2007-02-06  2:12 Stefanos Harhalakis
  2007-02-06 12:40 ` Stephen Smalley
  0 siblings, 1 reply; 9+ messages in thread
From: Stefanos Harhalakis @ 2007-02-06  2:12 UTC (permalink / raw)
  To: selinux

I had this issue today:

# semodule -i logging.pp 
Segmentation fault (core dumped)

I traced this a bit and it seems that this is because of libsepol. 
The core dump is the result of lines 602:603 of link.c:

(gdb) bt
#0  0xb7f732fd in sens_copy_callback (key=0x848c2a0 "s15", datum=0x848c290, data=0xbfde3854) at link.c:602
#1  0xb7f6f8a1 in hashtab_map (h=0x846cbf0, apply=0xb7f731d1 <sens_copy_callback>, args=0xbfde3854) at hashtab.c:214
#2  0xb7f75528 in copy_identifiers (state=0xbfde3854, src_symtab=0x843cc74, dest_decl=0x0) at link.c:1323
#3  0xb7f77c72 in link_modules (handle=0x804c710, b=0x80525b8, mods=0x863ce18, len=19, verbose=0) at link.c:2178
#4  0xb7f7a2c9 in sepol_link_packages (handle=0x804c710, base=0x8053060, modules=0x80543c8, num_modules=19, verbose=0) at module.c:302

Where:

(gdb) l
597                                 state->cur_mod_name);
598                             return -SEPOL_LINK_NOTSUP;
599                     }
600             }
601     
602             state->cur->map[SYM_LEVELS][level->level->sens - 1] =
603                 base_level->level->sens;
604     
605             return 0;
606     }

Because of:

(gdb) p base_level
$1 = (level_datum_t *) 0x0

The last 'if' checks for !base_level, but inside the 'if' block, only 
!scope and scope->scope==SCOPE_DECL are checked.

This core dump is caused by:

(gdb) p scope->scope
$2 = 1

Which is noted as:

/* Required for this decl */
#define SCOPE_REQ  1

in libsepol/include/sepol/policydb/policydb.h

Hope this helps...

<<V13>>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: core dump
  2007-02-06  2:12 core dump Stefanos Harhalakis
@ 2007-02-06 12:40 ` Stephen Smalley
  2007-02-06 13:06   ` [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump) Stephen Smalley
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Smalley @ 2007-02-06 12:40 UTC (permalink / raw)
  To: Stefanos Harhalakis
  Cc: selinux, Joshua Brindle, Karl MacMillan, Darrel Goeddel,
	Christopher J. PeBenito

On Tue, 2007-02-06 at 04:12 +0200, Stefanos Harhalakis wrote:
> I had this issue today:
> 
> # semodule -i logging.pp 
> Segmentation fault (core dumped)
> 
> I traced this a bit and it seems that this is because of libsepol. 
> The core dump is the result of lines 602:603 of link.c:
> 
> (gdb) bt
> #0  0xb7f732fd in sens_copy_callback (key=0x848c2a0 "s15", datum=0x848c290, data=0xbfde3854) at link.c:602
> #1  0xb7f6f8a1 in hashtab_map (h=0x846cbf0, apply=0xb7f731d1 <sens_copy_callback>, args=0xbfde3854) at hashtab.c:214
> #2  0xb7f75528 in copy_identifiers (state=0xbfde3854, src_symtab=0x843cc74, dest_decl=0x0) at link.c:1323
> #3  0xb7f77c72 in link_modules (handle=0x804c710, b=0x80525b8, mods=0x863ce18, len=19, verbose=0) at link.c:2178
> #4  0xb7f7a2c9 in sepol_link_packages (handle=0x804c710, base=0x8053060, modules=0x80543c8, num_modules=19, verbose=0) at module.c:302
> 
> Where:
> 
> (gdb) l
> 597                                 state->cur_mod_name);
> 598                             return -SEPOL_LINK_NOTSUP;
> 599                     }
> 600             }
> 601     
> 602             state->cur->map[SYM_LEVELS][level->level->sens - 1] =
> 603                 base_level->level->sens;
> 604     
> 605             return 0;
> 606     }
> 
> Because of:
> 
> (gdb) p base_level
> $1 = (level_datum_t *) 0x0
> 
> The last 'if' checks for !base_level, but inside the 'if' block, only 
> !scope and scope->scope==SCOPE_DECL are checked.
> 
> This core dump is caused by:
> 
> (gdb) p scope->scope
> $2 = 1
> 
> Which is noted as:
> 
> /* Required for this decl */
> #define SCOPE_REQ  1
> 
> in libsepol/include/sepol/policydb/policydb.h
> 
> Hope this helps...

Looks like your logging.pp policy module has a requires on sensitivity
s15 but your base module doesn't declare it.  Naturally, that should
show up as an unfulfilled requirement rather than a seg fault.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [patch] libsepol:  check for unmet requires on sensitivities and categories (Was:  Re: core dump)
  2007-02-06 12:40 ` Stephen Smalley
@ 2007-02-06 13:06   ` Stephen Smalley
  2007-02-06 13:15     ` [patch -trunk] " Stephen Smalley
                       ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Stephen Smalley @ 2007-02-06 13:06 UTC (permalink / raw)
  To: Stefanos Harhalakis
  Cc: selinux, Joshua Brindle, Karl MacMillan, Darrel Goeddel,
	Christopher J. PeBenito

On Tue, 2007-02-06 at 07:40 -0500, Stephen Smalley wrote:
> On Tue, 2007-02-06 at 04:12 +0200, Stefanos Harhalakis wrote:
> > I had this issue today:
> > 
> > # semodule -i logging.pp 
> > Segmentation fault (core dumped)
> > 
> > I traced this a bit and it seems that this is because of libsepol. 
> > The core dump is the result of lines 602:603 of link.c:
> > 
> > (gdb) bt
> > #0  0xb7f732fd in sens_copy_callback (key=0x848c2a0 "s15", datum=0x848c290, data=0xbfde3854) at link.c:602
> > #1  0xb7f6f8a1 in hashtab_map (h=0x846cbf0, apply=0xb7f731d1 <sens_copy_callback>, args=0xbfde3854) at hashtab.c:214
> > #2  0xb7f75528 in copy_identifiers (state=0xbfde3854, src_symtab=0x843cc74, dest_decl=0x0) at link.c:1323
> > #3  0xb7f77c72 in link_modules (handle=0x804c710, b=0x80525b8, mods=0x863ce18, len=19, verbose=0) at link.c:2178
> > #4  0xb7f7a2c9 in sepol_link_packages (handle=0x804c710, base=0x8053060, modules=0x80543c8, num_modules=19, verbose=0) at module.c:302
> > 
> > Where:
> > 
> > (gdb) l
> > 597                                 state->cur_mod_name);
> > 598                             return -SEPOL_LINK_NOTSUP;
> > 599                     }
> > 600             }
> > 601     
> > 602             state->cur->map[SYM_LEVELS][level->level->sens - 1] =
> > 603                 base_level->level->sens;
> > 604     
> > 605             return 0;
> > 606     }
> > 
> > Because of:
> > 
> > (gdb) p base_level
> > $1 = (level_datum_t *) 0x0
> > 
> > The last 'if' checks for !base_level, but inside the 'if' block, only 
> > !scope and scope->scope==SCOPE_DECL are checked.
> > 
> > This core dump is caused by:
> > 
> > (gdb) p scope->scope
> > $2 = 1
> > 
> > Which is noted as:
> > 
> > /* Required for this decl */
> > #define SCOPE_REQ  1
> > 
> > in libsepol/include/sepol/policydb/policydb.h
> > 
> > Hope this helps...
> 
> Looks like your logging.pp policy module has a requires on sensitivity
> s15 but your base module doesn't declare it.  Naturally, that should
> show up as an unfulfilled requirement rather than a seg fault.

Patch below for the stable branch.

Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>

Index: libsepol/src/link.c
===================================================================
--- libsepol/src/link.c	(revision 2221)
+++ libsepol/src/link.c	(working copy)
@@ -597,6 +597,13 @@
 			    state->cur_mod_name);
 			return -SEPOL_LINK_NOTSUP;
 		}
+		if (scope->scope == SCOPE_REQ) {
+			/* unmet requirement */
+			ERR(state->handle,
+			    "%s:  Sensitivity %s not declared by base.\n",
+			    state->cur_mod_name, id);
+			return -SEPOL_LINK_NOTSUP;
+		}
 	}
 
 	state->cur->map[SYM_LEVELS][level->level->sens - 1] =
@@ -628,6 +635,13 @@
 			    state->cur_mod_name);
 			return -SEPOL_LINK_NOTSUP;
 		}
+		if (scope->scope == SCOPE_REQ) {
+			/* unmet requirement */
+			ERR(state->handle,
+			    "%s:  Category %s not declared by base.\n",
+			    state->cur_mod_name, id);
+			return -SEPOL_LINK_NOTSUP;
+		}
 	}
 
 	state->cur->map[SYM_CATS][cat->s.value - 1] = base_cat->s.value;

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch -trunk] libsepol:  check for unmet requires on sensitivities and categories (Was:  Re: core dump)
  2007-02-06 13:06   ` [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump) Stephen Smalley
@ 2007-02-06 13:15     ` Stephen Smalley
  2007-02-06 15:05       ` Karl MacMillan
  2007-02-06 13:24     ` [patch] " V13
  2007-02-06 15:15     ` Karl MacMillan
  2 siblings, 1 reply; 9+ messages in thread
From: Stephen Smalley @ 2007-02-06 13:15 UTC (permalink / raw)
  To: Stefanos Harhalakis
  Cc: selinux, Joshua Brindle, Karl MacMillan, Darrel Goeddel,
	Christopher J. PeBenito

On Tue, 2007-02-06 at 08:06 -0500, Stephen Smalley wrote:
> On Tue, 2007-02-06 at 07:40 -0500, Stephen Smalley wrote:
> > On Tue, 2007-02-06 at 04:12 +0200, Stefanos Harhalakis wrote:
> > > I had this issue today:
> > > 
> > > # semodule -i logging.pp 
> > > Segmentation fault (core dumped)
> > > 
> > > I traced this a bit and it seems that this is because of libsepol. 
> > > The core dump is the result of lines 602:603 of link.c:
> > > 
> > > (gdb) bt
> > > #0  0xb7f732fd in sens_copy_callback (key=0x848c2a0 "s15", datum=0x848c290, data=0xbfde3854) at link.c:602
> > > #1  0xb7f6f8a1 in hashtab_map (h=0x846cbf0, apply=0xb7f731d1 <sens_copy_callback>, args=0xbfde3854) at hashtab.c:214
> > > #2  0xb7f75528 in copy_identifiers (state=0xbfde3854, src_symtab=0x843cc74, dest_decl=0x0) at link.c:1323
> > > #3  0xb7f77c72 in link_modules (handle=0x804c710, b=0x80525b8, mods=0x863ce18, len=19, verbose=0) at link.c:2178
> > > #4  0xb7f7a2c9 in sepol_link_packages (handle=0x804c710, base=0x8053060, modules=0x80543c8, num_modules=19, verbose=0) at module.c:302
> > > 
> > > Where:
> > > 
> > > (gdb) l
> > > 597                                 state->cur_mod_name);
> > > 598                             return -SEPOL_LINK_NOTSUP;
> > > 599                     }
> > > 600             }
> > > 601     
> > > 602             state->cur->map[SYM_LEVELS][level->level->sens - 1] =
> > > 603                 base_level->level->sens;
> > > 604     
> > > 605             return 0;
> > > 606     }
> > > 
> > > Because of:
> > > 
> > > (gdb) p base_level
> > > $1 = (level_datum_t *) 0x0
> > > 
> > > The last 'if' checks for !base_level, but inside the 'if' block, only 
> > > !scope and scope->scope==SCOPE_DECL are checked.
> > > 
> > > This core dump is caused by:
> > > 
> > > (gdb) p scope->scope
> > > $2 = 1
> > > 
> > > Which is noted as:
> > > 
> > > /* Required for this decl */
> > > #define SCOPE_REQ  1
> > > 
> > > in libsepol/include/sepol/policydb/policydb.h
> > > 
> > > Hope this helps...
> > 
> > Looks like your logging.pp policy module has a requires on sensitivity
> > s15 but your base module doesn't declare it.  Naturally, that should
> > show up as an unfulfilled requirement rather than a seg fault.

Second patch below for the trunk (I also stripped the extraneous \n 
characters from the first patch locally).

Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>

Index: libsepol/src/link.c
===================================================================
--- libsepol/src/link.c	(revision 2221)
+++ libsepol/src/link.c	(working copy)
@@ -598,6 +598,13 @@
 			    state->cur_mod_name);
 			return SEPOL_ENOTSUP;
 		}
+		if (scope->scope == SCOPE_REQ) {
+			/* unmet requirement */
+			ERR(state->handle,
+			    "%s: Sensitivity %s not declared by base.",
+			    state->cur_mod_name, id);
+			return SEPOL_ENOTSUP;
+		}
 	}
 
 	state->cur->map[SYM_LEVELS][level->level->sens - 1] =
@@ -629,6 +636,13 @@
 			    state->cur_mod_name);
 			return SEPOL_ENOTSUP;
 		}
+		if (scope->scope == SCOPE_REQ) {
+			/* unmet requirement */
+			ERR(state->handle,
+			    "%s: Category %s not declared by base.",
+			    state->cur_mod_name, id);
+			return SEPOL_ENOTSUP;
+		}
 	}
 
 	state->cur->map[SYM_CATS][cat->s.value - 1] = base_cat->s.value;

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] libsepol:  check for unmet requires on sensitivities and categories (Was:  Re: core dump)
  2007-02-06 13:06   ` [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump) Stephen Smalley
  2007-02-06 13:15     ` [patch -trunk] " Stephen Smalley
@ 2007-02-06 13:24     ` V13
  2007-02-06 14:38       ` Karl MacMillan
  2007-02-06 15:15     ` Karl MacMillan
  2 siblings, 1 reply; 9+ messages in thread
From: V13 @ 2007-02-06 13:24 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: selinux, Joshua Brindle, Karl MacMillan, Darrel Goeddel,
	Christopher J. PeBenito

On Tuesday 06 February 2007 15:06, Stephen Smalley wrote:
> Patch below for the stable branch.
>
> Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
>
> Index: libsepol/src/link.c
> ===================================================================
> --- libsepol/src/link.c	(revision 2221)
> +++ libsepol/src/link.c	(working copy)
> @@ -597,6 +597,13 @@
>  			    state->cur_mod_name);
>  			return -SEPOL_LINK_NOTSUP;
>  		}
> +		if (scope->scope == SCOPE_REQ) {
> +			/* unmet requirement */
> +			ERR(state->handle,
> +			    "%s:  Sensitivity %s not declared by base.\n",
> +			    state->cur_mod_name, id);
> +			return -SEPOL_LINK_NOTSUP;
> +		}
>  	}

May I recomend that an:

assert(0);

been added at the end of the outter if statement or there is no way that 
another SCOPE_ value will be added in the future. In the latter case, perhaps 
an enum (for the SCOPE_* values) and a switch() (instead of the ifs) would be 
better. gcc warns on switch() statements that don't handle all values of an 
enum.

<<V13>>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] libsepol:  check for unmet requires on sensitivities and categories (Was:  Re: core dump)
  2007-02-06 13:24     ` [patch] " V13
@ 2007-02-06 14:38       ` Karl MacMillan
  0 siblings, 0 replies; 9+ messages in thread
From: Karl MacMillan @ 2007-02-06 14:38 UTC (permalink / raw)
  To: V13
  Cc: Stephen Smalley, selinux, Joshua Brindle, Darrel Goeddel,
	Christopher J. PeBenito

V13 wrote:
> On Tuesday 06 February 2007 15:06, Stephen Smalley wrote:
>> Patch below for the stable branch.
>>
>> Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
>>
>> Index: libsepol/src/link.c
>> ===================================================================
>> --- libsepol/src/link.c	(revision 2221)
>> +++ libsepol/src/link.c	(working copy)
>> @@ -597,6 +597,13 @@
>>  			    state->cur_mod_name);
>>  			return -SEPOL_LINK_NOTSUP;
>>  		}
>> +		if (scope->scope == SCOPE_REQ) {
>> +			/* unmet requirement */
>> +			ERR(state->handle,
>> +			    "%s:  Sensitivity %s not declared by base.\n",
>> +			    state->cur_mod_name, id);
>> +			return -SEPOL_LINK_NOTSUP;
>> +		}
>>  	}
> 
> May I recomend that an:
> 
> assert(0);
> 
> been added at the end of the outter if statement or there is no way that 
> another SCOPE_ value will be added in the future.

I think this is a good practice in general, but it's not likely that 
another scope will be added.

  In the latter case, perhaps
> an enum (for the SCOPE_* values) and a switch() (instead of the ifs) would be 
> better. gcc warns on switch() statements that don't handle all values of an 
> enum.
> 

Enums aren't used often in libsepol and I'd rather not change to that 
style now.

Thanks - Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch -trunk] libsepol:  check for unmet requires on sensitivities and categories (Was:  Re: core dump)
  2007-02-06 13:15     ` [patch -trunk] " Stephen Smalley
@ 2007-02-06 15:05       ` Karl MacMillan
  0 siblings, 0 replies; 9+ messages in thread
From: Karl MacMillan @ 2007-02-06 15:05 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Stefanos Harhalakis, selinux, Joshua Brindle, Darrel Goeddel,
	Christopher J. PeBenito

Stephen Smalley wrote:
> On Tue, 2007-02-06 at 08:06 -0500, Stephen Smalley wrote:
> 
> Second patch below for the trunk (I also stripped the extraneous \n 
> characters from the first patch locally).
> 
> Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
> 

Acked-by: Karl MacMillan <kmacmillan@mentalrootkit.com> and merged into 
trunk as libsepol 2.0.1.

> Index: libsepol/src/link.c
> ===================================================================
> --- libsepol/src/link.c	(revision 2221)
> +++ libsepol/src/link.c	(working copy)
> @@ -598,6 +598,13 @@
>  			    state->cur_mod_name);
>  			return SEPOL_ENOTSUP;
>  		}
> +		if (scope->scope == SCOPE_REQ) {
> +			/* unmet requirement */
> +			ERR(state->handle,
> +			    "%s: Sensitivity %s not declared by base.",
> +			    state->cur_mod_name, id);
> +			return SEPOL_ENOTSUP;
> +		}
>  	}
>  
>  	state->cur->map[SYM_LEVELS][level->level->sens - 1] =
> @@ -629,6 +636,13 @@
>  			    state->cur_mod_name);
>  			return SEPOL_ENOTSUP;
>  		}
> +		if (scope->scope == SCOPE_REQ) {
> +			/* unmet requirement */
> +			ERR(state->handle,
> +			    "%s: Category %s not declared by base.",
> +			    state->cur_mod_name, id);
> +			return SEPOL_ENOTSUP;
> +		}
>  	}
>  
>  	state->cur->map[SYM_CATS][cat->s.value - 1] = base_cat->s.value;
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] libsepol:  check for unmet requires on sensitivities and categories (Was:  Re: core dump)
  2007-02-06 13:06   ` [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump) Stephen Smalley
  2007-02-06 13:15     ` [patch -trunk] " Stephen Smalley
  2007-02-06 13:24     ` [patch] " V13
@ 2007-02-06 15:15     ` Karl MacMillan
  2 siblings, 0 replies; 9+ messages in thread
From: Karl MacMillan @ 2007-02-06 15:15 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Stefanos Harhalakis, selinux, Joshua Brindle, Darrel Goeddel,
	Christopher J. PeBenito

Stephen Smalley wrote:
> On Tue, 2007-02-06 at 07:40 -0500, Stephen Smalley wrote:
>> On Tue, 2007-02-06 at 04:12 +0200, Stefanos Harhalakis wrote:
>>> I had this issue today:
>>>
>>> # semodule -i logging.pp 
>>> Segmentation fault (core dumped)
>>>
>>> I traced this a bit and it seems that this is because of libsepol. 
>>> The core dump is the result of lines 602:603 of link.c:
>>>
>>> (gdb) bt
>>> #0  0xb7f732fd in sens_copy_callback (key=0x848c2a0 "s15", datum=0x848c290, data=0xbfde3854) at link.c:602
>>> #1  0xb7f6f8a1 in hashtab_map (h=0x846cbf0, apply=0xb7f731d1 <sens_copy_callback>, args=0xbfde3854) at hashtab.c:214
>>> #2  0xb7f75528 in copy_identifiers (state=0xbfde3854, src_symtab=0x843cc74, dest_decl=0x0) at link.c:1323
>>> #3  0xb7f77c72 in link_modules (handle=0x804c710, b=0x80525b8, mods=0x863ce18, len=19, verbose=0) at link.c:2178
>>> #4  0xb7f7a2c9 in sepol_link_packages (handle=0x804c710, base=0x8053060, modules=0x80543c8, num_modules=19, verbose=0) at module.c:302
>>>
>>> Where:
>>>
>>> (gdb) l
>>> 597                                 state->cur_mod_name);
>>> 598                             return -SEPOL_LINK_NOTSUP;
>>> 599                     }
>>> 600             }
>>> 601     
>>> 602             state->cur->map[SYM_LEVELS][level->level->sens - 1] =
>>> 603                 base_level->level->sens;
>>> 604     
>>> 605             return 0;
>>> 606     }
>>>
>>> Because of:
>>>
>>> (gdb) p base_level
>>> $1 = (level_datum_t *) 0x0
>>>
>>> The last 'if' checks for !base_level, but inside the 'if' block, only 
>>> !scope and scope->scope==SCOPE_DECL are checked.
>>>
>>> This core dump is caused by:
>>>
>>> (gdb) p scope->scope
>>> $2 = 1
>>>
>>> Which is noted as:
>>>
>>> /* Required for this decl */
>>> #define SCOPE_REQ  1
>>>
>>> in libsepol/include/sepol/policydb/policydb.h
>>>
>>> Hope this helps...
>> Looks like your logging.pp policy module has a requires on sensitivity
>> s15 but your base module doesn't declare it.  Naturally, that should
>> show up as an unfulfilled requirement rather than a seg fault.
> 
> Patch below for the stable branch.
> 
> Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
> 

Acked-by: Karl MacMillan <kmacmillan@mentalrootkit.com> and merged as 
libsepol 1.16.1.

> Index: libsepol/src/link.c
> ===================================================================
> --- libsepol/src/link.c	(revision 2221)
> +++ libsepol/src/link.c	(working copy)
> @@ -597,6 +597,13 @@
>  			    state->cur_mod_name);
>  			return -SEPOL_LINK_NOTSUP;
>  		}
> +		if (scope->scope == SCOPE_REQ) {
> +			/* unmet requirement */
> +			ERR(state->handle,
> +			    "%s:  Sensitivity %s not declared by base.\n",
> +			    state->cur_mod_name, id);
> +			return -SEPOL_LINK_NOTSUP;
> +		}
>  	}
>  
>  	state->cur->map[SYM_LEVELS][level->level->sens - 1] =
> @@ -628,6 +635,13 @@
>  			    state->cur_mod_name);
>  			return -SEPOL_LINK_NOTSUP;
>  		}
> +		if (scope->scope == SCOPE_REQ) {
> +			/* unmet requirement */
> +			ERR(state->handle,
> +			    "%s:  Category %s not declared by base.\n",
> +			    state->cur_mod_name, id);
> +			return -SEPOL_LINK_NOTSUP;
> +		}
>  	}
>  
>  	state->cur->map[SYM_CATS][cat->s.value - 1] = base_cat->s.value;
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2007-02-06 15:15 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-06  2:12 core dump Stefanos Harhalakis
2007-02-06 12:40 ` Stephen Smalley
2007-02-06 13:06   ` [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump) Stephen Smalley
2007-02-06 13:15     ` [patch -trunk] " Stephen Smalley
2007-02-06 15:05       ` Karl MacMillan
2007-02-06 13:24     ` [patch] " V13
2007-02-06 14:38       ` Karl MacMillan
2007-02-06 15:15     ` Karl MacMillan
     [not found] <OF615DC251.A04042B9-ON4A256B61.007D0561-4A256B61.007D5D7B@au.ibm.com>
2002-02-16  3:24 ` Core dump Michael Sinz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.