it-swarm-tr.com

Linux'ta ortam değişkeni erişilebilirliği

Belki de bu önemsiz bir soru, ancak Linux'taki ortam değişkenleri farklı kullanıcılar arasında ne kadar erişilebilir?

örneğin. Alice idam ederse

export FAVORITE_FOOD=`cat /home/alice/fav_food.txt`

Eve Alice'in en sevdiği yiyecekleri söyleyebilir mi? (Hem Alice hem de Havva'nın normal kullanıcılar olduğu ve Havva'nın /home/alice/fav_food.txt)

43
Yoav Aner

Gizli verilerin akışını izleyelim. Bu analizde Alice'in yapabildiği her şeyin, kökün de yapabileceği anlaşılmaktadır. Ayrıca harici bir gözlemci “bir seviye yukarı” (örn. Disk veriyolunda veya kod sanal makinede çalışıyorsa hipervizörde fiziksel erişime sahip olarak) verilere erişebilir.

İlk olarak, veriler bir dosyadan yüklenir. Dosyada yalnızca Alice'in okuma izni bulunduğunu ve dosyanın başka şekilde sızdırılmadığını varsayarsak, yalnızca Alice cat /home/alice/fav_food.txt başarıyla. Veriler daha sonra cat işleminin belleğindedir; burada yalnızca bu işlem erişebilir. Veriler bir boru üzerinden cat komutundan çağıran Kabuğa iletilir; yalnızca ilgili iki işlem borudaki verileri görebilir. Veriler daha sonra tekrar bu işleme özel olan Shell işleminin belleğindedir.

Bir noktada, veriler Shell'in ortamında sonuçlanır. Kabuğa bağlı olarak, export ifadesi yürütüldüğünde veya yalnızca Kabuk harici bir program yürüttüğünde gerçekleşebilir. Bu noktada, veriler bir execve sistem çağrısı argümanı olacaktır. Bu çağrıdan sonra, veriler alt süreç ortamında olacaktır.

