On Wed, 2009-01-21 at 15:59 -0800, Kam Leo wrote: > On Wed, Jan 21, 2009 at 2:25 PM, Craig White <craigwhite@xxxxxxxxxxx> wrote: > > On Wed, 2009-01-21 at 13:42 -0800, Kam Leo wrote: > >> On Wed, Jan 21, 2009 at 12:47 PM, Patrick O'Callaghan > >> <pocallaghan@xxxxxxxxx> wrote: > >> > On Thu, Jan 22, 2009 at 2:12 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > >> >> Richard Hughes wrote: > >> >>> Sure, but my point if that GTK code is untrusted, and just not designed > >> >>> to be run with elevated privileges. A buffer-overflow is an easy exploit > >> >>> if the code is running as uid 0, whether running as setuid or as root. > >> >> > >> >> Why would you overflow a buffer on your own machine where you're already > >> >> root? It makes sense to attack a setuid binary on a machine you're not root > >> >> on, but it doesn't make sense to attack your own machine. > >> > > >> > Really? In that case I invite you to visit my website evil.com and > >> > click on a few links. Better still, log into my friendly server and > >> > run a few of my apps. They're running on my machine, not yours. Of > >> > course the GUI runs on your machine via X11 ... > >> > > >> > poc > >> > >> A GUI is not required to compromise a machine. No need to go after the > >> root user either. Take a gander here: > >> http://www.linuxsecurity.com/content/blogcategory/89/102/7/0/ > > ---- > > well now...there's a cogent argument. > > > > Suggesting that even though few of the applications that run on X are > > audited for security when run as superuser, that it becomes acceptable > > to do so because other exploits exist that don't require X to propagate. > > > > Interesting logical expansion > > > > Craig > > The fallacy is believing you automatically obtain security by auditing > applications running on X for execution by the superuser or preventing > root from logging into X. No, the fallacy is believing that security is either on or off, when in fact there's *always* a tradeoff between effective security and user-friendliness. Running a GUI as root greatly expands the number of potential exploits, that's all. poc -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
