Как запретить очистке chgrp «бит setuid»?

У нас есть образы Linux на основе RH; на котором я должен «применить» некоторый «специальный архив», чтобы обновить их до последней версии разработки нашего продукта.

Человек, создавший архив, понял, что в нашем базовом изображении некоторые разрешения неверны; поэтому нам сказали бежать

sudo chgrp -R nobody /whatever

Мы сделали это; и позже, когда наше приложение работает, возникли неясные проблемы.

То , что я нашел позже: призыв к команде chgrp будет ясно Setuid битовой информации о наших двоичных файлах в пределах / независимо.

И настоящая проблема в том, что для правильной работы некоторых наших двоичных файлов должен быть установлен этот бит setuid.

Короче говоря: есть ли способ выполнить эту команду "chgrp", не убивая мои биты setuid?

Я просто запустил следующее в своей локальной Ubuntu; приводя к тому же результату:

mkdir sticky
cd sticky/
touch blub
chmod 4755 blub 
ls -al blub 

-> показывает мне имя файла с красным фоном -> так что, да, setuid

chgrp -R myuser .
ls -al blub 

-> показывает мне имя файла без красного фона -> setuid ушел

Если вы хотите реализовать свой chgrp -R nobody /whatever, сохраняя бит setuid, вы можете использовать эти две findкоманды

find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
                                      -exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +

find ... -perm 04000Вариант подбирает файлы с УИП битом. Первая команда затем применяет chgrpи затем a, chmodчтобы восстановить бит setuid, который был сбит. Второй относится chgrpко всем файлам, у которых нет бита setuid.

В любом случае, вы не хотите вызывать chgrpили использовать chmodсимволические ссылки, так как это повлияет на их цели, следовательно, на ! -type l.

Сброс битов SUID и SGID на chgrp(или chown) вполне разумен. Это мера безопасности для предотвращения проблем с безопасностью. Для SGID (на исполняемых файлах, я полагаю) означает запустить эту программу с эффективной группой владельца группы .

Если вы измените владельца группы, то с точки зрения безопасности и контроля доступа это будет что-то совершенно другое, то есть вместо того, чтобы работать с эффективной группой, uvwпрограмма теперь работает с эффективной группой xyz.

Таким образом, вам нужно явно восстановить бит SUID или SGID при смене владельца.

Приложение: к заявлению, что chgrp (или chown) должен очищать только SGID (или SUID, соответственно)

Используя chownили chgrpизменяя параметры безопасности для исполняемого файла, это является достаточной причиной для очистки любых атрибутов повышения привилегий. Сила Unix заключается в концептуальной простоте, а безопасность Unix уже достаточно сложна. С этой целью удаление SUID и SGID при любом изменении владельца является просто сетью безопасности - в конце концов, в истории Unix / Linux было довольно много уязвимостей из-за ошибочных настроек SUID или SGID.

Так что нет более глубокой причины, по которой Unix ведет себя так, это просто консервативное решение.

Просветление setuid, setgidнемного (по крайней мере на Linux) на не-каталогах осуществляются ядром на chown()системном вызов сделанного chgrp, а не chgrpсам по себе. Так что единственный способ - это восстановить его потом.

Это также очищает возможности безопасности.

Итак, на GNU Linux:

chown_preserve_sec() (
  newowner=${1?}; shift
  for file do
    perms=$(stat -Lc %a -- "$file") || continue
    cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
    chown -- "$newowner" "$file" || continue
    [ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
    chmod -- "$perms" "$file"
  done
)

И запустить (как root):

chown_preseve_sec :newgroup file1 file2...

изменить группу при попытке сохранить разрешения.

Вы можете сделать рекурсивно:

# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)

chgrp -RP nobody .

# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z  "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-

(это все, если предположить, что ничего не мешает одновременно с файлами).

Как обычно в админке есть много способов пройти.

Решение, которое я поставил на место, выглядит так:

cd /home/me
getfacl -R /whatever > whatever-permissions.org 2> /dev/null

# A) change lines starting with      # group: root
# to                                 # group: whatineed
sed 's/^# group: root/# group: whatineed/g' whatever-permissions.org > whatever-permissions.new

# B) change lines with               group::x.y
# to                                 group::xwy
# (where x, y mean: whatever was there before)
sed 's/^group::\(.\).\(.\)/group::\1w\2/g' whatever-permissions.new > whatever-permissions.new

cd /
setfacl --restore /home/me/whatever-permissions.new