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
