core dump

core dump

[Stefanos Harhalakis]

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.

Re: core dump

[Stephen Smalley]

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.

[patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump)

[Stephen Smalley]

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.

Re: [patch -trunk] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump)

[Stephen Smalley]

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.

Re: [patch -trunk] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump)

[Karl MacMillan]

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.

Re: [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump)

[V13]

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.

Re: [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump)

[Karl MacMillan]

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.

Re: [patch] libsepol: check for unmet requires on sensitivities and categories (Was: Re: core dump)

[Karl MacMillan]

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.

Re: Core dump

[Michael Sinz]

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.