Mailing List Archive

2014.Június 7.(Szo) 23:22 időpontban Alex Efros ezt írta:
> Some time ago I noticed this in kernel logs:
> kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
> /usr/lib64/python-exec/python2.7/layman[layman:9717] uid/euid:0/0
> gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 gid/egid:0/0
>
> Looks like it doesn't break layman, but I still wonder why it happens and
> is it possible to fix this (without paxmarking python, of course)?

I don't see this in my logs. The python executable has the "E" flag on my
systems.

Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

Hi!

On Sat, Jun 07, 2014 at 11:48:53PM +0200, "Tóth Attila" wrote:
> > Some time ago I noticed this in kernel logs:
> > kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
> > /usr/lib64/python-exec/python2.7/layman[layman:9717] uid/euid:0/0
> > gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 gid/egid:0/0
> > Looks like it doesn't break layman, but I still wonder why it happens and
> > is it possible to fix this (without paxmarking python, of course)?
> I don't see this in my logs. The python executable has the "E" flag on my
> systems.

I've just re-emerged both pythons, here is flags:

# paxctl-ng -v /usr/bin/python?.?
/usr/bin/python2.7:
PT_PAX : -e---
XATTR_PAX : -E---

/usr/bin/python3.3:
PT_PAX : -e---
XATTR_PAX : -E---

Next, I've run eix-sync and get this in kernel log:

2014-06-07_23:07:50.51597 kern.alert: grsec: denied RWX mmap of <anonymous mapping> by /usr/lib64/python-exec/python2.7/layman[layman:3854] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0
2014-06-07_23:07:50.82796 kern.alert: grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/python3.3[emerge:3977] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0
2014-06-07_23:07:56.00097 kern.alert: grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/python3.3[egencache:4009] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0
2014-06-07_23:07:56.39894 kern.alert: grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/python3.3[egencache:4028] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0

# cat /etc/eix-sync.conf
*
@egencache --repo=powerman --update
@egencache --repo=local --update

--
WBR, Alex.

On 06/07/14 17:48, "Tóth Attila" wrote:
> 2014.Június 7.(Szo) 23:22 időpontban Alex Efros ezt írta:
>> Some time ago I noticed this in kernel logs:
>> kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
>> /usr/lib64/python-exec/python2.7/layman[layman:9717] uid/euid:0/0
>> gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 gid/egid:0/0
>>
>> Looks like it doesn't break layman, but I still wonder why it happens and
>> is it possible to fix this (without paxmarking python, of course)?
>
> I don't see this in my logs. The python executable has the "E" flag on my
> systems.
>
> Dw.
>

Okay I need to document this loudly --- not sure how to do that except
to just keep repeating it until it becomes public knowledge:

When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
default and the ebuild automatically does the markings for you, so leave
the defaults alone.

If you don't, python apps will hit rwx mmap denials by the pax kernel.
Things like libffi try to work around this by spitting out little
snippets of code to the filesystem when the mmap fails; but, if you have
strict TPE on, even this workaround fails and you get a pretty dead
system (all python apps badly crippled). There are various ways around
this but we've settled on the EMUTRAMP solution. See

https://bugs.gentoo.org/show_bug.cgi?id=484472

So my appologize everyone, we should do a better job at getting this
information out. mea culpa.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

