Bagaimana mencegah chgrp dari membersihkan "setuid bit"?


8

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


1
The 4XXXbit disebut setuid bit ( s), tidak lengket. Sticky adalah tbit dan tujuannya sedikit berbeda: en.wikipedia.org/wiki/Sticky_bit
zuazo

2
(1) Anda sedang mengatur setuidbit, bukan stickybit. (2) Tidak membersihkan setuidbit saat Anda melakukan chgrpatau chownakan menjadi masalah keamanan.
Satō Katsura

1
Perilaku ini berubah di antara distribusi. Tetapi seperti yang dijelaskan di sini , perubahan bit setuid tergantung pada perilaku syscall yang mendasarinya.
zuazo

Terimakasih semuanya. Anda benar, ini tentang setuid bit! Terima kasih atas bantuan Anda. Dan saya juga menerima bahwa ini "berfungsi seperti yang dirancang". Sekarang saya hanya perlu menemukan cara paling waras untuk melakukan apa yang perlu dilakukan tanpa membunuh bit-bit itu. Saya mempertimbangkan untuk menggunakan gefacl untuk membuat dump teks, mengerjakan ulang konfigurasi teks dan kemudian menerapkannya. Itu seharusnya memberi saya kendali penuh atas apa yang akan terjadi.
GhostCat

Jawaban:


7

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.


Catatan yang chgrpjuga menghapus bit setgid (dan kemampuan di Linux) yang mungkin juga perlu dipulihkan.
Stéphane Chazelas

@ StéphaneChazelas Anda benar, tetapi sebagai setgid yang tidak ada yang disebutkan, saya tidak khawatir memberikan solusi untuk itu. Namun, solusinya dapat diperpanjang, dengan yang ketigafind
roaima

Yah itu tidak bisa menjadi temuan ke-3, Anda harus membahas kasus u + g, u sendiri, g sendiri. Bagaimanapun, Anda harus dapat melakukannya dalam satu findpermintaan. Saya tidak suka garis panjang di SE ketika Anda harus menggulir teks. Saya menambahkan! -tipe l membuatnya melampaui batas
Stéphane Chazelas

Yah, satu findpendekatan dengan -exec +mungkin sulit dilakukan andal jika itu akhirnya memecah chmod/ chgrps menjadi beberapa doa.
Stéphane Chazelas

1
Sebenarnya, saya pikir find . ! -type l -exec chgrp nobody {} + \( -perms -6000 -exec chmod gu+s {} + -o -perms -4000 -exec chmod u+s {} + -o -perms -2000 -exec chmod g+s {} + \)harus baik-baik saja. Karena chgrppertandingan untuk lebih banyak file, untuk setiap file itu harus dilakukan sebelum para chmods.
Stéphane Chazelas

5

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.


1
Ini dengan sempurna menjelaskan mengapa berganti pemilik menghapus bit SUID, dan mengubah grup menghapus bit SGID. Tetapi pertanyaannya adalah tentang bit SUID selama operasi perubahan grup yang tidak mempengaruhi pengguna yang menjalankan SUID. Jadi harus ada penjelasan yang berbeda.
Ben Voigt

1
@ BenVoigt: menjelaskannya cukup bagus. Baik chown dan chgrp memanggil chown () syscall, yang menghapus suid dan sgid pada file biasa, apa pun yang terjadi.
Joshua

1
@ Yosua: Itu deskripsi. Penjelasannya adalah "untuk menghindari kasus bahwa alih-alih berjalan dengan kelompok yang efektif uvw, program sekarang akan berjalan dengan kelompok yang efektif xyz", tetapi itu tidak berlaku untuk kasus yang sedang dibahas.
Ben Voigt

Itu benar. Dengan chownatau chgrpmengubah pengaturan keamanan, dan ini adalah alasan yang cukup untuk menghapus atribut peningkatan hak istimewa. Kemungkinannya tinggi sehingga hal ini menyerang yang tidak waspada.
countermode

4

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).


1

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
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.