Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Neil Horman <nhorman@xxxxxxxxxxxxx>
- Date: Sun, 29 Jul 2007 20:54:10 -0400
On Mon, Jul 30, 2007 at 07:45:39AM +0800, Eugene Teo wrote:
Hi Martin,We could do that I suppose, but /proc/<pid of crashing process>/* contains
Martin Pitt wrote:
Eugene Teo [2007-07-29 21:03 +0800]:
I haven't looked at apport yet, but are you talking about the userspace portion ofAlso, it is probably good to think how we can "drop privileges" while pipingIt was my understanding that apport already did this.
the core dump output to an external program. A malicious user can potentially
use it as a possible backdoor since anything that is executed by "|program" will
be executed with root privileges.
apport or the kernel changes in the Ubuntu kernel?
Similarly to Neil's patches, the Ubuntu kernel calls the userspace
helper as root, too. Apport drops privileges to the target process as
soon as possible (there are a few things it needs to do before, like
opening an fd to the crash file in /var/crash/ if that is only
writeable by root).
Just sharing some thoughts. Wouldn't it be more logical to drop the privileges first,
then call the userspace helper program? I know that this will limit tools like apport
to be able to read and/or write files that are only writable by root, but there ought
to be a better way to do this? What if the program piped is not a legitimate program?
informatino apport (and other apps need) to help diagnose problems during a
crash. To provide that information, we would then need to build out
infrastructure to pipe that information in-band through the pipe (perhaps
through ELF notes). Doable yes, but certainly not a small patch (consider
piping all of the files in /proc/<pid> as ELF notes).
Regarding security, and the use of non-legit programs: If the program pointed to
by core pattern does not exist, then the exec simply fails, and the core is
lost. Beyond that, core_pattern is only writable by root, and its teh sysadmins
responsibility to ensure that it points to valid and secured program.
Also, maybe it is good to make this portion of the code optional too, so that if noyou mean like a build time config option? I'm not sure I see lots of value,
one is using this "ispipe" feature, we just turn it off.
although, it seems like it would straightforward enough to do if you feel
strongly about it.
Regards
Neil
Eugene
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@xxxxxxxxxxxxx
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Neil Horman
- Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Eugene Teo
- Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Neil Horman
- Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Eugene Teo
- Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Martin Pitt
- Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- From: Eugene Teo
- [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- Prev by Date: Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1
- Next by Date: [PATCH] CPU online file permission
- Previous by thread: Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
- Next by thread: [PATCH 1/3] core_pattern: ignore RLIMIT_CORE if core_pattern is a pipe
- Index(es):
Relevant Pages
|
Loading