On Thu, 2005-12-08 at 19:25 +0100, Yoshinori K. Okuji wrote: > > There's a major point of contention being ignored here. OS vendors > > don't want to ship executables which require an executable stack. Full > > stop. > > I'd like to hear your opinion as a distributor about the trend of prohibiting > executable stacks. For me, it sounds just like a paranoid. I can understand > it when a program takes input from a different user. However, in the context > of GRUB, what is the benefit? I haven't heard any good reason behind it so > far.
It used to be that everybody assumed all their programs were well behaved, and that we could simply fix bugs when we found them, and that's good enough. That's the approach you're taking here, although it is somewhat implicit. What you're saying is that grub isn't setuid, so if there are bugs in it which would be exploitable in a setuid program, we don't need to worry. Everybody used to take that approach. As a vendor, we've done a lot of work on security in the kernel, the compilers, libc, and elsewhere, and the conclusion we've come to is that in several ways this approach is outright wrong. What happens is that some program which is setuid calls your program, and it inadvertently passes some used specified data along that it shouldn't, or accidentally picks up some data from a side channel that the user has access to. Then, some sysadmin has a really bad day, because his boxes get rooted. Now, obviously, we can't plan on getting rid of all bugs before anybody notices them, though we'll remain diligent and trying to do so. But what we *can* do, which is actually significantly more effective, is to identify classes of bugs that can be transformed from being showstoppers to being relatively innocuous -- not necessarily that they can't cause harm, but that it's very difficult for somebody to plan on what that harm would be. You no doubt get where I'm going with this. The vast majority of exploits these days are buffer overruns. It's hard to find all of the problem code, and it'll probably never happen (though we've added some tools to gcc to identify some). But making it so that if somebody finds a buffer that's not checked properly, they can't *do* anything with it is now *easy*. Since widespread hardware support for non-executable pages has started to occur, we've started fixing any programs we ship that have executable stacks. And the result is pretty massive. On machines with the capability to enforce it, RHEL has been vulnerable to an overwhelmingly smaller number of attacks. We're sure there are more lurking that are very hard to find, because the programs that directly accept input aren't necessarily the vulnerable ones. Now, the obvious retort to this is that no setuid programs are calling grub, so it's not even one of those cases. That's not a good answer either. I've got one I'd really *like* to call grub from, and it is pm-hibernate, through consolehelper, and they both accept some degree of user input from whoever's logged in on the console. I'd really like to make it so that if somebody has 2 kernels installed, boots the non-default one, hibernates their laptop, and unsuspends without paying attention, it doesn't die a horrible death. The most obvious way to do that is to make pm-hibernate set the next-boot device to the currently running one. >From our point of view, if grub has an executable stack, we can't do that, because we'd be introducing the type of scenario which we already know has an extremely large number of unpredictable security implications. Sorry about replying with a small novel. -- Peter _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel