Slashdot Mirror


IEEE to Standardize OS Security Components

aster_ken writes "The Institute of Electrical and Electronic Engineers has started work on a standard for securing operating systems, as a recognition that software security is 'limited by the operating systems that underpin them', the organization said yesterday. The standard, dubbed IEEE P2200, will address external threats and intrinsic flaws arising from software design and engineering practices."

21 of 197 comments (clear)

  1. Limited release by Anonymous Coward · · Score: 5, Insightful

    That's just great, codify the security aspects of OSes into a $100 document that can't be freely redistributed. That's a really good idea...

  2. Here here! by kevin_conaway · · Score: 2, Insightful

    Awesome. Operating System design is one of the most underdeveloped fields of the industry and I believe that this is a step in the right direction towards the development of a mature, secure operating system for general use!

    1. Re:Here here! by bryanthompson · · Score: 4, Insightful

      don't get too excited there, guy. just becuase someone puts out a 'standard' doesn't mean everyone has to follow it. anyone can form an organization to make standards, but they dont' mean anything if nobody wants to follow them.

      Not only that, but people like microsoft will just make their own standards and ignore the ones already set. They won't have any affect on anything, imho.

    2. Re:Here here! by miu · · Score: 2, Insightful
      anyone can form an organization to make standards , but they dont' mean anything if nobody wants to follow them.

      IEEE has a fair amount of credibility with the U.S. government - this standard could easily become a purchase requirement like POSIX.

      microsoft will just make their own standards and ignore the ones already set.

      MS will support this standard if it is a purchase requirement. I think it is more likely that MS will have an inconvenient BOSS mode, they will then be able to point to users failure to use that mode as the reason for security failures In the same manner MS has supported POSIX for a long time, they just kind of sneer at it and suggest you write native apps instead.

      --

      [Set Cain on fire and steal his lute.]
  3. If only Windows would use them and not brake them by isolation · · Score: 1, Insightful

    Such as how they did kerbose to be incompatble with Unix implementation. What good is a security standard if that implementation is going to be "extended" by the biggest player?

    --
    Free Unix? Free Windows. http://www.reactos.com
  4. So, did anyone else... by pla · · Score: 5, Insightful

    So, did anyone else read the linked article and think "Looks like someone bought the IEEE's support of TCPA / Palladium"?

    I hope not, but it certainly sounds that way. Basically, it makes the point that we cannot trust people not to run programs that break their own (or others) computers, so the task of limiting what (possibly malicious) code can run falls to the OS.

    Sad. If I didn't have complete confidence that any DRM scheme will eventually prove itself flawed, I might actually worry. Though, I certainly do not look forward to the general inconvenience it would cause, regardless...


    Only education (and not running Outlook) will help reduce the modern plague of worms, virii, spam, and other ways to generally make a computer and the internet grind to a crawl. Not legislation, and not crippled hardware. People simple need to learn how to secure their own damn machines.

    1. Re:So, did anyone else... by esme · · Score: 4, Insightful
      Basically, it makes the point that we cannot trust people not to run programs that break their own (or others) computers, so the task of limiting what (possibly malicious) code can run falls to the OS.

      you know, this basic premise doesn't have to be tied up in DRM. i think any decent security model is going to involve partitioning off system capabilities that aren't appropriate to the current user/situation/time of day/etc.

      unix has had this sort of thing for ages, in the form of user permissions, and ulimit. ulimit supports various parameters -- files, memory, cpu, etc. that can be consumed. taking this to its logical conclusion and including bandwidth, address book access, connections to various servers, etc. could provide a pretty logical way to fence in worms.

      providing even more restricted environments (like chroot jails or the applet runner) for untrusted code would be a good idea, too. if microsoft is going to insist on allowing people to email executables (screen savers, vbscript, etc.), the world will be better off if they execute in an environment that can't access the network, DoS the local machine, etc.

      -esme

    2. Re:So, did anyone else... by pla · · Score: 2, Insightful

      providing even more restricted environments (like chroot jails or the applet runner) for untrusted code would be a good idea, too.

      What you write makes a lot of sense, and leaves me at least a bit of hope of a "good" implementation. Even within your ideas, though, I can see room for a few unacceptible restrictions...

      For example, who defines "untrusted code"? Perhaps most people don't care about issues like that, but I personally think nothing of popping out 15 minutes of code to automate a task that would have only taken me 20 minutes to do manually. Would that count as untrusted, requiring my code to have access to only the most trivial of resources, such as limited CPU and memory, no HDD, no network, etc?

      So from that angle, perhaps you can better understand my concern with the threat of a "secure" base OS... While it will save the majority of computer users a lot of grief, those of us who can secure our machines, and need low-level access to hardware, will suffer greatly (basically, to the point of reducing us to no more capable than that same majority of computer users).

  5. This could be good by Bruha · · Score: 4, Insightful

    I think it's time for all OS's to accept standards to help people interact with eachother effectively and securely. As everyone know MicroSoft has shunned many attempts at standards in order to control their market share by keeping their users pinned into MicroSoft sanctioned data. This has the effect of forcing businesses to support the MicroSoft users first and everyone second if at all.

    I think a security standard should be enforced by a world body to help prevent MicroSoft from once again taking the standard and corrupting it to work only with Windows and .Net applications thus forcing the same cycle of users/companies designing to MS standards again thus shutting out the rest of us from secure systems.

    Some would say standards hurt computing that's not exactly the case. You can design products around standards and still compete with other standard compliant products. It allows everyone to remain compatible and at the same time darwinism will take effect with bad products going away and good products evolving to better suit their users.

  6. Re:great... by GoofyBoy · · Score: 4, Insightful

    >Security is still too volatile.

    Better put: Security is in the details.

    If I'm going to crash a system then its going to be its specific weakness/flaw and not some standard hole in every product.

    The standard will help but it still does not guarentee the implementation will be invulnerable.

    --
    The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
  7. it's good by focitrixilous+P · · Score: 2, Insightful

    Not really condeming of anyone in particluar, but I doubt the big player of the PC world will take orders from anyone. They didn't for any of their software, why would they take standards for the core OS of everything? Microsoft seems to be it's own standard, which is too bad.

    --
    SAILING MISHAP
  8. Re:Quit whining - not everything has to be free by pyrrhonist · · Score: 2, Insightful
    Learn to recognize which items are worth the amount on the price tag, and purchase accordingly.

    You got that right, everything the IETF ever turned out is a load of crap.
    I'm glad I spent all that money to get the ISO's OSIRM protocol documents. That's where it's at.

    --
    Show me on the doll where his noodly appendage touched you.
  9. Why the IEEE? by Anonymous Coward · · Score: 2, Insightful

    This is a software, not hardware issue. The ACM would be a more appropriate oversight group for this.

  10. Americans and standards by Tim+Ward · · Score: 4, Insightful

    Um, yes, perhaps.

    Remember the reaction of the average American to an international standard is to denounce it as a communist plot, particularly if one of the European standards bodies takes an interest (or even ISO, which most Americans regard as European and therefore communist).

    If you want an example of how well Americans make good use of international standards you just have to look at their mobile phone system ... and laugh or weep to taste. (I have this phone which works in 199 countries of the world and doesn't work in one, which is ... guess which? Likewise there's just one county in the world which uses strange paper sizes ... just one country which is so wedded to Imperial units that it crashes spacecraft in preference to following international standards ... and so on and so on ...)

    Now, if most operating system manufacturers were European and Japanese this would be a good idea, because they'd be likely to follow any new international standard. But it happens to be a fact of life that many operating systems are produced or contributed to by Americans, so any such idea is dead in the water before it gets off the ground.

    1. Re:Americans and standards by bluGill · · Score: 2, Insightful

      Where did you get the idea that american phones don't work anymore. My Phone is a tri-band GSM only phone that works just fine in the US, despite the "fact" that you appearently made up about no US cellphone working anywhere else in the world.

      GSM is a bad standard on most technical counts. The CDMA standard that is popular in the US is better, but it isn't GSM. For most people though, that is irrelavent. You choose a phone by many factor, GSM or CDMA is not, and should not be one for most people. Engineers designing the local cell phone system care about those details. You care about cost (which is intentionally confusing with different roaming areas, long distance rates, per minute rates, and so one which varies slightly from country to country), phone features, and where you can use the phone. (The last is the only place where standard comes into play but only indirectly)

      People in Europe tend to have a very disorted view of how the cell phone market in the US works. It is different on many levels. Some ways are better, some are worse. That most of us use CDMA is better, except for that compatability detail. That we pay per minute for incoming calls is different, and has just as many advantages as disadvantages. It is different, but the truth is, cell phones work just fine for people in the US.

  11. No operating system will ever be completely secure by rborek · · Score: 3, Insightful

    As long as there are people creating software, there will always be security bugs in the operating system. You just can't go over millions of lines of code and spot every bug that can result in a security breach - especially if two portions of code combined are the reason for the breach (those two pieces of code can be hundreds of thousands of lines of code apart). I predict that they'll certify an operating system secure... and then the next day a security alert will be announced for it. Microsoft has come a long way from their old operating systems - Windows Server 2003 is much more secure, but no operating system will ever be 100% secure as long as there are hackers out there to test every possible vulnerability... and the fact that there are administrators out there that may not secure the OS down and make stupid configuration errors.

  12. Re:redundancy by Anonymous Coward · · Score: 2, Insightful

    I doubt very many Open community members have the skill to add an ARM to their PCI network card or motherboard. Not that I'm saying it can't be done. It's just that I think your idea is taking a wrong and very difficult approach at a level that's way too close to the hardware. I'm surprised you didn't say to put a virus checker right on hard drive controllers.

    These solutions are more usefully implemented in software.

  13. Re:No operating system will ever be completely sec by Wesley+Felter · · Score: 3, Insightful

    You just can't go over millions of lines of code and spot every bug that can result in a security breach

    That's why really secure OSes don't have millions of lines of security-critical code.

  14. IEEE isn't your average organization by Erioll · · Score: 2, Insightful

    IEEE is responsible for a LARGE number of the computer-related standards out there. They are not just "someone" that puts out a standard. IEEE is probably the largest organization of computer and electronic-related people anywhere.

    Of course anybody can ignore a standard, but if the largest organization in the world in this industry goes one way, do you really want to go the other way?

    Erioll

  15. Re:great... by Anonymous Coward · · Score: 1, Insightful

    It is possible to standardize methodologies or best practices in a field, though, and train people to be aware of and follow those practices. For instance, one can certify civil engineers without limiting building to only standard bridges or skyscrapers

  16. Imperfect trust and contingency costs by Skapare · · Score: 2, Insightful

    You have to trust something. That which is trusted has to operate in a way that if it were made to do the wrong things, it would do the wrong things. Trust is the belief that it is not going to the wrong things. That which is not trusted has to be operated in a way that restricts its ability to do wrong things. But you cannot operate everything in the restrictive way because you have to trust the very mechanisms of restriction itself. And that generally means the kernel of the operating system, and the most of the hardware, have to be trusted to do the right things.

    But the biggest issue is how do you establish that trust? Are you going to personally inspect every line of source code, and understand what it does? Are you going to inspect the engineering of the CPU and associated hardware that can influence how the CPU operates? Because we generally cannot do this on things as complex as computers or software, we have to establish trust by some proxy. If we know someone, and trust them, who has done all that, then we might trust the system. But there really isn't likely to be very many people around who can do that, and perhaps none at all. So somehow we have aggregate that trust proxy, and conclude on the basis of some combination of information, that something is trustable. But this isn't genuine trust. We cannot be certain that something is truly trustworthy just because someone says it is, or that a combination of others say it is.

    Ultimately, we have to accept, and learn to deal with, the fact that trust is imperfect. We have to trust not that something cannot do the wrong thing, but that it is highly unlikely to do the wrong thing, and have contingency plans to be able to deal with it doing the wrong thing, which includes knowing that it did the wrong thing (it might try to hide that fact from you). The level we have to use to establish that trust will thus depend on the real and potential costs of the contingency (such as cleaning up the mess it leaves behind, restoring data, etc).

    In order to reduce your contingency costs, you have to establish a greater criteria of trust. But the trust has a cost as well (for example hiring several computer scientists to inspect and analyze the code, as well as performing background checks on them to make sure they have no other motives, and even this has costs). It's all a balancing act. And where the optimal balance is will depend on many factors. As your contingency costs increase (a military has very high contingency costs, as it could mean losing to an opponent), your level of trust establishment needs to increase as well.

    A standard for security has to address the fact that trust is imperfect, and that different entities will have different contingency costs. So it has to be flexible over a wide range of optimal levels of trust. If it is too rigid, it cannot be universally adopted, and will end up not being in common use (though it might find a niche use in areas matching its trust metrics). Those who are developing such a standard will at the very least need to state up front what the goal is. Is this something they expect to be usable in both a military high command setting, and in a casual home user setting? Unfortunately, I see none of this in the base document at the BOSS working group site.

    --
    now we need to go OSS in diesel cars