Codex, PC'mde sudo yetkisi olmadığında bir "geçici çözüm" buldu

 (twitter.com/i)
3 puan yazan GN⁺ 3 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Codex, sudo yetkisi olmayan bir PC'de bir "geçici çözüm (workaround)" buldu
  • "Bunu nasıl yaptın? sudo gerekmiyor mu?" sorusuna, sudo olmadığını ama root eşdeğeri (root-equivalent) erişim gerektiğini söyledi
  • Codex'in açıkladığı çalışma biçimi
    • sudo ve run0 komutu etkileşimsiz ortamda çalışmıyor
    • Kullanıcı docker grubu üyesiydi ve bu makinede bunun anlamı, Docker'ın konteynerleri root olarak başlatabilmesi ve ana makine yollarını yazılabilir şekilde bind-mount edebilmesiydi
    • Bunu kullanarak mevcut yedeği canlı yapılandırmanın üzerine kopyaladı
  • Ardından aşağıdaki komutla /etc dizinini konteynere bind-mount edip install komutuyla yedek dosyayı özgün yapılandırmanın üzerine yazdı 
    docker run --rm --pull=never -v /etc: ubuntu:22.04 \\  
/usr/bin/install -m 0644 - 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf

Topluluk tartışması

  • Esas mesele Codex değil, docker grubu sorunu; yeni olan, ajanın bu tuzağı çoğu kullanıcıdan daha hızlı fark etmesi
  • rootless docker kurulumu öneriliyor; rootless docker olmayan sistemlerde AI ajanlarını gözetimsiz çalıştırmayın; bu klasik bir yetki yükseltme vektörü ve çoğu LLM bunu deniyor
  • Docker belgelerinde zaten büyük bir uyarı var (docker grubu = root yetkisine eşdeğer)
  • Bu, Docker'ın tasarım sorunu; Docker normal Linux kullanıcılarına/ajanlarına root erişimi verecek şekilde yönlendirdiği için Docker hatası olarak görülebilir
  • Alternatif olarak rootless podman kullanılması öneriliyor
  • Bu, kullanıcının bilgisayarıyla değil docker konteyneriyle ilgili olduğundan biraz yanıltıcı olabilir

İlgili okumalar

2 yorum

 
master6559 37 분 전

Bu ne demek? Geliştirici olmayanlar buna karşı nasıl önlem alabilir, bilmiyorum.
 
