Ако нормален потребител на server може да прави sudo root не мисля, че има нужда от каквито и да са exploits :)
Това, което аз питам е, ако стартираме програмата top с user pencho и top-а е с pid 1292, други програми на user pencho имат ли легитимна причина да четат от /proc/1292/mem, /proc/1292/maps и /proc/1292/smaps. Целта на въпросната промяна е да не може да се стигне до ниво bios/boot/kernel module. Повече за начинът, по който да се постигне това ниво на сигурност: https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time Мариян On 11/01/2016 02:45 PM, Computer Burgas wrote:
1-во има много неща , които се изпълняват от sudo root. 2-ро всяка програма е легитимен потребител на част от паметта. 3-то потребителят в случаят е без значение. хората работят на ниво първоначално зареждане и биос. при такова компрометиране, всичко което правиш ти в последствие е без значение. 2016-10-27 0:05 GMT+03:00 Marian Marinov <m...@yuhu.biz <mailto:m...@yuhu.biz>>: Здравейте група, покрай Dirty CoW exploit-а с мои колеги и приятели започнахме да обсъждаме attack vectors на различни exploits. Реално много голяма част от exploits използват информацията от /proc/self/mem, /proc/self/maps и /proc/self/smaps за да могат да направят успешен exploit. Ние обсъдихме легитимните user-и(програми) на тези файлове и не виждаме някаква основателна причина normal user на машината да има права дори да ги вижда тези файлове. Моето генерално предложение е да си напишем patch, който да прави така, че root user или user с CAP_DAC_OVERRIDE и/или CAP_SYS_ADMIN, да може да вижда тези файлове, а за всички останали те да са невидими. Прост patch, който да ги прави 000 не върши работа, защото логиката на /proc fs-а не е задължитено да следва linux security модела. Вие какво мислите? Кои са легитимните потребители на mem, maps & smaps? Какво мислите за подходът ми с kernel patch-a? maps се използва много от lsof. Мариян _______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org <mailto:Lug-bg@linux-bulgaria.org> http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg> _______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
_______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg