Malloc config became global sysctl in 6.5

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Malloc config became global sysctl in 6.5

Igor Podlesny-2
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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Sebastien Marie-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
On Sat, 27 Apr 2019 at 12:26, Sebastien Marie <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Anthony J. Bentley-4
In reply to this post by Igor Podlesny-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley <[hidden email]> wrote:
>
> You didn't check the manpage.

you didn't think it over.
https://www.mail-archive.com/misc@.../msg167012.html

--
End of message. Next message?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Anthony J. Bentley-4
In reply to this post by Igor Podlesny-2
Igor Podlesny writes:

> On Sat, 27 Apr 2019 at 12:26, Sebastien Marie <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Theo de Raadt-2
In reply to this post by Igor Podlesny-2
Igor Podlesny <[hidden email]> wrote:

> On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley <[hidden email]> wrote:
> >
> > You didn't check the manpage.
>
> you didn't think it over.
> https://www.mail-archive.com/misc@.../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.

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
On Sat, 27 Apr 2019 at 12:46, Theo de Raadt <[hidden email]> wrote:
> Igor Podlesny <[hidden email]> wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley <[hidden email]> wrote:
> > > You didn't check the manpage.
> > you didn't think it over.
> > https://www.mail-archive.com/misc@.../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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Theo de Raadt-2
In reply to this post by Igor Podlesny-2
Igor Podlesny <[hidden email]> wrote:

> On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley <[hidden email]> wrote:
> >
> > You didn't check the manpage.
>
> you didn't think it over.
> https://www.mail-archive.com/misc@.../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.

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
In reply to this post by Anthony J. Bentley-4
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
In reply to this post by Theo de Raadt-2
On Sat, 27 Apr 2019 at 12:55, Theo de Raadt <[hidden email]> wrote:
> Igor Podlesny <[hidden email]> wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley <[hidden email]> wrote:
> > > You didn't check the manpage.
> >
> > you didn't think it over.
> > https://www.mail-archive.com/misc@.../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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Otto Moerbeek
In reply to this post by Theo de Raadt-2
On Fri, Apr 26, 2019 at 11:46:17PM -0600, Theo de Raadt wrote:

> Igor Podlesny <[hidden email]> wrote:
>
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley <[hidden email]> wrote:
> > >
> > > You didn't check the manpage.
> >
> > you didn't think it over.
> > https://www.mail-archive.com/misc@.../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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Consus-2
In reply to this post by Igor Podlesny-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Kevin Chadwick-4
In reply to this post by Otto Moerbeek
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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Marc Espie-2
In reply to this post by Igor Podlesny-2
On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:

> On Sat, 27 Apr 2019 at 12:26, Sebastien Marie <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
On Sat, 27 Apr 2019 at 18:09, Marc Espie <[hidden email]> wrote:

>
> On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Vincent Legoll
On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny <[hidden email]> wrote:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
On Sat, 27 Apr 2019 at 20:38, Vincent Legoll <[hidden email]> wrote:

>
> On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny <[hidden email]> wrote:
> > On Sat, 27 Apr 2019 at 18:09, Marc Espie <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

chohag
In reply to this post by Igor Podlesny-2
Igor Podlesny writes:

> On Sat, 27 Apr 2019 at 18:09, Marc Espie <[hidden email]> wrote:
> >
> > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Malloc config became global sysctl in 6.5

Igor Podlesny-2
On Sun, 28 Apr 2019 at 00:59, <[hidden email]> 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?

12