Bagaimana mencegah chgrp dari membersihkan "setuid bit"?

Kami memiliki gambar Linux berbasis RH; di mana saya harus "menerapkan" beberapa "arsip khusus" untuk meningkatkannya ke versi pengembangan terbaru dari produk kami.

Orang yang membuat arsip menganggap bahwa di dalam gambar dasar kami, beberapa izin salah; jadi kami disuruh lari

sudo chgrp -R nobody /whatever

Kami melakukan itu; dan kemudian, ketika aplikasi kita berjalan, masalah yang tidak jelas muncul.

Apa yang saya temukan kemudian: panggilan ke chgrp akan menghapus informasi bit setuid pada binari kita di dalam / apa pun.

Dan masalah sebenarnya adalah: beberapa binari kita harus memiliki bit setuid yang diatur agar berfungsi dengan benar.

Singkat cerita: apakah ada cara untuk menjalankan perintah "chgrp" tanpa membunuh bit setuid saya?

Saya baru saja menjalankan yang berikut di Ubuntu lokal saya; mengarah ke hasil yang sama:

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

-> menunjukkan kepada saya nama file dengan latar belakang merah -> jadi, ya, setuid

chgrp -R myuser .
ls -al blub 

-> menunjukkan kepada saya nama file tanpa latar belakang merah -> setuid hilang

Jika Anda ingin menerapkan chgrp -R nobody /whateversambil mempertahankan bit setuid Anda dapat menggunakan dua findperintah ini

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

The find ... -perm 04000pilihan mengambil file dengan bit set setuid. Perintah pertama kemudian menerapkan chgrpdan kemudian chmoduntuk mengembalikan bit setuid yang telah terlempar. Yang kedua berlaku chgrpuntuk semua file yang tidak memiliki bit setuid.

Bagaimanapun, Anda tidak ingin memanggil chgrpatau chmodmenggunakan symlink karena itu akan mempengaruhi target mereka, karenanya ! -type l.

Menghapus bit SUID dan SGID pada chgrp(atau chown) sangat masuk akal. Ini adalah langkah keamanan untuk mencegah masalah keamanan. Untuk SGID (pada executable, saya kira) berarti menjalankan program ini dengan grup pemilik grup yang efektif .

Jika Anda mengubah pemilik grup, maka dalam hal keamanan dan kontrol akses, ini adalah sesuatu yang sama sekali berbeda, yaitu alih-alih berjalan dengan grup yang efektif uvw, program sekarang berjalan dengan grup yang efektif xyz.

Dengan demikian Anda harus mengembalikan bit SUID atau SGID secara eksplisit pada perubahan kepemilikan.

Tambahan: Pada klaim bahwa chgrp (atau chown) seharusnya hanya menghapus SGID (atau SUID, resp.)

Dengan chownatau chgrpmengubah pengaturan keamanan untuk yang dapat dieksekusi, dan ini adalah alasan yang cukup untuk menghapus atribut peningkatan hak istimewa. Kekuatan Unix berasal dari kesederhanaan konseptual, dan keamanan Unix sudah cukup rumit. Untuk tujuan ini, menghapus SUID dan SGID pada setiap perubahan kepemilikan hanyalah jaring pengaman - setelah semua, dalam sejarah Unix / Linux ada beberapa kerentanan karena pengaturan SUID atau SGID yang salah arah.

Jadi tidak ada alasan yang lebih dalam mengapa Unix berperilaku seperti ini, itu hanya keputusan desain yang konservatif.

Kliring bit setuid, setgid(setidaknya di Linux) pada non-direktori dilakukan oleh kernel setelah chown()panggilan sistem dilakukan chgrp, bukan dengan chgrpsendirinya. Jadi satu-satunya cara adalah mengembalikannya setelah itu.

Ini juga membersihkan kemampuan keamanan.

Jadi, di 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
)

Dan jalankan (as root):

chown_preseve_sec :newgroup file1 file2...

untuk mengubah grup saat berusaha mempertahankan izin.

Secara rekursif, Anda bisa melakukan:

# 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=-

(Itu semua dengan asumsi tidak ada yang mengacaukan file pada saat yang sama).

Seperti biasa dalam admin ada banyak cara untuk pergi.

Solusi yang saya tempatkan berjalan seperti ini:

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