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