Bernardo Innocenti wrote: > John Richard Moser wrote: > >> VECTOR 1: kexec() >> [...] >> VECTOR 2: unsigned module >> [...] > > Unless we disable things such as /dev/mem, I also see a much > wider attack vector, where one can inject arbitrary code in > the kernel and recreate the conditions of these. And there > are many alternative strategies based on commonly available > interfaces. >
Thank you for seeing that one. grsecurity has code to resist this type of attack (allows writing to /dev/mem in video memory range, but nowhere else); I don't know how else to do it. > Some people seem to believe that one can give root access to > a system and at the same time keep it locked down. While this > seems possible in theory, I'm still waiting to see a practical > implementation that resists Random J. Hacker while preserving > the user's and application's expectations of what root can > normally do. > I did not address the mass of other crap you could do to the system with root. I was only addressing evading the OFW security implementation for only booting signed OSes. -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
