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
