B
Bear
http://research.microsoft.com/en-us/um/people/blampson/69-
SecurityRealIEEE/69-SecurityRealIEEEpub.pdf
http://goo.gl/54dNU+
Excerpts:
"The result should not be surprising. We don’t have “real” security that
guarantees to stop bad things from happening, and the main reason is
that
people don’t buy it.
A secondary reason we don’t have “real” security is that systems are
complicated, therefore both the code and the setup have bugs that an
attacker can exploit, such as buffer overruns or other ?aws that break
the basic programming abstractions.
Broadly speaking, there are five defensive strategies:
• Isolate—keep everybody out. This coarsegrained strategy provides the
best security, but it keeps users from sharing information or services.
This is impractical for all but a few applications.
• Exclude—keep the bad guys out. This mediumgrained strategy makes it
all right for programs inside this defense to be gullible. Code signing
and ?rewalls do this.
• Restrict—let the bad guys in, but keep them from doing damage. This ?
ne-grained strategy, also known as sandboxing, can be implemented
traditionally with an operating system process or with a more modern
approach that uses a Java virtual machine. Sandboxing typically involves
access control on resources to define the holes in the sandbox. Programs
accessible from the sandbox must be paranoid, and it’s hard to get this
right.
• Recover—undo the damage. This strategy, exemplified by backup systems
and restore points, doesn’t help with secrecy, but it does help with
integrity and availability.
• Punish—catch the bad guys and prosecute them. Auditing and police do
this."
There is a lot more in the article.
--
Bear
http://bearware.info
The real Bear's header path is:
news.sunsite.dk!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-
mail
SecurityRealIEEE/69-SecurityRealIEEEpub.pdf
http://goo.gl/54dNU+
Excerpts:
"The result should not be surprising. We don’t have “real” security that
guarantees to stop bad things from happening, and the main reason is
that
people don’t buy it.
A secondary reason we don’t have “real” security is that systems are
complicated, therefore both the code and the setup have bugs that an
attacker can exploit, such as buffer overruns or other ?aws that break
the basic programming abstractions.
Broadly speaking, there are five defensive strategies:
• Isolate—keep everybody out. This coarsegrained strategy provides the
best security, but it keeps users from sharing information or services.
This is impractical for all but a few applications.
• Exclude—keep the bad guys out. This mediumgrained strategy makes it
all right for programs inside this defense to be gullible. Code signing
and ?rewalls do this.
• Restrict—let the bad guys in, but keep them from doing damage. This ?
ne-grained strategy, also known as sandboxing, can be implemented
traditionally with an operating system process or with a more modern
approach that uses a Java virtual machine. Sandboxing typically involves
access control on resources to define the holes in the sandbox. Programs
accessible from the sandbox must be paranoid, and it’s hard to get this
right.
• Recover—undo the damage. This strategy, exemplified by backup systems
and restore points, doesn’t help with secrecy, but it does help with
integrity and availability.
• Punish—catch the bad guys and prosecute them. Auditing and police do
this."
There is a lot more in the article.
--
Bear
http://bearware.info
The real Bear's header path is:
news.sunsite.dk!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-