2014.Június 8.(V) 01:13 időpontban Alex Efros ezt írta:
> Hi!
>
> On Sat, Jun 07, 2014 at 11:48:53PM +0200, "Tóth Attila" wrote:
>> > Some time ago I noticed this in kernel logs:
>> > kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
>> > /usr/lib64/python-exec/python2.7/layman[layman:9717] uid/euid:0/0
>> > gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 gid/egid:0/0
>> > Looks like it doesn't break layman, but I still wonder why it happens
>> and
>> > is it possible to fix this (without paxmarking python, of course)?
>> I don't see this in my logs. The python executable has the "E" flag on
>> my
>> systems.
>
> I've just re-emerged both pythons, here is flags:
>
> # paxctl-ng -v /usr/bin/python?.?
> /usr/bin/python2.7:
> PT_PAX : -e---
> XATTR_PAX : -E---
>
> /usr/bin/python3.3:
> PT_PAX : -e---
> XATTR_PAX : -E---
>
> Next, I've run eix-sync and get this in kernel log:
>
> 2014-06-07_23:07:50.51597 kern.alert: grsec: denied RWX mmap of <anonymous
> mapping> by /usr/lib64/python-exec/python2.7/layman[layman:3854]
> uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:3830] uid/euid:0/0
> gid/egid:0/0
> 2014-06-07_23:07:50.82796 kern.alert: grsec: denied RWX mmap of <anonymous
> mapping> by /usr/bin/python3.3[emerge:3977] uid/euid:0/0 gid/egid:0/0,
> parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0
> 2014-06-07_23:07:56.00097 kern.alert: grsec: denied RWX mmap of <anonymous
> mapping> by /usr/bin/python3.3[egencache:4009] uid/euid:0/0 gid/egid:0/0,
> parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0
> 2014-06-07_23:07:56.39894 kern.alert: grsec: denied RWX mmap of <anonymous
> mapping> by /usr/bin/python3.3[egencache:4028] uid/euid:0/0 gid/egid:0/0,
> parent /bin/bash[sh:3830] uid/euid:0/0 gid/egid:0/0
>
> # cat /etc/eix-sync.conf
> *
> @egencache --repo=powerman --update
> @egencache --repo=local --update

As you can see, your PT_PAX and XATTR_PAX flags are not consistent. The
XATTR_PAX flag holds the correct value, the PT_PAX flag is not OK.

Pleas issue the following commands and retry running layman or eix-sync:
paxctl-ng -f /usr/bin/python2.7
paxctl-ng -f /usr/bin/python3.3

"-f" sets the PT_PAX field according to the XATTR_PAX flags.

How your system behaves in case of inconsistent PAX flags also depends on
your kernel configuration. Although the behavior is not as I would expect
in my experience.

BR: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057



>
> --
> WBR, Alex.
>

2014.Június 8.(V) 02:55 időpontban Anthony G. Basile ezt írta:
> On 06/07/14 17:48, "Tóth Attila" wrote:
>> 2014.Június 7.(Szo) 23:22 időpontban Alex Efros ezt írta:
>>> Some time ago I noticed this in kernel logs:
>>> kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
>>> /usr/lib64/python-exec/python2.7/layman[layman:9717] uid/euid:0/0
>>> gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 gid/egid:0/0
>>>
>>> Looks like it doesn't break layman, but I still wonder why it happens
>>> and
>>> is it possible to fix this (without paxmarking python, of course)?
>>
>> I don't see this in my logs. The python executable has the "E" flag on
>> my
>> systems.
>>
>> Dw.
>>
>
> Okay I need to document this loudly --- not sure how to do that except
> to just keep repeating it until it becomes public knowledge:
>
> When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
> default and the ebuild automatically does the markings for you, so leave
> the defaults alone.
>
> If you don't, python apps will hit rwx mmap denials by the pax kernel.
> Things like libffi try to work around this by spitting out little
> snippets of code to the filesystem when the mmap fails; but, if you have
> strict TPE on, even this workaround fails and you get a pretty dead
> system (all python apps badly crippled). There are various ways around
> this but we've settled on the EMUTRAMP solution. See

I see a problem here, that Alex has python binaries installed on his
system with inconsistent PAX markings (PT: e, XATTR: E). I don't know his
kernel config, but in my experience these flags can get misinterpreted
instead of taking the XATTR:E flag or the default EMUTRAMP enabled.
Despite it is not advised to keep both PT and XATTR markings on a system
at the same time, some users may still have both and run into problems
like Alex.
I introduced kinda chpax init style logic as a workaround on my systems to
double check sensitive binaries have correct PAX markings.
Can we expect these symptoms to go away by the advent of the new hardened
install helper?

BR: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

Hi!

