Bir işlem belirli bir grup olarak çalışırken Linux izinleri nasıl çalışır?

Bu, herhangi bir yardımın takdir edilmesi için fazla bilgi bulamadığım bir şey.

Benim anlayışım böyledir. Aşağıdaki dosyayı alın:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

Kullanıcı philbu dosyaya erişemiyor:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

Eğer phililave edilir admgrubun, olabilir:

root@server:~# adduser phil adm
Adding user `phil' to group `adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

Ancak, bir süreç açıkça ayar iken başlatılır user:groupiçin phil:phildosyayı okuyamıyor bunun. İşlem şu şekilde başladı:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

İşlem şu şekilde başlatılırsa phil:adm, dosyayı okuyabilir:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

Yani soru gerçekten:

Belirli bir kullanıcı / grup birleşimiyle bir işlem yürütmenin, işlemin o kullanıcının ek gruplarına ait dosyalara erişmesini engelleyen ve bunun herhangi bir yolu var mı?

Bir işlem bir uid ang gid ile gerçekleştirilir. Her ikisinin de kendilerine atanmış izinleri vardır. Chroot'u, kullanıcının o grupta olmadığı bir kullanıcı ve grubun kullanıcı özelliğiyle arayabilirsiniz. İşlem daha sonra kullanıcı uid ve verilen gruplar gid ile yürütülür.

Bir örneğe bakın. Adlı bir kullanıcı var userve o grupta student:

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

Aşağıdaki gibi bir dosya var:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

Okuyamıyor:

user@host:~$ cat file
cat: file: Permission denied 

Şimdi, catişlemi kullanıcı userVE grup bağlamında yürütebilirim root. Şimdi, kedi sürecinin gerekli izinleri var:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

Ne dediğini görmek ilginç id:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Hm, ancak kullanıcı userbu grupta değil ( root). Nerede gelmez idonun bilgi almak? idBağımsız değişken olmadan çağrılırsa getuid(),, getgid()ve , sistem çağrılarını kullanır getgroups(). Böylece kendi süreç bağlamı idbasılır. Bu bağlamı değiştirdik --userspec.

idBağımsız değişkenle çağrıldığında , kullanıcının grup atamalarını belirler:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

Sorunuz için:

Belirli bir kullanıcı / grup birleşimiyle bir işlem yürütmenin, işlemin o kullanıcının ek gruplarına ait dosyalara erişmesini engelleyen ve bunun herhangi bir yolu var mı?

İşlemin yapması gereken her görevi çözmek için gereken güvenlik işlemi bağlamını ayarlayabilirsiniz. Her sürecin altında çalıştığı bir uid ve gid seti vardır. Normalde süreç, arayan kullanıcıları uid ve gid'i bağlamı olarak "alır". "Alır" ile çekirdeğin yaptığı anlamına gelir, aksi takdirde bir güvenlik sorunu olacaktır.

Yani, aslında dosyayı okumak için hiçbir izni olmayan kullanıcı değil, sürecin izinleri ( cat). Ancak süreç çağıran kullanıcının uid / gid ile çalışır.

Bu nedenle, kullanıcı adınızla ve bu grubun gidişi ile çalışacak bir işlem için belirli bir grupta olmanız gerekmez.

Üzerindeki --userspecseçeneğin kullanılması, chrootkullanıcıyı ve çalıştırırken kullanılacak tek bir grubu belirtir chroot. Ek grupları tanımlamak için --groupsseçeneği de kullanmanız gerekir .

Varsayılan olarak süreçler onları çalıştıran kullanıcının birincil ve ek gruplarını devralır, ancak kullanarak --userspecsen anlattığı chmodtek bir grubu kullanan belirtilen geçersiz kılmak için.

Linux'taki izinlerin ayrıntılı dokümantasyonu kılavuzda mevcuttur credentials(7).

Linux'ta oturum açtığınızda, oturum açma işlemi - phil olarak oturum açabildiğinizi doğruladıktan sonra - phil ve ait olduğu grupların uid'ini alır ve bunları kabuk olarak başlatılan bir işlem olarak ayarlar. Uid, gid ve tamamlayıcı gruplar, sürecin bir özelliğidir.

Bundan sonra başlayan herhangi bir program, bu kabuğun torunudur ve bu kimlik bilgilerinin bir kopyasını alır. * Bu, kullanıcının haklarının değiştirilmesinin çalışan işlemleri etkilememesini açıklar. Ancak değişiklikler bir sonraki girişte alınacaktır.

* İstisna, farklı etkili kullanıcı kimliğine sahip setuid veya setgid bitleri ayarlanmış programlardır . Bu, örneğin su (1) içinde kullanılır, böylece roottarafından yürütüldüğünde bile ayrıcalıklarla çalışabilir phil.

Eklediğiniz sonra philhiç admgrubun, aday olabileceğine su philve suKök- o gerçekten phil şifresini sağladığını doğrulamak ve sonra Phil ait gid uid ve tamamlayıcı gruplarla bir kabuk onu karaya olarak -Çalıştıran olacaktır. Ve bu, kullanıcıyı gruba ekledikten sonra yapıldığından, bu kabuk zaten admgrupta olur.

Chroot (1) 'i farklı bir kullanıcı olarak çalıştırmak için en uygun program olarak görmüyorum , ancak kesinlikle işi hallediyor. Parametre --userspec phil:philonu uid philve gid ile çalıştırır phil. Herhangi bir ek grup ayarlanmadı (bunun için sağlayacağınız --groups). Bu nedenle, çocuk süreci admgrupta değildir .

İşleminizi phil'de olduğu gibi yürütmenin daha normal bir yolu su phil -c "process". Gibi suyükleri uid, kullanıcı veritabanı bilgilerinden gid ve tamamlayıcı grupları, processkullanıcı şu anda sahip aynı kimlik bilgilerine sahip olacaktır.

¹ Bu olabilir login (1) , sshd, su, gdb veya diğer programlar. Ayrıca, büyük olasılıkla pam modülleri aracılığıyla yönetilmektedir.