Re: suenv
On Thu, Oct 25, 2012 at 03:58:33AM +0200, Emmanuel Dreyfus wrote: David Laight da...@l8s.co.uk wrote: Wasn't there a recent change to ld so that NEEDED entries are only added if the shared library is needed to resolve symbols? Which makes the naive addition of -lpthread useless. That seems the best workaround to the problem, but it was either not pulled up in netbsd-6, or it does not work. What files where touched with that change? It is not obvous in ld.elf_so. I'me thinking of a change to ld itself, maybe NetBSD hasn't imported that version yet. (Or my brain cells are faulty.) David -- David Laight: da...@l8s.co.uk
Re: suenv
On Wed, Oct 24, 2012 at 06:35:48AM +0200, Emmanuel Dreyfus wrote: Anyway, a deepre look at PCSC-lite shows that despite pthread_create being referenced libpcsclite.so, it is does not seems to be really called. Its presence seems to be the consequence of code sharing between libpcsclite.so and pcscd. I will try to patch so that libpcsclite.so does not use -lpthread anymore, but even if it works, that patch will be hard to sell upstream. Yes, that works, with pcsc-lite-1.5.5 we have in pkgsrc. Latest version is 1.8.6 so there is no point pushing the patch upstream. -- Emmanuel Dreyfus m...@netbsd.org
Re: suenv
On Tue, Oct 23, 2012 at 06:08:37PM +0200, Martin Husemann wrote: On Tue, Oct 23, 2012 at 04:31:52PM +0200, Emmanuel Dreyfus wrote: Opinions? Either PAM modules should not be allowed to use shared libraries that use pthreads, or we need to make sure every application using PAM is linked against libpthread. Wasn't there a recent change to ld so that NEEDED entries are only added if the shared library is needed to resolve symbols? Which makes the naive addition of -lpthread useless. I also dug into some linux libc.so and libpthread.so. AFAICT the mutex and condvar functions are in libc. There are somes stubs in libpthread that do a jump indirect, not sure what that is based on though. David -- David Laight: da...@l8s.co.uk
Re: suenv
David Laight da...@l8s.co.uk wrote: Wasn't there a recent change to ld so that NEEDED entries are only added if the shared library is needed to resolve symbols? Which makes the naive addition of -lpthread useless. That seems the best workaround to the problem, but it was either not pulled up in netbsd-6, or it does not work. What files where touched with that change? It is not obvous in ld.elf_so. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: suenv
On Tue, Oct 23, 2012 at 04:31:52PM +0200, Emmanuel Dreyfus wrote: Background: libpthread is tagged as not loadable by dlopen() in NetBSD-6.0. This breaks PAM modules that are linked with -lpthread or that dlopen() other objects linked with -lpthread. Don't do that, then. Thor
Re: suenv
On Tue, 23 Oct 2012, Emmanuel Dreyfus wrote: snip In that situation, and perhaps in others, it would be nice if the administrator could configure a trusted environement for setUID binaries. We would need a way to feed a colon-separated list of environement variables (example: LD_PRELOAD=/usr/lib/libpthread.so:FOO=bar). I see two way of dealing with it: 1) lookup in /etc/suenv.d/$progname (probably libc based) 2) use sysctl security.suenv.$progname (kernel based) I like the second one, which is simple to implement and cannot be messed up with incorrect file permissions. I would fix my problem like this: sysctl -w security.suenv.su=LD_PRELOAD=/usr/lib/libpthread.so sysctl -w security.suenv.login=LD_PRELOAD=/usr/lib/libpthread.so Opinions? This would require that the entire set of programs be known in advance, in order to create the sysctl(9) nodes. As far as I can tell, usermode code has no mechanism to create new nodes for other suid binaries that you might want to add. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: suenv
Thor Lancelot Simon t...@panix.com wrote: Background: libpthread is tagged as not loadable by dlopen() in NetBSD-6.0. This breaks PAM modules that are linked with -lpthread or that dlopen() other objects linked with -lpthread. Don't do that, then. Well, it is a shame that pam_p11 and pam_pkcs11 ceased to work on NetBSD with the 6.0 release. Do you advocate it should be left as is? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: suenv
On Tue, Oct 23, 2012 at 11:12:55AM -0400, Thor Lancelot Simon wrote: On Tue, Oct 23, 2012 at 04:55:16PM +0200, Emmanuel Dreyfus wrote: Thor Lancelot Simon t...@panix.com wrote: Background: libpthread is tagged as not loadable by dlopen() in NetBSD-6.0. This breaks PAM modules that are linked with -lpthread or that dlopen() other objects linked with -lpthread. Don't do that, then. Well, it is a shame that pam_p11 and pam_pkcs11 ceased to work on NetBSD with the 6.0 release. Do you advocate it should be left as is? I advocate that this is eminently better than pretending security software (that had trivially detectable buffer overruns) worked when in fact it worked, if at all, only more often than not. If those two modules have bugs, the bugs should be fixed. Breaking NetBSD to accomodate those modules' bugs is not an option! Is it a bug to use pthreads? Having trivially detectable buffer overruns sounds like a completely different issue than not being able to load libpthread, or are they related somehow? How did those modules work pre-6.0? I thought pthreads wouldn't work at all when loaded through dlopen because libc would have initialized in non-threaded mode at process startup. eric
Re: suenv
On Tue, 23 Oct 2012 10:32:18 -0400 Thor Lancelot Simon t...@panix.com wrote: On Tue, Oct 23, 2012 at 04:31:52PM +0200, Emmanuel Dreyfus wrote: Background: libpthread is tagged as not loadable by dlopen() in NetBSD-6.0. This breaks PAM modules that are linked with -lpthread or that dlopen() other objects linked with -lpthread. Don't do that, then. You appear to be ignoring the existence of the Real World. You may write all the software you use yourself, but the majority of us do not. If we did, this conversation wouldn't be happening. Emmanuel is making a proposal for a mechanism which will allow him to work around a Real World problem. I am not convinced his solution is the right one, but that doesn't make his problem disappear. Besides, a process wanting to use pthreads is not, itself, a bug. That there is no way for that to happen in this case arguably is. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: suenv
On Tue, Oct 23, 2012 at 04:31:52PM +0200, Emmanuel Dreyfus wrote: Opinions? Either PAM modules should not be allowed to use shared libraries that use pthreads, or we need to make sure every application using PAM is linked against libpthread. My vote is on the former. PAM modules (as all security code) should be simple and straight forward, threading never is. Martin
Re: suenv
Eric Haszlakiewicz e...@nimenees.com wrote: Having trivially detectable buffer overruns sounds like a completely different issue than not being able to load libpthread, or are they related somehow? They are different issues. The relation is just a rhetoric way of discarding that software as being relevant. :-) How did those modules work pre-6.0? I thought pthreads wouldn't work at all when loaded through dlopen because libc would have initialized in non-threaded mode at process startup. pre-6.0 allowed libpthread to be loaded by dlopen(), which was very unsafe as I understand. My idea to set LD_PRELOAD would revert functionnality without the hazard tied to dlopen() of libpthread, since it would be loaded at startup time. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: suenv
Thor Lancelot Simon t...@panix.com wrote: If those two modules have bugs, the bugs should be fixed. As Erik said, using pthread is not a bug. If we have a way to set LD_PRELOAD=/usr/lib/libpthread.so,, it works without any drawback. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: suenv
On Tue, 23 Oct 2012, Emmanuel Dreyfus wrote: About PAM modules invoking libpthread. I don't know if this is related or not, but is this an explanation of why, sometimes, generally using pkgsrc (when it switches to root), su(1) fails. May it be that depending on what one has being doing, or from what program (terminal) the commands are sent, the library may be already loaded or not, leading to a silent success or a perplexing failure? Best, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: suenv
On Tue, Oct 23, 2012 at 10:46:53AM -0500, Eric Haszlakiewicz wrote: On Tue, Oct 23, 2012 at 11:12:55AM -0400, Thor Lancelot Simon wrote: I advocate that this is eminently better than pretending security software (that had trivially detectable buffer overruns) worked when in fact it worked, if at all, only more often than not. If those two modules have bugs, the bugs should be fixed. Breaking NetBSD to accomodate those modules' bugs is not an option! Is it a bug to use pthreads? Having trivially detectable buffer overruns sounds like a completely different issue than not being able to load libpthread, or are they related somehow? They're related: look where the buffer overrun is. How did those modules work pre-6.0? I thought pthreads wouldn't work at all when loaded through dlopen because libc would have initialized in non-threaded mode at process startup. They may have appeared to work sometimes; even most of the time. But code that uses threads, executing within a process which was not linked against libpthread when it was built, cannot actually work all the time (nor is it guaranteed to work at all by the standard). It is like writing a large threaded program and leaving all the locking out of a few critical sections: you might trick the customer into thinking the few random failures and the consequent data corruption is his fault, but of course it will really be your fault. NetBSD 6 was fixed to loudly rather than silently fail in such cases. That was the right decision, rather tha allowing application authors to silently hose applicatio users. This case is particularly ugly, since the result of undefined application behavior can be a bad authentication decision! I submit that anyone who does not understand that that was what could happen before, nor that the various proposed solutios either heavily penalize correct, non-threaded applications or simply don't work in important cases has not actually looked at the details of the problem hard enough. There are cases where desperate, ugly hacks to make other people's incorrect code work most of the time are justifiable. The system authentication path is not one of them!
Re: suenv
On Tue, 23 Oct 2012 12:16:28 -0400 Thor Lancelot Simon t...@panix.com wrote: On Tue, Oct 23, 2012 at 10:46:53AM -0500, Eric Haszlakiewicz wrote: How did those modules work pre-6.0? I thought pthreads wouldn't work at all when loaded through dlopen because libc would have initialized in non-threaded mode at process startup. [...] NetBSD 6 was fixed to loudly rather than silently fail in such cases. That was the right decision, rather tha allowing application authors to silently hose applicatio users. Yes. There are cases where desperate, ugly hacks to make other people's incorrect code work most of the time are justifiable. The system authentication path is not one of them! I thought he was advocating a more generic kludge mechanic rather than one specific to authentication? Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: suenv
On Tue, Oct 23, 2012 at 05:05:27PM +0100, Julian Yon wrote: On Tue, 23 Oct 2012 10:32:18 -0400 Thor Lancelot Simon t...@panix.com wrote: On Tue, Oct 23, 2012 at 04:31:52PM +0200, Emmanuel Dreyfus wrote: Background: libpthread is tagged as not loadable by dlopen() in NetBSD-6.0. This breaks PAM modules that are linked with -lpthread or that dlopen() other objects linked with -lpthread. Don't do that, then. You appear to be ignoring the existence of the Real World. You may You appear to be ignoring the relevant standards. A process is either threaded or it is not, and thus a shared object which may be loaded into arbitrary processes must not use threads. Doing so in authentication software is just insane. In the real world I live in, one needs to be particularly careful with security software, not the other way around. Nasty hacks like subverting the protection against LD_PRELOAD on setuid executables are not called for in a case like this. If we resort to them, why should our users trust us to deliver quality software? If you want the wild west, you can find Debian's openssl patches over there -. Thor
Re: suenv
On Tue, Oct 23, 2012 at 06:19:25PM +0200, Emmanuel Dreyfus wrote: tlaro...@polynum.com wrote: I don't know if this is related or not, but is this an explanation of why, sometimes, generally using pkgsrc (when it switches to root), su(1) fails. May it be that depending on what one has being doing, or from what program (terminal) the commands are sent, the library may be already loaded or not, leading to a silent success or a perplexing failure? What PAM module do you use? Only the default ones (the default NetBSD installation; here a 5.1.2). I don't remember if I encountered the problem with 5.1.2. But with 5.0.x and previous, I had some. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: suenv
On Tue, 23 Oct 2012 12:21:42 -0400 Thor Lancelot Simon t...@panix.com wrote: You appear to be ignoring the relevant standards. A process is either threaded or it is not, and thus a shared object which may be loaded into arbitrary processes must not use threads. I'm not ignoring the standards, I'm just not ignoring the situation, either. Something which used to soft-fail now hard-fails (correctly), and this has bitten someone who is now trying to work out what would make a temporary fix possible in similar situations. Doing so in authentication software is just insane. In the real world I live in, one needs to be particularly careful with security software, not the other way around. Agreed. Nasty hacks like subverting the protection against LD_PRELOAD on setuid executables are not called for in a case like this. If we resort to them, why should our users trust us to deliver quality software? If you want the wild west, you can find Debian's openssl patches over there -. I'm not advocating his hack, merely noting that there's a Real World reason why it has been suggested. It reminds me of the old joke, “Doctor, it hurts when I do this.” “Don't do that then.” As someone who uses Linux as well as BSD I see exactly the same thing happen “over there”. Sometimes the crazy hacks that distributions put in place are a response to upstream refusing to come to some interim compromise while the real problem gets fixed (if it gets fixed, of course). I agree that this is Not NetBSD's Problem, but I wonder how many people devise their own insane “solutions” to this sort of thing and are put at risk by the lack of an official workaround? I'm thinking particularly of less experienced folk, here. -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: suenv
On Tue, Oct 23, 2012 at 06:08:37PM +0200, Martin Husemann wrote: My vote is on the former. PAM modules (as all security code) should be simple and straight forward, threading never is. This is my position as well. More generally: do not create threads from a library unless you are really, really, insane sure that every single user of the library wants multi-threaded operation. Joerg
Re: suenv
On Tue, 23 Oct 2012 18:30:21 +0200 m...@netbsd.org (Emmanuel Dreyfus) wrote: Thor Lancelot Simon t...@panix.com wrote: Nasty hacks like subverting the protection against LD_PRELOAD on setuid executables are not called for in a case like this. Why is it a hack? I immagine it only configurable by root, and I understand it would cleany enable the program to use threads. Or do I miss a point? From Thor's response I suspect that the LD_PRELOAD restriction that I asked you about (that I know is in Linux but wasn't sure about NetBSD) probably is in place. And it's a hack because the real problem in your specific case lies in the design of the module, not in the threads restriction. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: suenv
tlaro...@polynum.com wrote: I don't know if this is related or not, but is this an explanation of why, sometimes, generally using pkgsrc (when it switches to root), su(1) fails. May it be that depending on what one has being doing, or from what program (terminal) the commands are sent, the library may be already loaded or not, leading to a silent success or a perplexing failure? What PAM module do you use? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: suenv
Julian Yon jul...@yon.org.uk wrote: From Thor's response I suspect that the LD_PRELOAD restriction that I asked you about (that I know is in Linux but wasn't sure about NetBSD) probably is in place. And it's a hack because the real problem in your specific case lies in the design of the module, not in the threads restriction. I am not sure we can find any standard that backs the pthread prohibition for PAM modules. It was bad before because libpthread was dlopen() and operated in a process that did not had threading initialized, but as I understand, the LD_PRELOAD way address that problem. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: suenv
If those two modules have bugs, the bugs should be fixed. [...] Is it a bug to use pthreads? In the case of security-critical software, yes, I believe it is. In case it's not clear, I'm with Thor et al on this one. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: suenv
On Oct 23, 2012, at 2:26 PM, Mouse wrote: If those two modules have bugs, the bugs should be fixed. [...] Is it a bug to use pthreads? In the case of security-critical software, yes, I believe it is. Why? Because threaded software is too complex? But apache is security critical, isn't it? And it certainly is threaded. Or are you applying the term security critical only to a smaller set of components? paul
Re: suenv
In article c75a84166056c94f84d238a44af9f6ad277...@ausx10mpc103.amer.dell.com, paul_kon...@dell.com wrote: But apache is security critical, isn't it? And it certainly is threaded. Or are you applying the term security critical only to a smaller set of components? Yes, but apache is designed to be threaded. login, su, and other pam users not necessarily. Typically programs know the closure of shared libraries that they can potentially use, and PAM breaks that model. The threaded/non-threaded case is a particularly nasty example, where a program might assume that it can use static storage and non-threaded interfaces (res_foo() instead of res_nfoo(), getdbfoo() instead of getdbfoo_r()) and then suddenly it finds itself in a threaded environment and potential heisen bugs. In the apache case these may effect only the apache user and whatever access it has, but login/su and other PAM users cases this leads to a complete system compromise. christos
Re: suenv
On Oct 23, 2012, at 2:56 PM, Christos Zoulas wrote: In article c75a84166056c94f84d238a44af9f6ad277...@ausx10mpc103.amer.dell.com, paul_kon...@dell.com wrote: But apache is security critical, isn't it? And it certainly is threaded. Or are you applying the term security critical only to a smaller set of components? Yes, but apache is designed to be threaded. login, su, and other pam users not necessarily. Typically programs know the closure of shared libraries that they can potentially use, and PAM breaks that model. The threaded/non-threaded case is a particularly nasty example, where a program might assume that it can use static storage and non-threaded interfaces (res_foo() instead of res_nfoo(), getdbfoo() instead of getdbfoo_r()) and then suddenly it finds itself in a threaded environment and potential heisen bugs. In the apache case these may effect only the apache user and whatever access it has, but login/su and other PAM users cases this leads to a complete system compromise. christos That makes sense, thanks. paul
Re: suenv
In article 20121023162142.gb24...@panix.com, Thor Lancelot Simon t...@panix.com wrote: Nasty hacks like subverting the protection against LD_PRELOAD on setuid executables are not called for in a case like this. If we resort to them, why should our users trust us to deliver quality software? If you want the wild west, you can find Debian's openssl patches over there -. Not that I advocate doing that (and I will not provide the recipe to do it), but if you want to always load libpthread you can do so via ld.so.conf(5). Resist the temptation :-) christos
Re: suenv
Is it a bug to use pthreads? In the case of security-critical software, yes, I believe it is. Why? Because threaded software is too complex? Loosely put, yes. But apache is security critical, isn't it? No, or at least substantially less so - no more so than any network-exposed daemon. To pick one simple example, nobody with two brain cells to rub together runs apache as root (possibly excepting briefly during early startup - and if it doesn't throw away any such privilege long before it starts threading, I consider that a critical bug in it), whereas most of the things that use PAM must run as root. To pick another, the class of machines on which apache is unnecessary is much, much larger than the class of machines on which login and su (and, more generally, programs which by default are built with PAM) are unnecessary. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: suenv
On Tue, Oct 23, 2012 at 06:08:37PM +0200, Martin Husemann wrote: On Tue, Oct 23, 2012 at 04:31:52PM +0200, Emmanuel Dreyfus wrote: Opinions? Either PAM modules should not be allowed to use shared libraries that use pthreads, or we need to make sure every application using PAM is linked against libpthread. I have been wondering about the latter. Most direct users of the PAM interfaces are either quite small or already threaded, I think. This might almost agitate for forcing the issue by moving the PAM interfaces to libpthread, or to a separate library that depends explicitly on libpthread! However, doesn't libc code also call into the PAM stuff? Thor
Re: suenv
On Tue, Oct 23, 2012 at 12:54:43PM +0200, tlaro...@polynum.com wrote: On Tue, 23 Oct 2012, Emmanuel Dreyfus wrote: About PAM modules invoking libpthread. I don't know if this is related or not, but is this an explanation of why, sometimes, generally using pkgsrc (when it switches to root), su(1) fails. May it be that depending on what one has being doing, or from what program (terminal) the commands are sent, the library may be already loaded or not, leading to a silent success or a perplexing failure? Libraries don't work that way. -- David A. Holland dholl...@netbsd.org
Re: suenv
Christos Zoulas chris...@astron.com wrote: The threaded/non-threaded case is a particularly nasty example, where a program might assume that it can use static storage and non-threaded interfaces (res_foo() instead of res_nfoo(), getdbfoo() instead of getdbfoo_r()) and then suddenly it finds itself in a threaded environment and potential heisen bugs. Right, I see the risk here. But that just suggest that we should use thread-safe API everywhere. Anyway, a deepre look at PCSC-lite shows that despite pthread_create being referenced libpcsclite.so, it is does not seems to be really called. Its presence seems to be the consequence of code sharing between libpcsclite.so and pcscd. I will try to patch so that libpcsclite.so does not use -lpthread anymore, but even if it works, that patch will be hard to sell upstream. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
