1 |
One more thing, this could be understood wrongly in one earlier mail I |
2 |
sent and was caused by my horrible english, |
3 |
<em>Before the filesystem capabilities one process |
4 |
with only CAP_SYS_RAWIO and the others restricted could add all |
5 |
others capabilities missing by simply searching the cap_bset in their |
6 |
system.map and writting 0xFFFFFEFF in it through /dev/mem. </em> |
7 |
|
8 |
This set the maximum capabilities that a new process could get, so, |
9 |
one system restricted to CAP_SYS_RAWIO could restore the complete |
10 |
Cap_bound set. You could remove for example an inmutable flag from a |
11 |
binary with only CAP_SYS_RAWIO, because you could set |
12 |
CAP_SYS_IMMUTABLE on in the cap_bset |
13 |
|
14 |
2008/12/5 Javier Martínez <tazok.id0@×××××.com>: |
15 |
> Have you said me that I'm obsoleted?, ok, I agreed with you... o:), |
16 |
> but since I don't use xorg in servers... no problem. You still having |
17 |
> the other problems I commented. One question, somebody knows what made |
18 |
> xorg incompatible with pax mprotect restrictions in earlier versions?. |
19 |
> |
20 |
> I put you a link that is newer than the link that Brian Kroth posted |
21 |
> and still having the incompatibilities on: |
22 |
> http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml, maybe a |
23 |
> mistake? |
24 |
> 2008/12/5 <pageexec@××××××××.hu>: |
25 |
>> On 25 Nov 2008 at 21:36, Javier Martínez wrote: |
26 |
>> |
27 |
>>> In my opinion getting X-window running is bad in security concerns, by |
28 |
>>> this reasons: |
29 |
>>> - First: PaX should be disable in mprotect terms since Xorg needs it |
30 |
>>> (with it refuse to run) . |
31 |
>> |
32 |
>> - PaX flags: -------x-e-- [/usr/bin/Xorg] |
33 |
>> |
34 |
>> and it works for me... so why do you need to disable MPROTECT on your Xorg? |
35 |
>> |
36 |
>> |
37 |
>> |
38 |
> |