grsecurity forums

Hi,

I wonder what certain subject mode flags are good for in practice. Given that they are there for a reason I would like to know some legitimate use case(s) for them.

1. Subject mode a: Allow this process to talk to the /dev/grsec device.
   
   What program except gradm would talk to /dev/grsec? (Is the protocol for talking to /dev/grsec documented somewhere?)
   
2. Subject mode t: Allow ptracing of any process (do not use unless necessary, allows ptrace to cross subject boundaries). (...)
   
   And when for instance would that be necessary?
   
3. Subject mode x: Allows executable anonymous shared memory for this subject.
   
   What would be a plausible scenario for that? The only one I could think of is software that would not work at all otherwise. Anything else?
   
4. Subject mode A: Protect the shared memory of this subject. No other processes but processes contained within this subject may access the shared memory of this subject.
   
   Plausible use case?
   
5. Subject mode O: Allow loading of writable libraries.
   
   Sounds pretty bad. In what situation would one want that?

To be more specific on subject mode x:

I am trying to find an example where subject mode x makes a difference.

The kernel rejects

Code: Select all

mem = mmap(NULL, MAP_SIZE, PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS | MAP_SHARED, -1, 0);

as well as

Code: Select all

mem = mmap(NULL, MAP_SIZE, PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
mprotect(mem, MAP_SIZE, PROT_EXEC);

or vice versa. On the other hand

Code: Select all

mem = mmap(NULL, MAP_SIZE, PROT_READ|PROT_EXEC, MAP_ANONYMOUS | MAP_SHARED, -1, 0);

works fine.

For all of the above it does not matter whether grsec is active or not, and if it is, it does not matter wether subject mode x is set or not - the kernel simply does not allow shared memory that is (or was) writable and executable.

Therefore: what is subject mode x good for, and for what piece of code would it make a difference?

x is for SYSV IPC shared memory, not normal mmaps (that's handled by PAX_MPROTECT).

-Brad

Hi,

spender wrote:x is for SYSV IPC shared memory, not normal mmaps (that's handled by PAX_MPROTECT).

ah. so it's shmget/shmat stuff. I tried that but did not get much further. According to the manpage "Presently, the execute permissions are not used by the system.". Now, apparently various processes simply use mode 0700 with shmflg as ipcs -m tells me. Thus I tried something like

Code: Select all

id = shmget(IPC_PRIVATE, MEM_SIZE, 0700);
mem = shmat(id, NULL, 0);
memcpy(shellcode, mem, ...);
(*(void(*)()) mem)();


but PaX complains loudly and kills the process - and it doesn't matter whether grsec is on or off, subject mode x assigned or not. More elaborate code with two processes doesn't make a difference either. At the end of the day I still can't see what subject mode x is good for.

Code: Select all

#include <stdio.h>
#include <sys/types.h>
#include <sys/shm.h>

int main(void)
{
        int id = shmget(IPC_PRIVATE, 0x1000, 0700);
        char *mem = (char *)shmat(id, NULL, SHM_EXEC);
        mem[0] = '\xc3';
        (*(void(*)())mem)();
        printf("executed sysv shared memory.\n");
        return 0;
}


Disable mprotect on the binary. x mode is needed because by default RBAC prevents the shared memory execution and needs some override flag for the rare application that would ever need this.

-Brad