1 |
2014.Június 8.(V) 15:22 időpontban Anthony G. Basile ezt írta: |
2 |
> On 06/08/14 04:31, "Tóth Attila" wrote: |
3 |
>> 2014.Június 8.(V) 02:55 időpontban Anthony G. Basile ezt írta: |
4 |
>>> On 06/07/14 17:48, "Tóth Attila" wrote: |
5 |
>>>> 2014.Június 7.(Szo) 23:22 időpontban Alex Efros ezt írta: |
6 |
>>>>> Some time ago I noticed this in kernel logs: |
7 |
>>>>> kern.alert: grsec: denied RWX mmap of <anonymous mapping> by |
8 |
>>>>> /usr/lib64/python-exec/python2.7/layman[layman:9717] |
9 |
>>>>> uid/euid:0/0 |
10 |
>>>>> gid/egid:0/0, parent /bin/bash[sh:9695] uid/euid:0/0 |
11 |
>>>>> gid/egid:0/0 |
12 |
>>>>> |
13 |
>>>>> Looks like it doesn't break layman, but I still wonder why it happens |
14 |
>>>>> and |
15 |
>>>>> is it possible to fix this (without paxmarking python, of course)? |
16 |
>>>> |
17 |
>>>> I don't see this in my logs. The python executable has the "E" flag on |
18 |
>>>> my |
19 |
>>>> systems. |
20 |
>>>> |
21 |
>>>> Dw. |
22 |
>>>> |
23 |
>>> |
24 |
>>> Okay I need to document this loudly --- not sure how to do that except |
25 |
>>> to just keep repeating it until it becomes public knowledge: |
26 |
>>> |
27 |
>>> When running with a pax kernel, you must enable EMUTRAMP in your |
28 |
>>> Kconfig |
29 |
>>> and you must paxmark your python exe's with E. Note: EMUTRAMP is on by |
30 |
>>> default and the ebuild automatically does the markings for you, so |
31 |
>>> leave |
32 |
>>> the defaults alone. |
33 |
>>> |
34 |
>>> If you don't, python apps will hit rwx mmap denials by the pax kernel. |
35 |
>>> Things like libffi try to work around this by spitting out little |
36 |
>>> snippets of code to the filesystem when the mmap fails; but, if you |
37 |
>>> have |
38 |
>>> strict TPE on, even this workaround fails and you get a pretty dead |
39 |
>>> system (all python apps badly crippled). There are various ways around |
40 |
>>> this but we've settled on the EMUTRAMP solution. See |
41 |
>> |
42 |
>> I see a problem here, that Alex has python binaries installed on his |
43 |
>> system with inconsistent PAX markings (PT: e, XATTR: E). I don't know |
44 |
>> his |
45 |
>> kernel config, but in my experience these flags can get misinterpreted |
46 |
>> instead of taking the XATTR:E flag or the default EMUTRAMP enabled. |
47 |
>> Despite it is not advised to keep both PT and XATTR markings on a system |
48 |
>> at the same time, some users may still have both and run into problems |
49 |
>> like Alex. |
50 |
>> I introduced kinda chpax init style logic as a workaround on my systems |
51 |
>> to |
52 |
>> double check sensitive binaries have correct PAX markings. |
53 |
>> Can we expect these symptoms to go away by the advent of the new |
54 |
>> hardened |
55 |
>> install helper? |
56 |
>> |
57 |
>> BR: Dw. |
58 |
>> |
59 |
> |
60 |
> Remember that the kernel decides what markings to look at. So if you |
61 |
> have XATTR_PAX enabled in the kernel, that's what it will look at and it |
62 |
> will ignore the other markings. In userland, the safest thing to do so |
63 |
> far is to enable both XATTR and PT markings in make.conf using |
64 |
> PAX_MARKINGS="XT PT". This will make sure the eclass does both markings. |
65 |
> |
66 |
> I've been slow (ie stuck) on how portage does wrapping but finally |
67 |
> figured out the issues. Today hopefully I'll have install-xattr wrapper |
68 |
> working with portage. Then its a matter of politicking it into portage. |
69 |
> At that point we will have end-to-end xattr support in portage and |
70 |
> people should be able to run a pure XATTR system. |
71 |
|
72 |
Alex reported correct XATTR marking and incorrect PT marking. He also |
73 |
told, that he disabled PT support in his kernel config. He was affected by |
74 |
the issue, but it's not clear for me: whether disabling PT support in |
75 |
kernel solved the problem alone, or paxctl-ng -f was also needed for |
76 |
happiness. |
77 |
|
78 |
BR: Dw. |
79 |
-- |
80 |
dr Tóth Attila, Radiológus, 06-20-825-8057 |
81 |
Attila Toth MD, Radiologist, +36-20-825-8057 |