De onde vem o UID / GID de um processo, quando não do ponteiro de cred do processo?

Question

Circunstâncias

Estou fazendo uma palestra sobre "Cloud Security" na Universidade e atualmente estou fazendo um projeto sobre introspecção de máquinas virtuais.

O objetivo do meu exercício era escalar privilégios de alguns processos para privilégios de root, o que consegui "emprestando" o ponteiro para struct cred de init , usando volatilidade e libvmi . Basicamente como alguns rootkits, mas de uma VM para outra. Eu posso provar o efeito desse método aumentando os privilégios de algum processo, que tenta repetidamente gravar na memória protegida. Assim:

#!/bin/bash
while true
do
    echo 1 >> /etc/test
    id
    sleep 2
done

Isso leva à seguinte saída (no momento em que os privilégios mudam):

# last time permission is denied
./test.sh: line 3: /etc/test: Permission denied
uid=1000(tester) gid=1000(tester)groups=1000(tester),24(cdrom),
25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),
111(scanner),115(bluetooth)

# tada, magic

# now I'm root
uid=0(root) gid=0(root) groups=0(root)

A questão

Para que eu possa provar que algum processo ( bash no exemplo acima) tem privilégios de root agora. Mas quando olho para o processo usando ps u ou diretamente via /proc/$PID , UID e GID parecem não ter mudado.

Saída de ps -A u | grep 2368 :

Antes:

# ...
tester    2368  0.0  0.9  23556  4552 pts/2    S+   22:24   0:00 -bash

Depois:

# ...
tester    2368  0.0  0.9  23556  4552 pts/2    S+   22:24   0:00 -bash

Nada mudou aqui.

Além disso, /proc/$PID/status não mudou:

~# cat /proc/2368/status | grep Uid
Uid:    1000    1000    1000    1000
~# cat /proc/2368/status | grep Gid
Gid:    1000    1000    1000    1000

Você pode explicar, por que eles não mudam lá, e onde essa informação veio, quando eles não foram tirados do processo struct cred , que foi obviamente alterado.

    

Answer 1

As tarefas não possuem uma estrutura cred. Eles têm dois struct cred's:

 * A task has two security pointers.  task->real_cred points to the objective
 * context that defines that task's actual details.  The objective part of this
 * context is used whenever that task is acted upon.
 *
 * task->cred points to the subjective context that defines the details of how
 * that task is going to act upon another object.  This may be overridden
 * temporarily to point to another security context, but normally points to the
 * same context as task->real_cred.

Eu verifiquei qual deles /proc mostra, mas você provavelmente pode adivinhar :-P.

(Veja fs / proc /, usando o link . O arquivo "status" do procfs é definido em fs / proc / base.c. )