Re: denied RWX mmap by layman

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