On Sun, Jun 08, 2014 at 10:31:58AM +0200, "Tóth Attila" wrote:
> > When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
> > and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
> > default and the ebuild automatically does the markings for you, so leave
> > the defaults alone.

Enabling EMUTRAMP fixed this issue, thanks!

> I see a problem here, that Alex has python binaries installed on his
> system with inconsistent PAX markings (PT: e, XATTR: E). I don't know his

I've disabled support for PT in kernel, so only XATTR value works and this
inconsistency isn't important. But, anyway, I wonder why after re-emerging
python it has this inconsistency in flags? (I've just run paxctl-ng -f and
it works - set PT flag to "E" instead of "e".)

--
WBR, Alex.

On 06/08/14 04:31, "Tóth Attila" wrote:
> 2014.Június 8.(V) 02:55 időpontban Anthony G. Basile ezt írta:
>> On 06/07/14 17:48, "Tóth Attila" wrote:
>>> 2014.Június 7.(Szo) 23:22 időpontban Alex Efros ezt írta:
>>>> Some time ago I noticed this in kernel logs:
>>>> kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
>>>> /usr/lib64/python-exec/python2.7/layman[layman:9717] uid/euid:0/0
>>>> gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 gid/egid:0/0
>>>>
>>>> Looks like it doesn't break layman, but I still wonder why it happens
>>>> and
>>>> is it possible to fix this (without paxmarking python, of course)?
>>>
>>> I don't see this in my logs. The python executable has the "E" flag on
>>> my
>>> systems.
>>>
>>> Dw.
>>>
>>
>> Okay I need to document this loudly --- not sure how to do that except
>> to just keep repeating it until it becomes public knowledge:
>>
>> When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
>> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
>> default and the ebuild automatically does the markings for you, so leave
>> the defaults alone.
>>
>> If you don't, python apps will hit rwx mmap denials by the pax kernel.
>> Things like libffi try to work around this by spitting out little
>> snippets of code to the filesystem when the mmap fails; but, if you have
>> strict TPE on, even this workaround fails and you get a pretty dead
>> system (all python apps badly crippled). There are various ways around
>> this but we've settled on the EMUTRAMP solution. See
>
> I see a problem here, that Alex has python binaries installed on his
> system with inconsistent PAX markings (PT: e, XATTR: E). I don't know his
> kernel config, but in my experience these flags can get misinterpreted
> instead of taking the XATTR:E flag or the default EMUTRAMP enabled.
> Despite it is not advised to keep both PT and XATTR markings on a system
> at the same time, some users may still have both and run into problems
> like Alex.
> I introduced kinda chpax init style logic as a workaround on my systems to
> double check sensitive binaries have correct PAX markings.
> Can we expect these symptoms to go away by the advent of the new hardened
> install helper?
>
> BR: Dw.
>

Remember that the kernel decides what markings to look at. So if you
have XATTR_PAX enabled in the kernel, that's what it will look at and it
will ignore the other markings. In userland, the safest thing to do so
far is to enable both XATTR and PT markings in make.conf using
PAX_MARKINGS="XT PT". This will make sure the eclass does both markings.

I've been slow (ie stuck) on how portage does wrapping but finally
figured out the issues. Today hopefully I'll have install-xattr wrapper
working with portage. Then its a matter of politicking it into portage.
At that point we will have end-to-end xattr support in portage and
people should be able to run a pure XATTR system.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

