Re: GRUB2 Build on Mac OS X

[Peter Jones]

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