I think the application is clearly at fault here. The boot loader doesn't have to make any assumptions about the disk (not even the presence of files or a filesystem), it sets up the info passed on to the operating system and both the operating system and any applications within that OS should stay outside of areas that were not explicitly allowed. The OS should never allow an application to do this.
The application shouldn't be doing what it's doing, but it still is kind of hypocritical to complain that someone else is doing exactly what grub is doing. There is no reason grub couldn't make a little partition for its data (except for inconvenience). It wouldn't even have to know how to parse a partition to get to its data, it would just be there to mark the area on the disk as its own.
We've solved the problem of data contention on a disk a long time ago...
Why does that give it a free pass to write to places on the disk that are "reserved" or unallocated?
Grub may not operating within an OS sandbox, but it is required to play nicely with the OSes it is booting. The way to do that is to wrap your data in a partition or a file.
Well, you're right that grub-the-bootloader doesn't have a supervisor to stop it from writing to random places on the disk (since it's not running under an OS), but grub-the-bootloader doesn't actually write to those sectors, so I'm not sure what your point is.
grub-the-comman-line-utility writes to those sectors but it runs in linux userspace so it's really in the same position as the windows programs that also write to the reserved space...
No OS can block users with administrative privileges from completely destroying their environments.
That said, no application without a very high level of trust (perhaps above what an Administrator can do on Windows) should be able to write outside the filesystem. This should, at the very least, pop-up some "Program X is about to do something remarkably stupid. Allow or deny?" dialog.
Be surprised then. This thing happened to me (on windows 7). I'm very wary about what kind of dialog i click on to, and never saw a warning which would seem related to that.
Right, but how do you do disk imaging (for example) if the OS doesn't give you access to the entire drive? The OS could say "OK, you can modify any drive's boot area but the one I'm on", but that doesn't help if you're booting from another drive and using chainloading.
Hell, you can flash motherboards from an OS... writing to the boot area is just one example of many 'giant holes in your security'.