Bir sürecin ortamı, o sürecin belleğinin geri kalanı kadar özeldir ( mm->env_start - mm->env_end işlemin bellek haritasında). ilk iş parçacığının yığını ile bitişiktir . Ancak, diğer işlemlerin ortamın bir kopyasını görüntülemesine izin veren özel bir mekanizma vardır: işlemin environ dosyası /proc dizin (/proc/$pid/environ). Bu dosya yalnızca sahibi tarafından okunabilir , kim işlemi çalıştıran kullanıcı (ayrıcalıklı bir işlem için, bu etkili UID'dir). (Komut satırı /proc/$pid/cmdline, öte yandan, herkes tarafından okunabilir.) Bunun, işlemin ortamına sızmanın tek yolu olduğunu doğrulamak için çekirdek kaynağını denetleyebilirsiniz.

Çevreyi sızdırmak için başka bir potansiyel kaynak daha vardır: execve çağrı sırasında. execve sistem çağrısı doğrudan çevreye sızmaz. Ancak, execve dahil olmak üzere her sistem çağrısının bağımsız değişkenlerini günlüğe kaydedebilen genel bir denetim mekanizması vardır. Denetim etkinleştirilmişse, ortam denetim mekanizması aracılığıyla gönderilebilir ve bir günlük dosyasına dönüştürülebilir. İyi yapılandırılmış bir sistemde, günlük dosyasına yalnızca yönetici erişebilir (varsayılan Debian kurulumumda /var/log/audit/audit.log, yalnızca kök tarafından okunabilir ve root olarak çalışan auditd arka plan programı tarafından yazılır).

Yukarıda yalan söyledim: Bir işlemin belleğinin başka bir işlem tarafından okunamayacağını yazdım. Aslında bu doğru değildir: Linux tüm unices gibi ptrace sistem çağrısını uygular. Bu sistem çağrısı, bir işlemin belleği denetlemesine ve hatta kodu başka bir işlem bağlamında yürütmesine izin verir. Hata ayıklayıcıların var olmasına izin veren şey budur. Alice'in süreçlerini sadece Alice izleyebilir. Ayrıca, bir işlem ayrıcalıklıysa (setuid veya setgid), yalnızca kök onu izleyebilir.

Sonuç: bir işlemin ortamı yalnızca işlemi çalıştıran kullanıcı tarafından kullanılabilir .

Veri sızdırabilecek başka bir işlem olmadığını varsayalım. Normal bir Linux kurulumunda bir sürecin ortamını açığa çıkarabilecek setuid kök programı yoktur. (Bazı eski birimlerde, ps bazı çekirdek belleğini ayrıştıran bir setuid kök programıydı; bazı varyantlar mutlu bir şekilde bir sürecin ortamını herkese gösterecektir. Linux'ta ps ayrıcalıksızdır ve /proc herkes gibi.).

(Bunun makul Linux sürümleri için geçerli olduğunu unutmayın. Çok uzun zaman önce, bence 1.x çekirdek günlerinde çevre dünya tarafından okunabilirdi.)

Başlangıçta "hayır" diyecektim. Ortam değişkeni değerleri kullanıcı başınadır ve başka hiçbir kullanıcı başka bir kullanıcının ortamını okuyamaz veya ona yazamaz. vars. Ancak, SO) üzerinde kökün en azından /proc/<pid>/environ. Şimdiye kadar Linux'a özgü bu arayüzün farkında değildim.

https://stackoverflow.com/a/532284/643314

Bununla birlikte, aynı arayüzde olsalar bile, bu arayüz diğer kullanıcılar tarafından hala okunamıyor gibi görünüyor. Çevre dosyası için izinler 400 olarak ayarlanmıştır ve/proc chmod'un dosyayı etkilemesini engeller. Kullanıcılar arasında ortam değişkeni ayrımı için güvenlik etki alanının hala sağlam olduğundan ve normal yollarla atlanamayacağından şüpheleniyorum.

4
logicalscope

Gilles'in teorik olarak doğru cevabına rağmen: Ortam değişkenlerine sır koymam.

  • Ortam değişkenleri genellikle işlem ağacının üst kısmına yakın bir yerde tanımlanır (örneğin, $HOME/.profile).
  • Kullanıcılar çevrenin içeriğini sır olarak görmezler.

Tek bir işlemin ortam değişkenlerini dünya tarafından okunabilir bir dosyaya kaydetmesi yeterlidir: env >> env-traces.txt veya benzeri. Kontrol edemezsiniz.

2
slowhand

Çoğu durumda başka bir kullanıcı ortam değişkenlerinizi okuyamaz. Bununla birlikte, bir setuid programının bir örneğinin setuid programının diğer herhangi bir örneğiyle aynı kullanıcı tarafından çalıştırıldığı iyi bilinen güvenlik açığından yararlanılabilir. Bu, eğer birisi bir setuid programı çalıştırıyorsa ve başka biri aynı kullanıcıya ayarlanmış başka bir programdan /proc/<pid>/environ sonra programın ortam değişkenlerini okuyabilirler. Kimse kullanıcısını kötüye kullanmak yerine, yazdığınız herhangi bir arka plan programı için yeni bir kullanıcı kullanmanızın nedeni budur.

katı politikalar yoksa, THEORETICALLY, bu dışa aktarma Alice için bir bash-login kullanıcı komut dosyasında yapılırsa bir yol vardır: Eve env'yi yazdırmak için bir komut dosyası oluşturur ve SETUIDGID bitlerini chmod olarak ayarlar ve sonra Alice'e koyar, sonra yürütür. Senaryo Alice'in kullanıcı kimliği altında yürütülecek ve bash autorun Alice'inki olacak. Sonra stdout =) ile veri sızdırıyor Ama böyle bir hile yapmak için çok zayıf bir sistem kurulumu olmalıdır. Adli tıp pratiğimde böyle çok yapılandırılmış bir kutu gördüm, bu yüzden bir şaka değil.

0
Alexey Vesnin