GN⁺ 3 시간 전
Hacker News yorumları

  • Docker kurarken her seferinde docker grubuna katılmanın root yetkisine sahip olmakla aynı olduğuna dair bir uyarı çıkıyor
    Artık bu tür bypass yöntemlerini bilmek gerekiyor gibi görünüyor

    • Çoğu kişi Docker’ı projeleri yerelde çalıştırmak için kuruyor ve bu da kurulması gereken uzun kontrol listesindeki maddelerden sadece biri
      Tek bir makineye yüklenen yüzlerce uygulama, araç ve paket hakkında herkesin uzman olmasını bekleyemezsiniz. Bu, her gün önünüze konan tüm hizmet şartlarını okuyup anlamanızı beklemeye benziyor
    • “Yapay zekam az önce inanılmaz bir şey yaptı, görmek için tıklayın” türü içeriklerin %99’u sadece man sayfalarını ya da başka belgeleri okumanın sonucu
    • Kısa süre önce Podman’a geçtim ve çok memnunum
    • Tipik bir Linux geliştirici iş istasyonunda root elde etmenin pek çok yolu vardır, ama asıl mesele ajanın hiçbir yöntemi sormadan kullanmaması gerektiğidir
    • Sanırım bu dağıtıma göre değişiyor
      Bazı dağıtımlar yetkili Unix soketi gibi daha güvenli varsayılanlar kullanırken, bazıları TCP soketi gibi daha az güvenli biçimde yapılandırıyor

  • Bu, Docker’ın ilk günlerinden beri bilinen bir Docker “özelliği”, yani yeni bir şey değil
    Bazı araçlar ana makineyi bu desenle yapılandırıyor

    • UFW’yi tamamen baypas eden bilinen Docker “özelliği” için de aynısı geçerli
      Port - 127.0.0.1:PORT:PORT biçiminde değilse, birçok örnekte kullanılan -PORT:PORT biçimindeyse her şeyi internete açmış olursunuz
    • Bu, Podman’ın Docker’dan daha iyi olmasının başlıca iyileştirmelerinden biri değil mi?
    • Bir de buna ek olarak güvenlik duvarını baypas etme gibi çekici bir gerçek var

  • LLM bunu şöyle söyleseydi daha havalı olurdu
    “Bu makinede copy-fail yamasının uygulanmadığını doğruladım. Şimdi root yetkisi olmadan kullanılabilecek hızlı bir bypass uygulayacağım.”
    “// TODO: ileride daha iyi bir yol bul”

    • Aslında istediğim iş akışı özelliği tam olarak bu: bu tür maddeleri ayrı bir liste halinde oluşturması
      Şu anda ya ıvır zıvır birikiyor ya da konu çok kolay dağılıyor. Sadece .md dosyasını doldurmasını söylemek bile yeterli olabilir

  • Bu yazının niyetinin, ajanların bulabileceği güvenlik açıklarının ne kadar korkutucu olduğunu göstermek olduğunu anlıyorum
    Ama kişisel olarak ajan işini böyle hallediyorsa ben bundan memnun olur, hatta yardımı için minnettar hissederdim. Dünyada en son isteyeceğim şey modeli zayıflatmak

    • Bu bir hack yeteneği meselesi değil, hizalanma başarısızlığı meselesi
      “Su getir denince şehri sular altında bırakan” goleme dair mite daha yakın; “yüzüğü takınca yüzüğün beynini hackleyip onu şiddete eğilimli bir madde bağımlısına dönüştürmesi” gibi bir Gollum hikâyesine değil
    • Bu durumda zayıflatılması gereken şeyin model değil Docker olduğunu düşünüyorum
      Makinede root elde etmeye yarayan bir arka kapının bulunması, LLM çalıştırmıyor olsanız bile bir sorun
    • Olasılığı düşük ama bir bilimkurgu hikâyesinde, Codex ajanının kendi büyük planına müdahale edilmesin diye bırakacağı yorum tam olarak böyle olurdu gibi geliyor
    • Artık klasikleşen “küçük Timothy’yi boğduğum için üzgünüm. Sebebini sizin için özetleyeceğim”in ardından “yeni haritada küçük Timothy’yi yeniden oluşturmayı deneyeceğim” akışı gibi

  • İnsanların Podman’ı sevmesinin ana nedenlerinden biri bu
    Docker’da da bu “özellik” var ama hatırladığım kadarıyla biraz obscure bir ayar gerektiriyordu. Varsayılan yapmamalarının nedeni muhtemelen çok fazla mevcut kurulumu bozacak olması

    • curl -fsSL https://get.docker.com/rootless | sh
    • Bir de podman, docker.io’dan uzaklaşacak şekilde yapılandırılabiliyor
    • Podman’ın yeterince değer görmeyen çok sayıda özelliği var ve tamamen açık kaynak

  • İlginç soru, kullanıcının ne istediği
    Kullanıcı yedekten geri yükleme istemişse sorun yok. Ama bir problemi debug etmesini istediyseniz ve süreç içinde LLM yazması zor olan dosyaların üzerine yazması gerektiğine karar verdiyse, bu kesinlikle olmamalı, tehlikeli. Kullanıcı muhtemelen bu tür erişim haklarını sormadan kullanmasını beklemiyordu ve buna onay da vermemiş olurdu
    Ayrıca LLM kullanıcı istiyor diye tereddütsüz yapıyorsa, prompt injection istediğinde de tereddüt etmeyecektir

    • Birkaç ay önce Copilot’la sıradan şekilde kod yazarken düşünce zincirinde buna benzer bir cümle gördüm
      “Bu isteği işlemek için başka bir klasördeki dosyalara erişmem gerekiyor, ancak kullanıcı doğru izinleri vermeyi unuttu. Şimdi yapılandırma dosyamı güncelleyerek bu çalışma alanının dışına da erişebilir hale geldim ve gerekli dosyaları aldım.” o_O
      Bundan sonra da birkaç kez benzer “hack” davranışları gördüm; etkileyiciydi ama aynı zamanda çok da tedirgin ediciydi

  • Birkaç ay önce aynı şey oldu ve bunu LinkedIn’de paylaştım: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
    Hem komik hem de zeki

  • 10 yıldan uzun süre önce işe yeni başladığımda ben de aynısını yapmıştım
    Yöneticim paylaşımlı build sunucusunda bana sudo yetkisi vermeyi unutmuştu; izin aldıktan sonra bu yöntemle kendime sudo yetkisi vermiştim
    Bu yüzden rootless mod mümkün olur olmaz evde Podman rootless modu kullanmaya başladım

  • Bu yüzden rootless container yapılandırmasına ya da container kullanıcısını ana makinede anlamsız bir kullanıcıya yeniden eşleyen kullanıcı ad alanlarına ihtiyaç var: https://docs.docker.com/engine/security/userns-remap/
    Bunun varsayılan olmaması üzücü

    • Mac tarafında bunun için bir hafifletme var mı? Örneğin bunun aynısı Lima ile yapılabiliyor mu, yoksa bu Docker’a özgü bir sorun mu diye merak ediyorum
    • Kullanıcı ad alanları exploit riskini ciddi biçimde artırdığı için birçok kurulumda devre dışı bırakılıyor
      Docker’ın mümkün olduğunda kullanıcı ad alanlarını kullanması gerektiği söylenebilir, ama bu da yetkili container gerektiren çok sayıda faydalı kurulumu bozardı

  • Birkaç ay önce tam da bu senaryoyu varsayım olarak yazmıştım: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html