Use cases for various subject mode flags

Submit your RBAC policies or suggest policy improvements

Use cases for various subject mode flags

Postby countermode » Thu Mar 27, 2014 7:37 pm

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?
countermode
 
Posts: 27
Joined: Mon Sep 16, 2013 6:59 pm

Re: Use cases for various subject mode flags

Postby countermode » Thu Apr 03, 2014 6:59 pm

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?
countermode
 
Posts: 27
Joined: Mon Sep 16, 2013 6:59 pm

Re: Use cases for various subject mode flags

Postby spender » Fri Apr 04, 2014 7:24 am

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

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: Use cases for various subject mode flags

Postby countermode » Fri Apr 04, 2014 7:49 pm

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.
countermode
 
Posts: 27
Joined: Mon Sep 16, 2013 6:59 pm

Re: Use cases for various subject mode flags

Postby spender » Fri Apr 04, 2014 8:29 pm

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm


Return to RBAC policy development