2014.Június 8.(V) 15:22 időpontban Anthony G. Basile ezt írta:
> On 06/08/14 04:31, "Tóth Attila" wrote:
>> 2014.Június 8.(V) 02:55 időpontban Anthony G. Basile ezt írta:
>>> On 06/07/14 17:48, "Tóth Attila" wrote:
>>>> 2014.Június 7.(Szo) 23:22 időpontban Alex Efros ezt írta:
>>>>> Some time ago I noticed this in kernel logs:
>>>>> kern.alert: grsec: denied RWX mmap of <anonymous mapping> by
>>>>> /usr/lib64/python-exec/python2.7/layman[layman:9717]
>>>>> uid/euid:0/0
>>>>> gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0
>>>>> gid/egid:0/0
>>>>>
>>>>> Looks like it doesn't break layman, but I still wonder why it happens
>>>>> and
>>>>> is it possible to fix this (without paxmarking python, of course)?
>>>>
>>>> I don't see this in my logs. The python executable has the "E" flag on
>>>> my
>>>> systems.
>>>>
>>>> Dw.
>>>>
>>>
>>> Okay I need to document this loudly --- not sure how to do that except
>>> to just keep repeating it until it becomes public knowledge:
>>>
>>> When running with a pax kernel, you must enable EMUTRAMP in your
>>> Kconfig
>>> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
>>> default and the ebuild automatically does the markings for you, so
>>> leave
>>> the defaults alone.
>>>
>>> If you don't, python apps will hit rwx mmap denials by the pax kernel.
>>> Things like libffi try to work around this by spitting out little
>>> snippets of code to the filesystem when the mmap fails; but, if you
>>> have
>>> strict TPE on, even this workaround fails and you get a pretty dead
>>> system (all python apps badly crippled). There are various ways around
>>> this but we've settled on the EMUTRAMP solution. See
>>
>> I see a problem here, that Alex has python binaries installed on his
>> system with inconsistent PAX markings (PT: e, XATTR: E). I don't know
>> his
>> kernel config, but in my experience these flags can get misinterpreted
>> instead of taking the XATTR:E flag or the default EMUTRAMP enabled.
>> Despite it is not advised to keep both PT and XATTR markings on a system
>> at the same time, some users may still have both and run into problems
>> like Alex.
>> I introduced kinda chpax init style logic as a workaround on my systems
>> to
>> double check sensitive binaries have correct PAX markings.
>> Can we expect these symptoms to go away by the advent of the new
>> hardened
>> install helper?
>>
>> BR: Dw.
>>
>
> Remember that the kernel decides what markings to look at. So if you
> have XATTR_PAX enabled in the kernel, that's what it will look at and it
> will ignore the other markings. In userland, the safest thing to do so
> far is to enable both XATTR and PT markings in make.conf using
> PAX_MARKINGS="XT PT". This will make sure the eclass does both markings.
>
> I've been slow (ie stuck) on how portage does wrapping but finally
> figured out the issues. Today hopefully I'll have install-xattr wrapper
> working with portage. Then its a matter of politicking it into portage.
> At that point we will have end-to-end xattr support in portage and
> people should be able to run a pure XATTR system.

Alex reported correct XATTR marking and incorrect PT marking. He also
told, that he disabled PT support in his kernel config. He was affected by
the issue, but it's not clear for me: whether disabling PT support in
kernel solved the problem alone, or paxctl-ng -f was also needed for
happiness.

BR: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

Hi!

On Sun, Jun 08, 2014 at 07:41:51PM +0200, "Tóth Attila" wrote:
> Alex reported correct XATTR marking and incorrect PT marking. He also
> told, that he disabled PT support in his kernel config. He was affected by
> the issue, but it's not clear for me: whether disabling PT support in
> kernel solved the problem alone, or paxctl-ng -f was also needed for
> happiness.

If kernel ignores PT then value of PT isn't affect anything, so there is
no need in keeping it same as XATTR value.

I was affected by the issue because while XATTR value was correct it
doesn't really works because I had EMUTRAMP disabled in kernel (so "E"
flag which mean "enable EMUTRAMP" has no effect).

--
WBR, Alex.

On 06/07/2014 08:55 PM, Anthony G. Basile wrote:
>
> When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
> default and the ebuild automatically does the markings for you, so leave
> the defaults alone.
>

Can linux-info.eclass be used to spit out a warning during a python emerge?

This,

use hardened && CONFIG_CHECK+=" ~CONFIG_PAX_EMUTRAMP"

seems like a common pattern. With a little more ingenuity we can
probably have it check the running/installed kernel and not the USE flag.

