Re: Malloc config became global sysctl in 6.5
On Sun, 28 Apr 2019 at 02:43, Thomas Frohwein wrote: > > On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote: > [...] > > Looks like decision made aren't subjects of discussing(?) Well, why > > the hell you have those mail lists then(?) :) > > Igor: > The actual purpose of misc@ is for us to learn that you are among the people > to > ignore. You don't understand what "to ignore" mean then. Or fail to do what you say. Or learn too slow. ;-) -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
On 12:43 Sat 27 Apr, Thomas Frohwein wrote: > Move along, nothing to see here. I want to see more butthurting Theo!
Re: Malloc config became global sysctl in 6.5
Otto Moerbeek writes: > > The mechanism is in the docs as well, not only in the code. You You are of course correct, and OpenBSD has some of the best documentation I've ever seen, but I've spent so long in linux land that whenever I'm met with the question of how *exactly* something works, I just go straight to the source. Source code can't lie (trusting trust notwithstanding). > ignored my post about the symlink being confusing and error prone > since the time it is read (before or after the chroot) is program > dependent. It might even depend on options gives to a program when the > first malloc call happens, making it even more unclear which symlink > is being used. Add the complexity with respect to unveil and pledge > and it is clear why we replaced it. And I'm grateful. Having options - and such low-level options at that! - encoded in such a weird way has always felt extremely unopenbsd-like. This is another step toward sanity. Simplicity! Thank you, devs. Matthew
Re: Malloc config became global sysctl in 6.5
On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote: [...] > Looks like decision made aren't subjects of discussing(?) Well, why > the hell you have those mail lists then(?) :) Igor: The actual purpose of misc@ is for us to learn that you are among the people to ignore. Everyone else: Move along, nothing to see here.
Re: Malloc config became global sysctl in 6.5
Igor Podlesny writes: > On Sun, 28 Apr 2019 at 00:59, wrote: > [...] > > > > > > Oh, those hypocrite wankers here and there.. > > > > If you actually read the code (I know, right? Who DOES that?) you'll see > > how omalloc_ > init perfectly embarrasses you. In 6.4 it would read the symlink, then > checked the envi > ronment, and then consider the global variable malloc_options. In 6.5 it is > ... exactly > the same except that now sysctl is used instead of readlink (and hooray for > sanity). > > > > At no time was any attempt ever made by libc to force a programme to use > > only the set > tings from sysctl née malloc.conf. If you had been using the environment > variable from > the beginning you would have been in _exactly_ the same position all that > time as you a > re now. The security you think you've been relying on and have now lost was > never there > . You have been protecting yourself with security theatre. > > > > Matthew > > Matthew, LOL, what? > Read the code? > You didn't even read the whole comment thread where I did explain that > I was mostly concerned with cleared up environment other than changed > options of that variable. No, I did. I dismissed your arguments because they come from someone who plainly has no idea what "the environment" even is. malloc.c is quite lucid. Your continuing to spout off having clearly not even glanced at it is a sorry state of affairs. But this is unix. We'll continue to hand you as much rope as you like. > Actually, I'd say that preparing chroots with malloc.conf as a symlink > is more straightforward, more enforcing and easier to verify other > than putting that as an environment option that would actually have to > be read before target is running. How in the ... Stay the hell away from my servers. > And (of course) given with symlink > it can't be so easily vanished when the whole environment is cleared > up by user space. /etc/malloc.conf can disappear exactly as easily as /etc/profile and /etc/login.conf. More easily, in fact, if a tool to "handle" broken symlinks gets involved. > All-in-all, I didn't rely on this anyways. > My question was purely theoretical and reaction was practically clumsy. :) No, the reaction was dismissive of your complete lack of research and understanding. Why should the developers or us other list members take the time to read and understand the code you can't be arsed to? In order to find out exactly how malloc handles its various configuration sources took approximately 5 minutes of browsing on cvsweb.openbsd.org to find the appropriate function and I don't even know C that well. Your unwillingness to do even that is why you're being treated with such derision. > Looks like decision made aren't subjects of discussing(?) Well, why > the hell you have those mail lists then(?) :) Building something as large as OpenBSD simply cannot be done without discussion so this is either a poor quality attempt at derision or some sort of delusion. In fact I imagine that intellient discussion is restricted to places where the general public are not permitted so that it remain intelligent - for which I am most grateful. It's quite clear why you've not been invited. tl;dr: You don't understand and your ranting is just turning you into a spectacle. Please do continue; I have popcorn. Matthew
Re: Malloc config became global sysctl in 6.5
On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote: > On Sun, 28 Apr 2019 at 00:59, wrote: > [...] > > > > > > Oh, those hypocrite wankers here and there.. > > > > If you actually read the code (I know, right? Who DOES that?) you'll see > > how omalloc_init perfectly embarrasses you. In 6.4 it would read the > > symlink, then checked the environment, and then consider the global > > variable malloc_options. In 6.5 it is ... exactly the same except that now > > sysctl is used instead of readlink (and hooray for sanity). > > > > At no time was any attempt ever made by libc to force a programme to use > > only the settings from sysctl née malloc.conf. If you had been using the > > environment variable from the beginning you would have been in _exactly_ > > the same position all that time as you are now. The security you think > > you've been relying on and have now lost was never there. You have been > > protecting yourself with security theatre. > > > > Matthew > > Matthew, LOL, what? > Read the code? > You didn't even read the whole comment thread where I did explain that > I was mostly concerned with cleared up environment other than changed > options of that variable. > > Actually, I'd say that preparing chroots with malloc.conf as a symlink > is more straightforward, more enforcing and easier to verify other > than putting that as an environment option that would actually have to > be read before target is running. And (of course) given with symlink > it can't be so easily vanished when the whole environment is cleared > up by user space. > > All-in-all, I didn't rely on this anyways. > My question was purely theoretical and reaction was practically clumsy. :) > Looks like decision made aren't subjects of discussing(?) Well, why > the hell you have those mail lists then(?) :) > For users to come and thank you and say you did all the best possible > way only? :) > To never question any decision? Seriously? No, really? C'mon, you > gotta be kidding. > > -- > End of message. Next message? > The mechanism is in the docs as well, not only in the code. You ignored my post about the symlink being confusing and error prone since the time it is read (before or after the chroot) is program dependent. It might even depend on options gives to a program when the first malloc call happens, making it even more unclear which symlink is being used. Add the complexity with respect to unveil and pledge and it is clear why we replaced it. -Otto
Re: Malloc config became global sysctl in 6.5
On Sun, 28 Apr 2019 at 00:59, wrote: [...] > > > > Oh, those hypocrite wankers here and there.. > > If you actually read the code (I know, right? Who DOES that?) you'll see how > omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, > then checked the environment, and then consider the global variable > malloc_options. In 6.5 it is ... exactly the same except that now sysctl is > used instead of readlink (and hooray for sanity). > > At no time was any attempt ever made by libc to force a programme to use only > the settings from sysctl née malloc.conf. If you had been using the > environment variable from the beginning you would have been in _exactly_ the > same position all that time as you are now. The security you think you've > been relying on and have now lost was never there. You have been protecting > yourself with security theatre. > > Matthew Matthew, LOL, what? Read the code? You didn't even read the whole comment thread where I did explain that I was mostly concerned with cleared up environment other than changed options of that variable. Actually, I'd say that preparing chroots with malloc.conf as a symlink is more straightforward, more enforcing and easier to verify other than putting that as an environment option that would actually have to be read before target is running. And (of course) given with symlink it can't be so easily vanished when the whole environment is cleared up by user space. All-in-all, I didn't rely on this anyways. My question was purely theoretical and reaction was practically clumsy. :) Looks like decision made aren't subjects of discussing(?) Well, why the hell you have those mail lists then(?) :) For users to come and thank you and say you did all the best possible way only? :) To never question any decision? Seriously? No, really? C'mon, you gotta be kidding. -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
Igor Podlesny writes: > On Sat, 27 Apr 2019 at 18:09, Marc Espie wrote: > > > > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote: > > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote: > > > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote: > > > > > Previously users could have different behaviour of malloc > > > > > simultaneously: one i > n > > > > > global FS, others in chroots. Say, in global it could be more relaxed > > > [...] > > > > malloc(3) man page mentions several ways to set malloc options: > > > > > > > > - globally with vm.malloc_conf sysctl(2) > > > > - externally per apps with environment variable MALLOC_OPTIONS > > > > - internally per apps with global variable malloc_options in the program > > > > > > > > So I suppose you want to look at exported MALLOC_OPTIONS environment > > > > variable. > > > > > > Wrong. Environment is easy to be changed by any non-privileged process. > > > OTOH, root owned /etc/malloc.conf is not. > > > > Man, you have some really strange delusions about how to harden things. > > % man malloc.conf | grep -i security > S Enable all options suitable for security auditing. > > Oh, those hypocrite wankers here and there.. If you actually read the code (I know, right? Who DOES that?) you'll see how omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, then checked the environment, and then consider the global variable malloc_options. In 6.5 it is ... exactly the same except that now sysctl is used instead of readlink (and hooray for sanity). At no time was any attempt ever made by libc to force a programme to use only the settings from sysctl née malloc.conf. If you had been using the environment variable from the beginning you would have been in _exactly_ the same position all that time as you are now. The security you think you've been relying on and have now lost was never there. You have been protecting yourself with security theatre. Matthew
Re: Malloc config became global sysctl in 6.5
On Sat, 27 Apr 2019 at 20:38, Vincent Legoll wrote: > > On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny wrote: > > On Sat, 27 Apr 2019 at 18:09, Marc Espie wrote: > > > Man, you have some really strange delusions about how to harden things. > > > > % man malloc.conf | grep -i security > > S Enable all options suitable for security auditing. > > > > Oh, those hypocrite wankers here and there.. > > Looks like auditing and hardening are not exactly the same thing. And I didn't say "hardening". That's a delusion courtesy of Marc Espie "the wako". ;-) Although I can say "harder auditing" if you like. ;-) -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny wrote: > On Sat, 27 Apr 2019 at 18:09, Marc Espie wrote: > > Man, you have some really strange delusions about how to harden things. > > % man malloc.conf | grep -i security > S Enable all options suitable for security auditing. > > Oh, those hypocrite wankers here and there.. Looks like auditing and hardening are not exactly the same thing. -- Vincent Legoll
Re: Malloc config became global sysctl in 6.5
On Sat, 27 Apr 2019 at 18:09, Marc Espie wrote: > > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote: > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote: > > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote: > > > > Previously users could have different behaviour of malloc > > > > simultaneously: one in > > > > global FS, others in chroots. Say, in global it could be more relaxed > > [...] > > > malloc(3) man page mentions several ways to set malloc options: > > > > > > - globally with vm.malloc_conf sysctl(2) > > > - externally per apps with environment variable MALLOC_OPTIONS > > > - internally per apps with global variable malloc_options in the program > > > > > > So I suppose you want to look at exported MALLOC_OPTIONS environment > > > variable. > > > > Wrong. Environment is easy to be changed by any non-privileged process. > > OTOH, root owned /etc/malloc.conf is not. > > Man, you have some really strange delusions about how to harden things. % man malloc.conf | grep -i security S Enable all options suitable for security auditing. Oh, those hypocrite wankers here and there.. -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote: > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote: > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote: > > > Previously users could have different behaviour of malloc simultaneously: > > > one in > > > global FS, others in chroots. Say, in global it could be more relaxed > [...] > > malloc(3) man page mentions several ways to set malloc options: > > > > - globally with vm.malloc_conf sysctl(2) > > - externally per apps with environment variable MALLOC_OPTIONS > > - internally per apps with global variable malloc_options in the program > > > > So I suppose you want to look at exported MALLOC_OPTIONS environment > > variable. > > Wrong. Environment is easy to be changed by any non-privileged process. > OTOH, root owned /etc/malloc.conf is not. Man, you have some really strange delusions about how to harden things. I would suggest you go to another operating system. There are lots of wackos out there with similar mixes of paranoia and wishful thinking.
Re: Malloc config became global sysctl in 6.5
On 4/27/19 8:23 AM, Otto Moerbeek wrote: > Additionally, in many cases using a symlink has unclear effects, since > it is hard to determine if the first malloc call (malloc inits itself > on first use) happens before of after the chroot call. I would argue > that in many cases people were thinking they had per-chroot settings, > while actually they had not. Also, as Otto informed me on twitter, base is quite happy with the stronger settings. The code that really needs weaker settings inside the chroot, probably needs the stronger settings the most, technically (if it didn't break). I like the more convenient sysctl. Be careful though, S cost me a couple of hours last night. After much success on many systems without issue. I foolishly enabled S at the same time as PHP5 with suhosin to php7 upgrade, All the statically built pledged parts, femail, PHP output and reop, worked individually but femail would not send the mail when directly sent from PHP. I still don't understand how malloc S could cause that but turning back to the default, solved the breakage. In any case, the inherent clarity of what is happening under the hood in golang (php sh flags etc.) and the loss of php suhosin function whitelist feature (again) that has avoided so many CVEs has affirmed moving to golang. Therefore, I am not so bothered about finding why unless it helps OpenBSD somehow, which I doubt?
Re: Malloc config became global sysctl in 6.5
I like reading misc@ mostly due to the constanst BUTTHURT that is going on here. But seriously though, each program can change it's own malloc flags either by calling setenv(3) or just by updating static malloc_options variable. So there is really *NO* difference between your old way (/etc/malloc.conf) and your new way (setenv MALLOC_OPTIONS). There is a possibility that a program will reset it's own env, but it would most likely not.
Re: Malloc config became global sysctl in 6.5
On Fri, Apr 26, 2019 at 11:46:17PM -0600, Theo de Raadt wrote: > Igor Podlesny wrote: > > > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote: > > > > > > You didn't check the manpage. > > > > you didn't think it over. > > https://www.mail-archive.com/misc@openbsd.org/msg167012.html > > No, you didn't think it through at all. > > You are expecting the malloc settings to provide security gaurantees. > They do not. They detect corruption. That is not the same as > a security gaurantee. > > Then you wish to use this inside a chroot jail, and make it tighter. > > Fine. > > Next you argue but what if the program inside the jail adjusts > it's environment. Well then all bets are off. Why would that > program modify it's environment variable only, rather than just > doing anything else it wants to do? > > Why would it restrict itself to adjusting this specific environment > variable only, and why would you consider that to impact security? > > > The malloc configuration was moved to a sysctl to make it compatible > with pledge+unveil. It has tightened the security in many programs. > > The change has weakened security in your configurations because > you designed them wrong. Additionally, in many cases using a symlink has unclear effects, since it is hard to determine if the first malloc call (malloc inits itself on first use) happens before of after the chroot call. I would argue that in many cases people were thinking they had per-chroot settings, while actually they had not. -Otto > > Finally Igor you are being a jerk. Cut it out. >
Re: Malloc config became global sysctl in 6.5
On Sat, 27 Apr 2019 at 12:55, Theo de Raadt wrote: > Igor Podlesny wrote: > > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote: > > > You didn't check the manpage. > > > > you didn't think it over. > > https://www.mail-archive.com/misc@openbsd.org/msg167012.html > > Igor, talking back to the developers of the operating system you use is > never a good idea. Theo, if you can't read your mail list w/o losing your shit, don't make it public. -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
> > Wrong. Environment is easy to be changed by any non-privileged process. > > OTOH, root owned /etc/malloc.conf is not. > > Back then, when both /etc/malloc.conf and MALLOC_OPTIONS were set, which > did a program prefer? I'm more concerned with cleared up environment other than changed MALLOC_OPTIONS. > > -- > Anthony J. Bentley
Re: Malloc config became global sysctl in 6.5
Igor Podlesny wrote: > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote: > > > > You didn't check the manpage. > > you didn't think it over. > https://www.mail-archive.com/misc@openbsd.org/msg167012.html Igor, talking back to the developers of the operating system you use is never a good idea. There's this fine operating system that does exactly what you want -- it is called OpenBSD 6.4, go ahead, use it. You'll be happy. For 6 months, lots of people worked on changes which make this system better. Thousands upon thousands of hours of work. You were not one of those builders. Yet a few days after release, you jump in to criticize our design decisions, for software we primarily develop for ourselves -- in the hope that other people are like us and need similar things. We made decisions you don't understand because you haven't studied the reasons. You haven't read the commit messages. You don't understand our rationales, you only see your own point of view. So you come off as a ranty jerk. If you don't like our software, please don't use it.
Re: Malloc config became global sysctl in 6.5
On Sat, 27 Apr 2019 at 12:46, Theo de Raadt wrote: > Igor Podlesny wrote: > > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote: > > > You didn't check the manpage. > > you didn't think it over. > > https://www.mail-archive.com/misc@openbsd.org/msg167012.html > > No, you didn't think it through at all. > > You are expecting Now we enter that part were Theo becomes a medium. > Then you wish to use this inside a chroot jail, and make it tighter. > > Fine. > Next you argue but what if the program inside the jail adjusts > it's environment. Well then all bets are off. Why would that > program modify it's environment variable only, rather than just > doing anything else it wants to do? Because any user space daemon can clear up its own environment completely and put a big bold dick onto your malloc options, Theo. > Why would it restrict itself to adjusting this specific environment > variable only, and why would you consider that to impact security? > > > The malloc configuration was moved to a sysctl to make it compatible > with pledge+unveil. It has tightened the security in many programs. > > The change has weakened security in your configurations because > you designed them wrong. > > Finally Igor you are being a jerk. Cut it out. Very jerk-like sounding. Cut it out, Theo. But it's obvious you can't. Nature... -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
Igor Podlesny wrote: > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote: > > > > You didn't check the manpage. > > you didn't think it over. > https://www.mail-archive.com/misc@openbsd.org/msg167012.html No, you didn't think it through at all. You are expecting the malloc settings to provide security gaurantees. They do not. They detect corruption. That is not the same as a security gaurantee. Then you wish to use this inside a chroot jail, and make it tighter. Fine. Next you argue but what if the program inside the jail adjusts it's environment. Well then all bets are off. Why would that program modify it's environment variable only, rather than just doing anything else it wants to do? Why would it restrict itself to adjusting this specific environment variable only, and why would you consider that to impact security? The malloc configuration was moved to a sysctl to make it compatible with pledge+unveil. It has tightened the security in many programs. The change has weakened security in your configurations because you designed them wrong. Finally Igor you are being a jerk. Cut it out.
Re: Malloc config became global sysctl in 6.5
Igor Podlesny writes: > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote: > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote: > > > Previously users could have different behaviour of malloc simultaneously: > one in > > > global FS, others in chroots. Say, in global it could be more relaxed > [...] > > malloc(3) man page mentions several ways to set malloc options: > > > > - globally with vm.malloc_conf sysctl(2) > > - externally per apps with environment variable MALLOC_OPTIONS > > - internally per apps with global variable malloc_options in the program > > > > So I suppose you want to look at exported MALLOC_OPTIONS environment > > variable. > > Wrong. Environment is easy to be changed by any non-privileged process. > OTOH, root owned /etc/malloc.conf is not. Back then, when both /etc/malloc.conf and MALLOC_OPTIONS were set, which did a program prefer? -- Anthony J. Bentley
Re: Malloc config became global sysctl in 6.5
On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote: > > You didn't check the manpage. you didn't think it over. https://www.mail-archive.com/misc@openbsd.org/msg167012.html -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
Igor Podlesny writes: > Previously users could have different behaviour of malloc simultaneously: one > in > global FS, others in chroots. Say, in global it could be more relaxed > with lesser > performance impact and in some chroots more drastic, at contrary. With > 6.5 it's not > possible anymore, is it really so? This change has own pluses as well > indeed: one > knob to rule them all but then what if you need something special in > just one place, > something that shouldn't be following global sysctl parameters -- how > do you get it(?) You didn't check the manpage. Upon the first call to the malloc() family of functions, an initialization sequence inspects the value of the vm.malloc_conf sysctl(2), next checks the environment for a variable called MALLOC_OPTIONS, and finally looks at the global variable malloc_options in the program. -- Anthony J. Bentley
Re: Malloc config became global sysctl in 6.5
On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote: > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote: > > Previously users could have different behaviour of malloc simultaneously: > > one in > > global FS, others in chroots. Say, in global it could be more relaxed [...] > malloc(3) man page mentions several ways to set malloc options: > > - globally with vm.malloc_conf sysctl(2) > - externally per apps with environment variable MALLOC_OPTIONS > - internally per apps with global variable malloc_options in the program > > So I suppose you want to look at exported MALLOC_OPTIONS environment > variable. Wrong. Environment is easy to be changed by any non-privileged process. OTOH, root owned /etc/malloc.conf is not. -- End of message. Next message?
Re: Malloc config became global sysctl in 6.5
On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote: > Previously users could have different behaviour of malloc simultaneously: one > in > global FS, others in chroots. Say, in global it could be more relaxed > with lesser > performance impact and in some chroots more drastic, at contrary. With > 6.5 it's not > possible anymore, is it really so? This change has own pluses as well > indeed: one > knob to rule them all but then what if you need something special in > just one place, > something that shouldn't be following global sysctl parameters -- how > do you get it(?) malloc(3) man page mentions several ways to set malloc options: - globally with vm.malloc_conf sysctl(2) - externally per apps with environment variable MALLOC_OPTIONS - internally per apps with global variable malloc_options in the program So I suppose you want to look at exported MALLOC_OPTIONS environment variable. Thanks. -- Sebastien Marie
Malloc config became global sysctl in 6.5
Previously users could have different behaviour of malloc simultaneously: one in global FS, others in chroots. Say, in global it could be more relaxed with lesser performance impact and in some chroots more drastic, at contrary. With 6.5 it's not possible anymore, is it really so? This change has own pluses as well indeed: one knob to rule them all but then what if you need something special in just one place, something that shouldn't be following global sysctl parameters -- how do you get it(?) -- End of message. Next message?
