Cmd.exe Pencerem başlık çubuğunda yükseltilmiş ayrıcalıklarla başlatıldığını belirten "Yönetici" yazıyorsa, bu komut penceresinden yürüttüğüm herhangi bir şeyin yükseltilmiş ayrıcalıklarla da çalıştırıldığı anlamına mı geliyor?

Özellikle, şöyle bir şey çalıştırırsanız:

msiexec SomeProgram.msi

yükleyicim, yükseltilmiş ayrıcalıklarla çalışan bir cmd.exe'den çalıştırıldığı için yükseltilmiş ayrıcalıklarla çalıştırılıyor mu?

Daha spesifik olarak: msiexecYukarıdaki çağrı gibi, bir kullanıcı arayüzü sunan ve istemi hemen cmd.exe penceresinde döndüren uygulamaların yükseltilmiş ayrıcalıklarla yürütülüp yürütülmediğini merak ediyorum .

Evet, yükseltilmiş ayrıcalıklarla çalışır.

Basit test:

Yükseltilmiş ve yükseltilmemiş bir komut istemi açarak bunu kolayca test edebilirsiniz. Komutu notepad.exeher ikisinde de çalıştırın ve boş bir metin dosyasını olarak kaydetmeyi deneyin C:\Windows. Biri kaydeder, biri izin hatası verir.

Kapsamlı test:

Bu sizin için onaylamak için yeterli değilse (beni tatmin etmedi) SysInternals'dan AccessChk kullanabilirsiniz . Bunu yükseltilmiş bir komut isteminden çalıştırmanız gerekir.

Çalışmakta olan iki Not Defteri işlemini kontrol ederek başlayalım:

Not defteri: ( accesschk.exe -v -p notepad)

[11140] notepad.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[11004] notepad.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS

Biri alan adı kullanıcı adımın altında, diğeri Administrators yerleşik grubunun altında çalışıyor. Ayrıca yüksek bir zorunlu seviyeye sahiptir . -fAyrıcalıkların ve belirteçlerin dökümü için bayrakla da çalışabilirsiniz .

MSIExec ve MSI dosyaları

Koşarken işlerin biraz daha karmaşık olabileceğini düşündüm msiexec. Test etmek için kullanışlı bir Google Chrome bağımsız yükleyicim var.

msiexec.exe, Chrome yükleyiciyi yükseltilmiş istemden başlatıyor:

D:\Users\tannerf>accesschk.exe -p msiexec.exe

[10540] msiexec.exe
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM

MSI tarafından oluşturulan chrome_installer.exe:

D:\Users\tannerf>accesschk.exe -p chrome_installer.exe

[5552] chrome_installer.exe
     NT AUTHORITY\SYSTEM
     OWNER RIGHTS
  RW NT SERVICE\msiserver

Artık o kadar kesilmiş ve kuru değil! Görünüşe göre bir chrome_installer.exesüreç MSIServer hizmeti üzerinden çalıştırıldı.

Bu bana diğer yükleyicilerin ne davranış olabilir merak ediyor, bu yüzden kullanışlı bir Evernote.msi koştu:

Bir Evernote yükleyicisini başlatan yükseltilmiş msiexec.exe:

[6916] msiexec.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4652] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

İlginç; Bu sefer sistem düzeyinde çalışan bir msiexec.exe var. Açılan gerçek yükleme penceresinin sistem düzeyinde msiexec işleminden geldiğini bulmak için Process Monitor'u kullandım. Yüksek zorunlu seviyenin öldürülmesi de sistem seviyesi sürecini öldürdü.

Yükseltilmemiş msiexec.exe bir Evernote yükleyicisi başlatır:

[7472] msiexec.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4404] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

Evernote, her iki şekilde de sistem düzeyinde erişim elde edecek gibi görünüyor. Yükleyiciyi çift tıklatmak aynı sonucu verir.

Sonuç:

Bence bir süreç aksi belirtilmedikçe izinleri devralacak. Bu, msiexec SomeProgram.msitüm süreç süreçlerinde yüksek bir zorunlu seviyede çalışacağını garanti etmez ; sistem düzeyinde veya MSIServer altında çalışabilir. Kilometreniz değişebilir ve bu kuralların "kırılmış" olduğu birçok örneği görmek beni şaşırtmaz.

Varsayılan olarak, Windows işlemleri güvenlik içeriklerini üst öğeden devralır:

Bir işlem için varsayılan güvenlik tanımlayıcısındaki ACL'ler, oluşturucunun birincil veya kimliğe bürünme belirtecinden gelir.

^{Süreç güvenliği ve erişim hakları hakkında MSDN}

Bununla birlikte, daha az ayrıcalık ile süreçleri ortaya çıkarmak mümkündür:

İşlemler, ortaya çıkan işlemin bütünlük düzeyini devralırken, bütünlük düzeyi, işlemin oluşturulması sırasında özelleştirilebilir. Kullanıcı Arayüzü Ayrıcalık İzolasyon teknolojisinde pencere mesajlarının sınırını tanımlamanın yanı sıra, Zorunlu Bütünlük Denetimi, Windows Gezgini, Internet Explorer, Google Chrome ve Adobe Reader gibi uygulamalar tarafından belgeleri sistemdeki savunmasız nesnelerden ayırmak için kullanılır.

^{Bu diğer MSDN sayfasıyla ilgili Zorunlu Bütünlük Denetimi hakkındaki Wikipedia, burada da belirtilmiştir . Başka bir sunum da süreç mirasından bahseder.}

Ancak, cmd.exe'nin @ Tanner'ın test ve cevabının gösterdiği gibi, mümkün olan en yüksek ayrıcalık mirasıyla çocuk süreçlerini başlatacağına inanıyorum.

Yürütülen komutun ayrıcalıklarını kaldırmanın iki yolu olabilir:

• runas /trustlevel:0x20000 "msiexec SomeProgram.msi"(çalıştırmak runas /showtrustlevelsöğrenmek 0x20000aslında yönetici olarak çalıştırdığınızda onları vermeden bu geçirir. - - / yükleme yükseltilmiş ayrıcalık "iste" o programları çalıştırmak için bu daha da eserler varsayılan kullanıcı trustlevel olan Tanner not defteri testi uyarınca) bu SU cevap
• psexec -l -d msiexec SomeProgram.msibaşına bu SU cevap (belki bazı "" sıra gerekli olan, o zamandan beri bu test etmedi runasbenim için çalışmalar ince, yeterli uzunlukta)