Bug#679323: clearenv(3): implies that it's a security tool
tags 679323 + fixed-upstream stop - Will be fixed in man-pages-4.04. See commit c66649c8359865ff2a464e5b82284e6b1acf by Michael Kerrisk , 2016-02-19 12:04:51 (GMT) https://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/man3/clearenv.3?id=c66649c8359865ff2a464e5b82284e6b1acf - Matt Zimmerman a écrit : > On Fri, Feb 19, 2016 at 12:59:05PM +0100, Michael Kerrisk (man-pages) wrote: > > On 18 February 2016 at 21:34, Matt Zimmerman wrote: > > > Thanks for following up. My recommendation is to say something like: > > > > > > This function DOES NOT securely erase the contents of the environment. > > > Security-conscious applications which need to do this should use > > > instead. > > > > So, I think this report is a little confused, but mainly because of > > the poor description in the man page. > > > > The security-conscious applications in this context are those that > > want to precisely control the environment passed to an exec()ed > > program. clearenv() cannot, indeed must not, try to erase the buffers > > containing the environment definitions. (See putenv(3) to understand > > why.) I've adjusted the man page in away that I hope explains things > > better: > > > >The clearenv() function may be useful in security-conscious > >applications that want to precisely control the environment that > >is passed to programs executed using exec(3). The application > >would do this by first clearing the environment and then adding > >select environment variables. > > > >Note that the main effect of clearenv() is to adjust the value of > >the pointer environ(7); this function does not erase the contents > >of the buffers containing the environment definitions. > > Yes, that's much clearer, thank you! Case classified, thank you for your help Matt and Michael! Regards, -- Stéphane Aulery
Bug#679323: clearenv(3): implies that it's a security tool
On Fri, Feb 19, 2016 at 12:59:05PM +0100, Michael Kerrisk (man-pages) wrote: > On 18 February 2016 at 21:34, Matt Zimmerman wrote: > > Thanks for following up. My recommendation is to say something like: > > > > This function DOES NOT securely erase the contents of the environment. > > Security-conscious applications which need to do this should use > > instead. > > So, I think this report is a little confused, but mainly because of > the poor description in the man page. > > The security-conscious applications in this context are those that > want to precisely control the environment passed to an exec()ed > program. clearenv() cannot, indeed must not, try to erase the buffers > containing the environment definitions. (See putenv(3) to understand > why.) I've adjusted the man page in away that I hope explains things > better: > >The clearenv() function may be useful in security-conscious >applications that want to precisely control the environment that >is passed to programs executed using exec(3). The application >would do this by first clearing the environment and then adding >select environment variables. > >Note that the main effect of clearenv() is to adjust the value of >the pointer environ(7); this function does not erase the contents >of the buffers containing the environment definitions. Yes, that's much clearer, thank you! -- - mdz
Bug#679323: clearenv(3): implies that it's a security tool
Hello Michael and Matt, - Michael Kerrisk (man-pages) a écrit : > On 18 February 2016 at 21:34, Matt Zimmerman wrote: > > Thanks for following up. My recommendation is to say something like: > > > > This function DOES NOT securely erase the contents of the environment. > > Security-conscious applications which need to do this should use > > instead. > > So, I think this report is a little confused, but mainly because of > the poor description in the man page. > > The security-conscious applications in this context are those that > want to precisely control the environment passed to an exec()ed > program. clearenv() cannot, indeed must not, try to erase the buffers > containing the environment definitions. (See putenv(3) to understand > why.) I've adjusted the man page in away that I hope explains things > better: > >The clearenv() function may be useful in security-conscious >applications that want to precisely control the environment that >is passed to programs executed using exec(3). The application >would do this by first clearing the environment and then adding >select environment variables. > >Note that the main effect of clearenv() is to adjust the value of >the pointer environ(7); this function does not erase the contents >of the buffers containing the environment definitions. It's much better that I can do. If no objection Matt, I pass the bug report in fixed-upstream. Regards, -- Stéphane Aulery
Bug#679323: clearenv(3): implies that it's a security tool
On 18 February 2016 at 21:34, Matt Zimmerman wrote: > Thanks for following up. My recommendation is to say something like: > > This function DOES NOT securely erase the contents of the environment. > Security-conscious applications which need to do this should use > instead. So, I think this report is a little confused, but mainly because of the poor description in the man page. The security-conscious applications in this context are those that want to precisely control the environment passed to an exec()ed program. clearenv() cannot, indeed must not, try to erase the buffers containing the environment definitions. (See putenv(3) to understand why.) I've adjusted the man page in away that I hope explains things better: The clearenv() function may be useful in security-conscious applications that want to precisely control the environment that is passed to programs executed using exec(3). The application would do this by first clearing the environment and then adding select environment variables. Note that the main effect of clearenv() is to adjust the value of the pointer environ(7); this function does not erase the contents of the buffers containing the environment definitions. Cheers, Michael
Bug#679323: clearenv(3): implies that it's a security tool
Hello Matt, Le 18/02/2016 21:34, Matt Zimmerman a écrit : Thanks for following up. My recommendation is to say something like: This function DOES NOT securely erase the contents of the environment. Security-conscious applications which need to do this should use instead. Thanks for your reply. To match the note recommending a solution of withdrawal, then I suggest: - If it is unavailable the assignment environ = NULL; will probably do. But these solutions DO NOT securely erase the contents of the environment. ecurity-conscious applications which need to do this should use [...] instead. Problem, I have no idea of good security practice. A helping hand, please? Regards, -- Stéphane Aulery
Bug#679323: clearenv(3): implies that it's a security tool
Thanks for following up. My recommendation is to say something like: This function DOES NOT securely erase the contents of the environment. Security-conscious applications which need to do this should use instead. On Thu, Feb 18, 2016 at 06:28:19PM +0100, Stéphane Aulery wrote: > severity 679323 minor > stop > - > > Hello Matt, > > I dig your bug reports about the clearenv() function. > > Does the sentence below would do, please? > > >Used by security-conscious application, with the reservation >that the memory is not zeroed by the glibc implementation >before release. > > > Regards, > > -- > Stéphane Aulery -- - mdz
Bug#679323: clearenv(3): implies that it's a security tool
severity 679323 minor stop - Hello Matt, I dig your bug reports about the clearenv() function. Does the sentence below would do, please? Used by security-conscious application, with the reservation that the memory is not zeroed by the glibc implementation before release. Regards, -- Stéphane Aulery
