Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
On Mon, Jul 30, 2007 at 07:45:39AM +0800, Eugene Teo wrote: > Hi Martin, > > Martin Pitt wrote: > > Eugene Teo [2007-07-29 21:03 +0800]: > Also, it is probably good to think how we can "drop privileges" while > piping > 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. > > >>> It was my understanding that apport already did this. > >> I haven't looked at apport yet, but are you talking about the userspace > >> portion of > >> 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? > We could do that I suppose, but /proc//* contains 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/ 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 no > one is using this "ispipe" feature, we just turn it off. > you mean like a build time config option? I'm not sure I see lots of value, 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. [EMAIL PROTECTED] *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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Hi Martin, Martin Pitt wrote: > Eugene Teo [2007-07-29 21:03 +0800]: Also, it is probably good to think how we can "drop privileges" while piping 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. >>> It was my understanding that apport already did this. >> I haven't looked at apport yet, but are you talking about the userspace >> portion of >> 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? Also, maybe it is good to make this portion of the code optional too, so that if no one is using this "ispipe" feature, we just turn it off. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Hi Eugene, Eugene Teo [2007-07-29 21:03 +0800]: > >> Also, it is probably good to think how we can "drop privileges" while > >> piping > >> 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. > >> > > It was my understanding that apport already did this. > > I haven't looked at apport yet, but are you talking about the userspace > portion of > 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). Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Neil Horman wrote: > On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote: >> Neil Horman wrote: [...] >> You may want to improve your patches with style-related changes, including >> removing trailing spaces, using tabs instead of spaces, and defining pointers >> like char *ptr instead of char * ptr. >> > I assume this is just a general comment, since as far as I can see, I've > followed those guidelines. Please see the next few emails. >> Also, it is probably good to think how we can "drop privileges" while piping >> 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. >> > It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of apport or the kernel changes in the Ubuntu kernel? Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote: > Neil Horman wrote: > > Ok, here we go > > > > As promised, I'm reposting the core_pattern enhancements I've done over the > > past > > few days. These three patches replace and conintue the work contained in > > the > > following patches, and can replace them: > > update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch > > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe.patch > > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix.patch > > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2.patch > > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-fix.patch > > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-sparc64-fix.patch > > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-sparc64-fix.patch > [...] > > You may want to improve your patches with style-related changes, including > removing trailing spaces, using tabs instead of spaces, and defining pointers > like char *ptr instead of char * ptr. > I assume this is just a general comment, since as far as I can see, I've followed those guidelines. > Also, it is probably good to think how we can "drop privileges" while piping > 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. > It was my understanding that apport already did this. Thanks and Regards Neil > Eugene -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Neil Horman wrote: > Ok, here we go > > As promised, I'm reposting the core_pattern enhancements I've done over the > past > few days. These three patches replace and conintue the work contained in the > following patches, and can replace them: > update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe.patch > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix.patch > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2.patch > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-fix.patch > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-sparc64-fix.patch > allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-sparc64-fix.patch [...] You may want to improve your patches with style-related changes, including removing trailing spaces, using tabs instead of spaces, and defining pointers like char *ptr instead of char * ptr. Also, it is probably good to think how we can "drop privileges" while piping 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. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Neil Horman wrote: Ok, here we go As promised, I'm reposting the core_pattern enhancements I've done over the past few days. These three patches replace and conintue the work contained in the following patches, and can replace them: update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-fix.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-sparc64-fix.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-sparc64-fix.patch [...] You may want to improve your patches with style-related changes, including removing trailing spaces, using tabs instead of spaces, and defining pointers like char *ptr instead of char * ptr. Also, it is probably good to think how we can drop privileges while piping 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. Eugene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote: Neil Horman wrote: Ok, here we go As promised, I'm reposting the core_pattern enhancements I've done over the past few days. These three patches replace and conintue the work contained in the following patches, and can replace them: update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-fix.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-sparc64-fix.patch allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix-2-sparc64-fix.patch [...] You may want to improve your patches with style-related changes, including removing trailing spaces, using tabs instead of spaces, and defining pointers like char *ptr instead of char * ptr. I assume this is just a general comment, since as far as I can see, I've followed those guidelines. Also, it is probably good to think how we can drop privileges while piping 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. It was my understanding that apport already did this. Thanks and Regards Neil Eugene -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Neil Horman wrote: On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote: Neil Horman wrote: [...] You may want to improve your patches with style-related changes, including removing trailing spaces, using tabs instead of spaces, and defining pointers like char *ptr instead of char * ptr. I assume this is just a general comment, since as far as I can see, I've followed those guidelines. Please see the next few emails. Also, it is probably good to think how we can drop privileges while piping 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. It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of apport or the kernel changes in the Ubuntu kernel? Eugene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Hi Eugene, Eugene Teo [2007-07-29 21:03 +0800]: Also, it is probably good to think how we can drop privileges while piping 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. It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of 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). Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Hi Martin, Martin Pitt wrote: Eugene Teo [2007-07-29 21:03 +0800]: Also, it is probably good to think how we can drop privileges while piping 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. It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of 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? Also, maybe it is good to make this portion of the code optional too, so that if no one is using this ispipe feature, we just turn it off. Eugene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
On Mon, Jul 30, 2007 at 07:45:39AM +0800, Eugene Teo wrote: Hi Martin, Martin Pitt wrote: Eugene Teo [2007-07-29 21:03 +0800]: Also, it is probably good to think how we can drop privileges while piping 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. It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of 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? We could do that I suppose, but /proc/pid of crashing process/* contains 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 no one is using this ispipe feature, we just turn it off. you mean like a build time config option? I'm not sure I see lots of value, 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. [EMAIL PROTECTED] *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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/