On Mon, Jun 9, 2014 at 7:43 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 06/07/2014 08:55 PM, Anthony G. Basile wrote:
> >
> > When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
> > and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
> > default and the ebuild automatically does the markings for you, so leave
> > the defaults alone.
> >
>
> Can linux-info.eclass be used to spit out a warning during a python emerge?
>
> This,
>
> use hardened && CONFIG_CHECK+=" ~CONFIG_PAX_EMUTRAMP"
>
> seems like a common pattern. With a little more ingenuity we can
> probably have it check the running/installed kernel and not the USE flag.
>

Where did the "Gentoo Linux" option in the kernel config disappear?
the one that had the
openrc / systemd options among other things.

Could we just add an option in there that will force EMUTRAMP for the
hardened-sources?

-- Jason

On 06/09/14 11:43, Michael Orlitzky wrote:
> On 06/07/2014 08:55 PM, Anthony G. Basile wrote:
>>
>> When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
>> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
>> default and the ebuild automatically does the markings for you, so leave
>> the defaults alone.
>>
>
> Can linux-info.eclass be used to spit out a warning during a python emerge?
>
> This,
>
> use hardened && CONFIG_CHECK+=" ~CONFIG_PAX_EMUTRAMP"
>
> seems like a common pattern. With a little more ingenuity we can
> probably have it check the running/installed kernel and not the USE flag.
>

Yes and no. I could add that as a warning but .... There is no
guarantee that the kernel you are building under is the kernel you will
be running under. So there's no way to warn against future stupidity.
Or current stupidity if your running kernel and kernel sources are out
of sync.

So I'm not a fan of linux-info.eclass.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 06/09/14 11:51, Jason Zaman wrote:
> On Mon, Jun 9, 2014 at 7:43 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>>
>> On 06/07/2014 08:55 PM, Anthony G. Basile wrote:
>>>
>>> When running with a pax kernel, you must enable EMUTRAMP in your Kconfig
>>> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by
>>> default and the ebuild automatically does the markings for you, so leave
>>> the defaults alone.
>>>
>>
>> Can linux-info.eclass be used to spit out a warning during a python emerge?
>>
>> This,
>>
>> use hardened && CONFIG_CHECK+=" ~CONFIG_PAX_EMUTRAMP"
>>
>> seems like a common pattern. With a little more ingenuity we can
>> probably have it check the running/installed kernel and not the USE flag.
>>
>
> Where did the "Gentoo Linux" option in the kernel config disappear?
> the one that had the
> openrc / systemd options among other things.
>
> Could we just add an option in there that will force EMUTRAMP for the
> hardened-sources?
>
> -- Jason
>

Its on by default. I could force it so you can't turn it off. But this
is gentoo and you need lots of rope ;) On a serious note, I can think
of instances where I want it off: eg. an embedded system which doesn't
even have python would gain security by having it off.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 06/10/2014 01:50 PM, Anthony G. Basile wrote:
>>
>> Can linux-info.eclass be used to spit out a warning during a python emerge?
>>
>> This,
>>
>> use hardened && CONFIG_CHECK+=" ~CONFIG_PAX_EMUTRAMP"
>>
>> seems like a common pattern. With a little more ingenuity we can
>> probably have it check the running/installed kernel and not the USE flag.
>>
>
> Yes and no. I could add that as a warning but .... There is no
> guarantee that the kernel you are building under is the kernel you will
> be running under. So there's no way to warn against future stupidity.
> Or current stupidity if your running kernel and kernel sources are out
> of sync.
>
> So I'm not a fan of linux-info.eclass.
>

It's not 100%, but it has to be more accurate than manually replying to
each bug report, right?

I think it's easy to overestimate the number of corner cases that normal
users run into with their kernels. Even on my home/work desktops, which
are a mess, most of the kernels that are lying around are pretty much
the same. If one of them has EMUTRAMP set, the rest do.

This might even be done once and for all in pax-utils.eclass. If a
package needs an -E marking, the user will probably want EMUTRAMP set at
runtime.