> > Marc Aurele La France: Contrary to what too many security pundits think, > > limiting root's power doesn't solve anything. Like bugs, security issues > > will forever be uncovered, whether they be in setuid applications like an X > > server or in a kernel itself. The trick, it seems, is to understand where > > to > > properly fix them, instead of sowing workarounds all over the place... > > > > ( http://marc.theaimsgroup.com/?t=114735843400006&r=1&w=2 ) > > I think that's been agreed to many times by the OpenBSD developers: you can't > effectively limit root's ability to do "bad things", and pretending you did > is just fooling the good guys and making the bad guys giggle.
Wrong. You can limit roots ability to do some bad things. We try to do that. Even root cannot open /dev/*mem for write. We are trying to be protective, but the requirements of X stops us from doing so. > This isn't about root. Or at least, it shouldn't be. Except it is, because > of how much of the X code is doing root-like things. X is not doing root-like things. X is talking to IO devices. Root does not talk to IO devices. Root only talks to the kernel. If you are going to ran on a topic like this, you HAVE TO KNOW WHAT YOU ARE TALKING ABOUT. Nick, you don't know what you are talking about. But Ed, you interviewed someone in detail about the issue, and you still managed to get it wrong and you still don't understand it. Get a grip, please. In the Unix system view, anything which needs to talk to raw devices INSTEAD OF THE KERNEL DOING SO is broken. There are no apologies to be made. Period. If you want X to talk to IO devices, what next? ls?
