Set-uid исполняемый и результирующий пользователь процесса

В Ubuntu 14.04 исполняемый файл passwd

 -rwsr-xr-x 1 root root 47032 gen 27 01:50 /usr/bin/passwd 

и исполняемый файл ping

 -rwsr-xr-x 1 root root 44168 mag 7 2014 /bin/ping 

поэтому (для обоих) uid текущего процесса должен приводить к возникновению root , даже если они запускаются от обычного пользователя. Если я запускаю passwd из user1 , на самом деле, я получаю

 $ ps -aux | grep passwd root 4317 0.0 0.0 85940 2004 pts/0 S+ 10:24 0:00 passwd 

но если я запускаю ping из user1 это не одно и то же:

 $ ps -aux | grep ping user1 4362 0.0 0.0 6500 632 pts/0 S+ 10:29 0:00 ping 192.168.8.1 

Почему uid процесса был установлен в root в первом случае, а не во втором?

3 Solutions collect form web for “Set-uid исполняемый и результирующий пользователь процесса”

Как говорит @schily, в утилите ping (и других) корневые разрешения удаляются после того, как они больше не нужны. Это делается по соображениям безопасности.

Из ping.c – main () – пользовательский корень отбрасывается с помощью вызова getuid и setuid.

getuid () получает текущего пользователя, а root, выполняющий setuid (), изменит uid процесса.

 /* * Pull this stuff up front so we can drop root if desired. */ if (!(proto = getprotobyname("icmp"))) { (void)fprintf(stderr, "ping: unknown protocol icmp.\n"); exit(2); } if ((s = socket(AF_INET, SOCK_RAW, proto->p_proto)) < 0) { if (errno==EPERM) { fprintf(stderr, "ping: ping must run as root\n"); } else perror("ping: socket"); exit(2); } #ifdef SAFE_TO_DROP_ROOT setuid(getuid()); /* HERE RETURNING TO THE USER */ #endif 

Uid второго процесса был сброшен уже потому, что после того, как сокеты были открыты, больше не нужно корневать.

Утилита passwd прежнему нуждается в привилегиях root при проверке.

Если вы хотите проверить это, вам нужно будет проверить исходный код, так как сброс uid может быть выполнен слишком быстро, чтобы дать другим возможность проверить uid до сброса.

Общий смысл замечания @ rui-f-ribeiro верен, но деталей нет. Подробности имеют значение. Ubuntu использует эти пакеты:

  • iputils-пин
  • ПАРОЛЬ

Утилита ping сбрасывает разрешения в функции с именем limit_capabilities , разделяемой ping и ping6. Соответствующий фрагмент кода выглядит так:

  if (prctl(PR_SET_KEEPCAPS, 1) < 0) { perror("ping: prctl"); exit(-1); } if (setuid(getuid()) < 0) { perror("setuid"); exit(-1); } if (prctl(PR_SET_KEEPCAPS, 0) < 0) { perror("ping: prctl"); exit(-1); } cap_free(cap_p); cap_free(cap_cur_p); #endif uid = getuid(); euid = geteuid(); #ifndef CAPABILITIES if (seteuid(uid)) { perror("ping: setuid"); exit(-1); } #endif 

То есть (прочитайте исходный код), ping выполняет несколько привилегированных операций и снижает привилегии, но может быть создан для того, чтобы вести себя по-разному в соответствии с предпочтениями.

Интересно, что в журнал изменений:

 iputils (3:20121221-2) unstable; urgency=low * Enable the CAP_NET_RAW capability and strip the setuid bit on ping and ping6 binaries if possible. 

История для passwd похожа, с различными деталями. Это часть теневого набора инструментов, которые могут отбрасывать привилегии в change_root :

  /* Drop privileges */ if ( (setregid (getgid (), getgid ()) != 0) || (setreuid (getuid (), getuid ()) != 0)) { fprintf (stderr, _("%s: failed to drop privileges (%s)\n"), Prog, strerror (errno)); exit (EXIT_FAILURE); } 

Но это делает это только в частном случае:

 /* * process_root_flag - chroot if given the --root option * * This shall be called before accessing the passwd, group, shadow, * gshadow, useradd's default, login.defs files (non exhaustive list) * or authenticating the caller. * * The audit, syslog, or locale files shall be open before */ 

В обычном случае он гарантирует, что он имеет привилегии и не оставляет их (потому что больше нечего делать, что не требует привилегии):

  if (setuid (0) != 0) { (void) fputs (_("Cannot change ID to root.\n"), stderr); SYSLOG ((LOG_ERR, "can't setuid(0)")); closelog (); exit (E_NOPERM); } 

Большинство утилит не сбрасывают поведение setuid / setgid, предполагая, что они не установлены с этими разрешениями.

  • почему разрешение setgid на SO вызывает сбои?
  • SUID-бит не работает для исполняемых файлов в каталоге / tmp
  • Разрешение исполняемого файла Unix и разрешения пользователя во время выполнения
  • Как установка бита Setuid влияет на сценарии оболочки, которые запускаются при загрузке системы, до того, как произошел какой-либо логин?
  • Почему ping требует разрешения setuid?
  • Как безопасно деактивировать разрешения для поддерева
  • crontab не выполняет мой скрипт?
  • Как suid iwconfig на Debian wheezy?
  • почему suid бит не отменяется после изменения файла
  • Использование find -perm для поиска файлов setuid
  • Изменение UID файлов в / proc
  • Linux и Unix - лучшая ОС в мире.