if only things were so easy...
the first mistake seems to be blaming the operating system... they make a good argument for it but it ignores the decades old result that all general purpose computers are susceptible to virus infection... it's not the operating system that decides whether a computer is a general purpose computer or not, that's only part of it - the hardware plays a part too... take bootsector infectors, for example: they're operating system agnostic, they run straight off the bios (or even lower level hardware interfaces) without intervention from any operating system... clearly, making changes to the operating system alone will not stop a computer from being infectable...
let's humour them for a moment though... the premise of the idea seems to involve preventing applications from being able to access that which they have no need to access - one of the examples they use is that Solitaire should not be able to search your desktop to perform it's intended function... they hope to apply the principle of least priviledges (or principle of least authority, depending on who's talking - it's basically the same thing) to individual programs, which is a novel departure from normal operating system security that normally only defines priviledges for principals (users, local machine account, etc)...
let's consider this carefully - there are thousands, possibly hundreds of thousands of programs on today's computers (most of which the user isn't even aware of), how are we to define what priviledges each and every one of those programs is supposed to have? there are 4 options:
- the computer could figure it out by itself by examining the programs
- the user could define them all at the outset
- the user could answer yes/no to a variety of pop-up questions as new applications are run and the system needs to know what kinds of priviledges the new applications should have
- some authority (like HP perhaps?) could define the proper priviledges for all applications everywhere in a central database that and that information would then need to be communicated to systems that need it
(1) is not really an option... it runs afoul of a little thing called the halting problem (if we could solve the halting problem we could have perfect virus scanners and this blog probably wouldn't exist)... not only is it not generally possible for a program to determine what another program does by looking at the code, it would require that we examine the program in it's uninfected state first and that's not generally an option when we download infected materials...
if you think (2) seems like it would be an unreasonable burden on users you wouldn't be alone... in fact both (2) and (3) ask the user to decide what programs should be allowed to do and the user is almost certain to make mistakes - the more the user has to decide, the more mistakes are likely to be made, and those mistakes can lead to lost functionality ('i didn't know the program needed to do that'), more priviledges (and therefore more opportunity to spread infections) than necessary, or both... there could be thousands of decisions to make and users are just not likely to do that at the outset... the pop-up questions (now familiar from such things as software firewalls) require less from the user at any one given moment, but that doesn't address the problem of knowing the right answer to the popped up question... it's a problem in software firewalls too, but at least in software firewalls all you need to do is figure out if the application is supposed to use the network - this system would require much more indepth knowledge of each application...
and that leaves (4)... maybe a central authority could define the appropriate priviledges for all known software in existence, but i doubt it... and even if they could produce entries for all known software, such a huge database would invariably have the problem that all large databases have - incorrect data... not to mention that this would boil down to a central software registry such that people would only use the software found in the authority's database (for security reasons of course) which winds up being no different than the proposed system where people only use software that's been digitally signed and certified by a similar central authority...
and besides all that, your application priviledge system would then need a reliable, unspoofable means of identifying the program (filenames aren't enough, i can change filenames to whatever i like) - and not just the current version of the program but all versions of the program, for all programs... and it would have to recognize that some versions of a program would need different priviledges than other versions of the same program (due to differences in feature sets)...
i'm certain the folks at HP are not the first to think of defining priviledges on a per program, rather than per user basis... why weren't operating systems designed that way? it seems to me that the answer is obvious, because it's an unworkable system...
the above mentioned article states rather plainly that they want all the security without losing any of the features of existing software - but the features create complexity and, to quote bruce schneier, "complexity is the worst enemy of security"...
ultimately, reduced priviledges doesn't actually stop virus infection - what happens when a program that requires a great deal of priviledges becomes infected? it spreads the virus far and wide... reduced priviledges can't do any more on a per program basis than it can on a per user basis to stop viruses - that is, all it can really do is make the path of infection more convoluted until it gets to someone/something with lots of priviledges - in other words, all it can do is slow the viruses down...
the way i see it, that article is either a very poor representation of what the researchers at HP are really working on, or the researchers at HP have 'jumped the shark'...
0 comments:
Post a Comment