Not necessarily wrong. If they have N times as many lines of code to audit, they need to spend an absolute minimum of N times as much just to stay on level pegging. Spending N/2 times as much is still more, but it isn't usefully more.
Then there's program arcs. You can't just validate each line of code, you have to validate each arc as well. Windows 7 probably has many, many more program arcs than say, oh, Photoshop. At least, I hope so. If you test twice as many arcs but your code has a hundred times as many, you're spending more and doing more but getting a fiftieth of the coverage and therefore a fiftieth of the quality control. At best.
I'm not saying Microsoft gets it right, either. I strongly suspect that the efficiency and quality of their testing is pathetic. Thus, dollar for dollar, I don't think they actually test even in absolute numbers as much as their rivals.
Remember, not all testing is of equal worth. If you were to add asserts at the start and end of each arc through the code that specify each and every invariant that must be true at those points, you could eliminate most common bugs with very basic tests. In the case of applications, if you then added a strict debugging dynamic memory library, you should be able to clear out a significant fraction of the buffer overflows. If you then threw a static checker (Klokwork and Coverity make good but hellishly expensive products) at the code, you could clean out a lot of the remaining common flaws.
Not all coding is of equal worth, ether. If coders are held to the CERT standards for coding, you'll get better code than if you hold them to the "would-it-fly-on-tucows" standard. The "extreme programming" method of writing tests first and code around the tests should also help.
However, even Microsoft couldn't afford Coverity's charge per line of code for something the size of Windows. I'm not sure they could afford the charge even for Internet Explorer. Just because the software would be valuable doesn't mean it is practical.
My argument is that you're choosing the most expensive implementation of a specification and then blaming the specification for the price.
There are affordable, practical ways to achieve the same results and that totally eliminates the price side of your complaint (which, apparently, still has this fictional multiplication of servers which I've already demonstrated is not required).
If you want to argue against the idea, fine. But produce a VALID argument, not a bullshit one. I have no respect for bullshit artists.
I've broken RPM and DEP so often I've lost count. They work, but only to a point. Part of the problem is that packages aren't generally maintained very well. In fact, that's most of the problem. Especially when you get name-clashes in the standard directories.
The rest of the problem is the way the data is stored. The package managers don't do much in the way of normalizing, which can seriously mess things up.
One method is to have a tool for interrogating the API version and also testing the API against some set of tests that relate to the application being installed. You'd then apply the following:
If the API version is within bounds, do not install the library
If the API version is outside of bounds but the tests succeed, do not install the library
If the API version is greater than the latest supported and the tests fail and a backwards-compatibility library which IS within bounds of the API provided is within the archive, install the backwards-compatibility library
If the API version is greater than the latest supported and the tests fail and no backwards-compatibility library is usable, install the supplied library locally to the application, using the package manager, using an alias so there's no name-clash with primary libraries
If the API version is less than the minimum supported and the tests fail and the user authorizes an upgrade, use the package manager to upgrade to the supplied library
In all other cases, install the supplied library locally to the application, using the package manager, using an alias so there's no name-clash with primary libraries
Where the library is installed locally, all information regarding the supplied API must be removed since it's vital it doesn't clash with anything else - however, there must be a maintenance tool for cleaning out such local libraries when they are no longer required
This should keep redundancy to a minimum. There will be some, since there's nothing in this to collaborate between apps using this method, but it's a start.
If there is no OS (ie: it's a bare-metal application), there's no user accounts, there's no shells, there's no login daemons (there's no daemons or services of any kind), there's no threads (threads need an OS), it's a pure round-robin (since anything else needs an OS).
Since there's no management (no OS, no threads), all packets are dumb. You have packets going in, getting decrypted and being passed to the internal network. Likewise, packets come in, get encrypted, get pushed out.
Because the maximum size of a packet can have is fixed, and because it's round-robin, you can use a fixed-size round-robin window with fixed-size entries in it. Therefore no dynamic memory problems. In fact you have to, since a lack of OS means no memory management means no dynamic memory.
Ok, so there's no way you can do a buffer overflow attack, no way you can do underruns, no way you can break the stack (cos there isn't one), no way to inject commands (and even if you could find a vulnerability the lack of threading means the box failsafes to no I/O if you inject an instruction).
If there's no OS, you can't have device drivers for things like USB keys or any other pluggable device. If it's a diskless station (ie: everything runs out of flash or eeprom, since there's nowhere else to get the data), other physical attacks - such as adding a drive or inserting a floppy - would do nothing.
(Even if you rebooted the machine, you couldn't do anything - no filesystem. It's a raw image.)
So if you want to tell me that a diskless OS-less proxy -is- possible to compromise, you'd best be able to prove it. None of the above is implementation-dependent, so don't weazel out. Either you're this super-cool expert that can find a way to break the above or you're not. And if you can, you'd best damn-well be able to prove it.
You have yet to prove that the above solution would "balloon costs". (Hell, you've yet to show that adding an RSA card to machines would balloon costs, given the cost of a typical datacenter.)
So I'm giving you the chance to do so. I want you to price up the cost of a complete system - two NIC cards, a chipset with built-in PRNG, 256K RAM (way more than you need, but you might even need to go higher as I'm not sure if you can buy in units that small at a decent price) and maybe 128K Flash (again you may need to buy larger) and a minimalistic motherboard. PC104 would be fine.
(You can skip the cards if the motherboard has two independent NICs built onto it.)
I want you to tell me how much that would set an IT department back, using decent components (not high-grade, just decent).
You're a fool if you think there's no value in an IT department that loses money. It is the NET value to a business that matters, not the local value.
You're also a fool if you think only a tiny fraction "has" to be encrypted - context is everything, as I said. It's how virtually all social engineers operate, it's how virtually all hackers operate. Cripple the context and you cripple them all.
If you've no idea what point I'm trying to argue, you're not much of a security guy. In fact, I'd call you pathetic.
Technology may improve within 2-3 years, but so what? Technology improving won't change whether a buffer overflow is bad, and won't change whether mandatory access controls are good.
Improved technology might help people QA their software, but it won't eliminate the need for QA to be applied.
Improved technology might eliminate the need for passwords, but it won't eliminate the need to ensure that password-protected systems can't be attacked by use of a rainbow table.
Improved technology might help produce superior identity verification, but if you provide an API that bypasses such schemes, such improvements won't be worth a damn.
What do you mean "could"? The Internet Auditing Project revealed a third of Unix systems were insecure, and more recent surveys have revealed Windows boxes getting broken into within minutes of connecting to the Internet.
If the mandated security brought systems up to a minimum standard equal to an NSA-recommended install of Linux or a Trusted OS, circa 2010, with a "sunshine" clause that required the law be revised or automatically expire within, oh, 8 years, the odds are extremely high that we'd have a bullet-proof environment for the duration of those 8 years and a damn-near bullet-proof one for many years after even if the law was never updated and allowed to lapse.
(After all, admins would then be used to configuring systems sensibly and have forgotten how not to.)
They trust encryption combined with a lack of context. I specified that they do not trust encryption WITH context. Do try and read before you bitch.
And, no, hardware encryption has no holes. Neither does encryption via an FPGA. Nor indeed does an IPSec tunnel. Not one of these offers context and all offer encryption as good, or better, than SSL.
Using a DMZ is secure, since the unencrypted network is not publicly visible. It is an isolated network. Having a firewall that only permits traffic to/from the proxy also reduces exposure. A diskless, OS-less proxy is virtually impossible to compromise (there being no logins to hack, no system commands and no privileged services).
Seems to me that your awareness of security is, well, pretty feeble.
HTTPS uses more resources because people use software encryption (which is expensive). If you used hardware acceleration, you'd have no overheads at all at the machine level. You wouldn't need even one extra server. And hardware acceleration doesn't cost the same as 2 beefy servers.
Secondly, you're not limited to HTTPS - most firewalls are quite capable of supporting IPSec in opportunistic mode (ie: keys are generated and exchanged at the time the tunnel is set up). It serves much the same purpose, in that all data going off-site is encrypted.
The use of strong ciphers relies on the ciphers being strong. A cipher can be broken at any time and unless the person breaking it tells you, you do not - and cannot - know they have done so. Relying too heavily on the strength of the cipher alone is not a good approach.
This is why the DoD mandates that users of encrypted telephone systems should keep open context to a minimum and enable the encryption as soon as possible. Chit-chat, however innocent, can help an attacker know what they are to look for and how they should look. I think it safe to say that if the DoD trusted strong ciphers alone to do the job, they wouldn't be so paranoid.
(Indeed, if encryption alone were sufficient, you'd see classified material - albeit encrypted - on unclassified networks. Again, that is verboten. Those with their jobs, egos and indeed purpose on the line do not trust encryption to ever be strong enough on its own.)
Ok, what about all those admins who can't even afford a cheap accelerator card? (And by "cheap", I would include any card that carries an FPGA large enough to hold one of the public, open-source cryptographic hardware implementations and is also fast enough to out-perform a pure software solution.)
Well, is the firewall capable of acting as a secure proxy (ie: providing all the SSL)? If so, what's the problem? There's nothing that requires the web servers themselves to do the SSL in order for the Internet to see SSL.
If not, then can you afford a server that has a beefy processor but minimal memory (diskless is fine) that can act as a secure proxy in a DMZ-type situation? All it needs to do is handle SSL traffic to the outside world and non-SSL traffic back to the web servers. It needn't even run a true OS.
If you can't afford a DMZ and can't afford a cryptographic NIC or crypto engine, then you probably can't afford to maintain what hardware you do have. (A decent hardware RAID array will cost you more than a decent cryptographic system, and woe betide those with no spares, for hardware has a nasty habit of failing.)
That's part of things, but not the whole of things. The CERT stuff eliminates a lot of the bugs that introduce security holes, but it doesn't really cover any of the access controls within the app or between the app and OS, nor does it really cover how to have provably secure software*.
*If you can prove that your dynamic memory library, your I/O libraries and your access control library are correct, and that all dynamic memory and I/O accesses that have the potential to do Bad Things when used without authorization are routed through the access control library, then you have provably secure software. This is NOT the same as having software that can handle provably insecure users, it merely proves that the software cannot behave other than as intended.
You don't need a whole lot of extra code or a whole lot of extra work. For example, if you had a malloc replacement library that was proven correct, you don't need to have one written for every program and you don't need to do a whole lot of cleanup in existing software.
If you also had a drop-in replacement for sockets and file I/O, again using the standard APIs but where the code was proven correct, the same thing applies.
Finally, if all these drop-in replacements made sure they called system functions protected by SELinux, GRSecurity or another security module where applicable, you've got the access controls nailed.
The only things that are needed to be 100% bullet-proof are these libraries and the security module in the kernel. Getting them to 100% is the hard part, which is why "secure" programming languages often don't allow things like dynamic memory at all and severely restrict all other channels.
Obviously, getting the rest as close to 100% correct as possible is a Good Thing, but it is actually very difficult to have provably correct software of any level of complexity. Not impossible, but very very difficult. (There ARE cases where it is impossible, but the proof of this doesn't say what cases, only that there are a non-empty set of them.)
If the security flaws are not spread, then they stop being a "required" part of the system. It is when they are perpetuated that they become unfixable because fixing them will break things.
By having properly-built secure components, you make it so that it is possible to safely replace the buggy components over time. This is the only way that "expected" security flaws ever really get fixed.
So it's not really an "except" at all. What I described is a necessary first step. If both the original component and the new component require the security flaw, fixing the original component will break the new component. If the new component optionally supports the insecure method but also supports the correct, secure method, then fixing the old component doesn't break anything. Better still, it also allows you to eliminate the shim, accelerating performance.
Not starting from a clean slate is immaterial. A new component can be 100% self-contained (and therefore verifiably clean within itself), communicating via some intermediary layer that handles legacy APIs, network connections, pipes, shared memory, et al.
The new component can therefore be as provably secure as you want. Security holes will then be contained (they must be in pre-existing code and cannot spread into new code).
This is not often done in the business world because they're stupid and prefer to burn huge amounts covering their backsides when inevitable breakins occur rather than the relatively small extra needed to properly secure systems in the first place. (It's stupid because such a method can never be cost-efficient in the long-run and only looks very marginally better on the books in the short-term.)
If we start with the fact that the NSA is responsible for the Rainbow Series, partly responsible for Common Criteria, totally responsible for the NSA guidebook on securing Linux, and also totally responsible for the concepts in SELinux (remember, they talk about methods not code), it follows that the NSA is implying that the processes used to develop this public information are rigorous, sound and the methods the NSA use internally for projects they don't talk about. It actually doesn't say that what the NSA publishes is what they use - they only say that methods that are public are what they use. The source is implied.
It depends. The best place to hide something is in plain sight. And the best way to hide encrypted somethings is in a sea of equally encrypted somethings. If the NSA had some algorithm that they felt OK with others knowing and also using themselves, then any traffic of theirs using said algorithm would be indistinguishable from any other traffic. An attacker would need to decrypt everything in order to establish whether or not anything was being sent that was of interest. Even if there was a vulnerability in the encryption that reduced the search space to something theoretically manageable, having to break each and every single conversation on the Internet would push the search space back into the unmanageable region.
ObSidetrackingRant: This is why sites that use SSL should use SSL for everything - it adds noise which conceals the encrypted packets which would actually be of interest. Don't forget that the biggest weakness in secure systems is context. If you have enough context, you can bypass a lot of system security. A simple example would be the "secret question" systems that are popular. If you know enough about a person, the odds are high that you can guess what the answers are. Another example would be social engineering - if you have enough personal information, you could pretend to be that person to a system admin. Social engineering is really the sum total of all the new cracking/viral methods that are being used these days. Far from being new, it's merely better-automated and better-documented. Social engineering was standard back in the BBS days.
Actually, legislation might not be a bad idea. I propose that it be illegal to store passwords in plaintext (or equiv), allow passwords that John the Ripper can break, not QA code correctly, not encrypt traffic, provide identity verification that is bogus, or provide APIs that allow the protection in place to be bypassed. First-time offenders should be forced to read my posts - not because they're necessarily useful on issues of security, but because they're usually long and occasionally tedious. Repeat offenders should pay for the carpal tunnel syndrome surgery I'll eventually need because of all the writing of long and occasionally tedious posts.
They did brilliantly for a while - but at some point they stagnated and abandoned ARM, followed by the Acorn PC (which was never finished).
RiscOS was infinitely superior to any other GUI of the time, but failed to keep pace. For whatever reason, Acorn became too insular.
When they did finally abandon their entire IT division, a breakaway group tried to continue to develop the Acorn PC. I don't know what happened there, but suspect Acorn got stubborn, given the press releases of the time from them.
We don't necessarily need to replace Tomcat, JBoss, etc, we merely need to be able to handle the ABI they expect -and- be able to run them without a virtual machine (ie: compile them to native form).
Ok, correction. We don't need to replace them - yet. If we use an intermediate step or two, where these existing tools are gradually moved onto a different language or replacements are developed, then the migration will be much less painful and much more likely to actually happen.
I like D. Mind you, I like lots of languages.:) Seriously, D would be the "obvious" choice as it would mean the lowest learning curve for developers and the greatest amount of directly translatable code.
Drizzle is a fork of MySQL from before it was Oracle-ified. It is therefore 100% compatible with anything actually in use for MySQL. However, it is lighter-weight and therefore faster. As such, it is ideal for a simple web site with PHP.
PostgreSQL is heaftier and if you need the extra functions is definitely superior to MySQL's attempts to add in all the extra features. PostgreSQL 9.x series has some amazing capabilities.
I dunno. Think about this. If HP's CEO "happens" to end up in a country with no corporate tax, the company can move its "official" HQ there. Instant tax haven - and one that any revision of tax laws couldn't do much about because it would involve the CEO and not just some unused office with only a janitor in it.
Slashdot Mirror
The entire membership of the Firewire committee.
Depends on which Windows. It will boot up Vista, though, and I believe they got a copy of Notepad fired up.
The exact translation of Arrrrgh is unknown, but seems to involve the translator being sliced up with a cutlass before walking the plank.
Not necessarily wrong. If they have N times as many lines of code to audit, they need to spend an absolute minimum of N times as much just to stay on level pegging. Spending N/2 times as much is still more, but it isn't usefully more.
Then there's program arcs. You can't just validate each line of code, you have to validate each arc as well. Windows 7 probably has many, many more program arcs than say, oh, Photoshop. At least, I hope so. If you test twice as many arcs but your code has a hundred times as many, you're spending more and doing more but getting a fiftieth of the coverage and therefore a fiftieth of the quality control. At best.
I'm not saying Microsoft gets it right, either. I strongly suspect that the efficiency and quality of their testing is pathetic. Thus, dollar for dollar, I don't think they actually test even in absolute numbers as much as their rivals.
Remember, not all testing is of equal worth. If you were to add asserts at the start and end of each arc through the code that specify each and every invariant that must be true at those points, you could eliminate most common bugs with very basic tests. In the case of applications, if you then added a strict debugging dynamic memory library, you should be able to clear out a significant fraction of the buffer overflows. If you then threw a static checker (Klokwork and Coverity make good but hellishly expensive products) at the code, you could clean out a lot of the remaining common flaws.
Not all coding is of equal worth, ether. If coders are held to the CERT standards for coding, you'll get better code than if you hold them to the "would-it-fly-on-tucows" standard. The "extreme programming" method of writing tests first and code around the tests should also help.
However, even Microsoft couldn't afford Coverity's charge per line of code for something the size of Windows. I'm not sure they could afford the charge even for Internet Explorer. Just because the software would be valuable doesn't mean it is practical.
My argument is that you're choosing the most expensive implementation of a specification and then blaming the specification for the price.
There are affordable, practical ways to achieve the same results and that totally eliminates the price side of your complaint (which, apparently, still has this fictional multiplication of servers which I've already demonstrated is not required).
If you want to argue against the idea, fine. But produce a VALID argument, not a bullshit one. I have no respect for bullshit artists.
Well, no, because the local version is still there and the library path overrides the global path.
You can't avoid bit-rot completely, but you can minimize it.
I've broken RPM and DEP so often I've lost count. They work, but only to a point. Part of the problem is that packages aren't generally maintained very well. In fact, that's most of the problem. Especially when you get name-clashes in the standard directories.
The rest of the problem is the way the data is stored. The package managers don't do much in the way of normalizing, which can seriously mess things up.
One method is to have a tool for interrogating the API version and also testing the API against some set of tests that relate to the application being installed. You'd then apply the following:
This should keep redundancy to a minimum. There will be some, since there's nothing in this to collaborate between apps using this method, but it's a start.
If there is no OS (ie: it's a bare-metal application), there's no user accounts, there's no shells, there's no login daemons (there's no daemons or services of any kind), there's no threads (threads need an OS), it's a pure round-robin (since anything else needs an OS).
Since there's no management (no OS, no threads), all packets are dumb. You have packets going in, getting decrypted and being passed to the internal network. Likewise, packets come in, get encrypted, get pushed out.
Because the maximum size of a packet can have is fixed, and because it's round-robin, you can use a fixed-size round-robin window with fixed-size entries in it. Therefore no dynamic memory problems. In fact you have to, since a lack of OS means no memory management means no dynamic memory.
Ok, so there's no way you can do a buffer overflow attack, no way you can do underruns, no way you can break the stack (cos there isn't one), no way to inject commands (and even if you could find a vulnerability the lack of threading means the box failsafes to no I/O if you inject an instruction).
If there's no OS, you can't have device drivers for things like USB keys or any other pluggable device. If it's a diskless station (ie: everything runs out of flash or eeprom, since there's nowhere else to get the data), other physical attacks - such as adding a drive or inserting a floppy - would do nothing.
(Even if you rebooted the machine, you couldn't do anything - no filesystem. It's a raw image.)
So if you want to tell me that a diskless OS-less proxy -is- possible to compromise, you'd best be able to prove it. None of the above is implementation-dependent, so don't weazel out. Either you're this super-cool expert that can find a way to break the above or you're not. And if you can, you'd best damn-well be able to prove it.
You have yet to prove that the above solution would "balloon costs". (Hell, you've yet to show that adding an RSA card to machines would balloon costs, given the cost of a typical datacenter.)
So I'm giving you the chance to do so. I want you to price up the cost of a complete system - two NIC cards, a chipset with built-in PRNG, 256K RAM (way more than you need, but you might even need to go higher as I'm not sure if you can buy in units that small at a decent price) and maybe 128K Flash (again you may need to buy larger) and a minimalistic motherboard. PC104 would be fine.
(You can skip the cards if the motherboard has two independent NICs built onto it.)
I want you to tell me how much that would set an IT department back, using decent components (not high-grade, just decent).
You're a fool if you think there's no value in an IT department that loses money. It is the NET value to a business that matters, not the local value.
You're also a fool if you think only a tiny fraction "has" to be encrypted - context is everything, as I said. It's how virtually all social engineers operate, it's how virtually all hackers operate. Cripple the context and you cripple them all.
If you've no idea what point I'm trying to argue, you're not much of a security guy. In fact, I'd call you pathetic.
Technology may improve within 2-3 years, but so what? Technology improving won't change whether a buffer overflow is bad, and won't change whether mandatory access controls are good.
Improved technology might help people QA their software, but it won't eliminate the need for QA to be applied.
Improved technology might eliminate the need for passwords, but it won't eliminate the need to ensure that password-protected systems can't be attacked by use of a rainbow table.
Improved technology might help produce superior identity verification, but if you provide an API that bypasses such schemes, such improvements won't be worth a damn.
So what is your point?
What do you mean "could"? The Internet Auditing Project revealed a third of Unix systems were insecure, and more recent surveys have revealed Windows boxes getting broken into within minutes of connecting to the Internet.
If the mandated security brought systems up to a minimum standard equal to an NSA-recommended install of Linux or a Trusted OS, circa 2010, with a "sunshine" clause that required the law be revised or automatically expire within, oh, 8 years, the odds are extremely high that we'd have a bullet-proof environment for the duration of those 8 years and a damn-near bullet-proof one for many years after even if the law was never updated and allowed to lapse.
(After all, admins would then be used to configuring systems sensibly and have forgotten how not to.)
They trust encryption combined with a lack of context. I specified that they do not trust encryption WITH context. Do try and read before you bitch.
And, no, hardware encryption has no holes. Neither does encryption via an FPGA. Nor indeed does an IPSec tunnel. Not one of these offers context and all offer encryption as good, or better, than SSL.
Using a DMZ is secure, since the unencrypted network is not publicly visible. It is an isolated network. Having a firewall that only permits traffic to/from the proxy also reduces exposure. A diskless, OS-less proxy is virtually impossible to compromise (there being no logins to hack, no system commands and no privileged services).
Seems to me that your awareness of security is, well, pretty feeble.
HTTPS uses more resources because people use software encryption (which is expensive). If you used hardware acceleration, you'd have no overheads at all at the machine level. You wouldn't need even one extra server. And hardware acceleration doesn't cost the same as 2 beefy servers.
Secondly, you're not limited to HTTPS - most firewalls are quite capable of supporting IPSec in opportunistic mode (ie: keys are generated and exchanged at the time the tunnel is set up). It serves much the same purpose, in that all data going off-site is encrypted.
The use of strong ciphers relies on the ciphers being strong. A cipher can be broken at any time and unless the person breaking it tells you, you do not - and cannot - know they have done so. Relying too heavily on the strength of the cipher alone is not a good approach.
This is why the DoD mandates that users of encrypted telephone systems should keep open context to a minimum and enable the encryption as soon as possible. Chit-chat, however innocent, can help an attacker know what they are to look for and how they should look. I think it safe to say that if the DoD trusted strong ciphers alone to do the job, they wouldn't be so paranoid.
(Indeed, if encryption alone were sufficient, you'd see classified material - albeit encrypted - on unclassified networks. Again, that is verboten. Those with their jobs, egos and indeed purpose on the line do not trust encryption to ever be strong enough on its own.)
Ok, what about all those admins who can't even afford a cheap accelerator card? (And by "cheap", I would include any card that carries an FPGA large enough to hold one of the public, open-source cryptographic hardware implementations and is also fast enough to out-perform a pure software solution.)
Well, is the firewall capable of acting as a secure proxy (ie: providing all the SSL)? If so, what's the problem? There's nothing that requires the web servers themselves to do the SSL in order for the Internet to see SSL.
If not, then can you afford a server that has a beefy processor but minimal memory (diskless is fine) that can act as a secure proxy in a DMZ-type situation? All it needs to do is handle SSL traffic to the outside world and non-SSL traffic back to the web servers. It needn't even run a true OS.
If you can't afford a DMZ and can't afford a cryptographic NIC or crypto engine, then you probably can't afford to maintain what hardware you do have. (A decent hardware RAID array will cost you more than a decent cryptographic system, and woe betide those with no spares, for hardware has a nasty habit of failing.)
That's part of things, but not the whole of things. The CERT stuff eliminates a lot of the bugs that introduce security holes, but it doesn't really cover any of the access controls within the app or between the app and OS, nor does it really cover how to have provably secure software*.
*If you can prove that your dynamic memory library, your I/O libraries and your access control library are correct, and that all dynamic memory and I/O accesses that have the potential to do Bad Things when used without authorization are routed through the access control library, then you have provably secure software. This is NOT the same as having software that can handle provably insecure users, it merely proves that the software cannot behave other than as intended.
You don't need a whole lot of extra code or a whole lot of extra work. For example, if you had a malloc replacement library that was proven correct, you don't need to have one written for every program and you don't need to do a whole lot of cleanup in existing software.
If you also had a drop-in replacement for sockets and file I/O, again using the standard APIs but where the code was proven correct, the same thing applies.
Finally, if all these drop-in replacements made sure they called system functions protected by SELinux, GRSecurity or another security module where applicable, you've got the access controls nailed.
The only things that are needed to be 100% bullet-proof are these libraries and the security module in the kernel. Getting them to 100% is the hard part, which is why "secure" programming languages often don't allow things like dynamic memory at all and severely restrict all other channels.
Obviously, getting the rest as close to 100% correct as possible is a Good Thing, but it is actually very difficult to have provably correct software of any level of complexity. Not impossible, but very very difficult. (There ARE cases where it is impossible, but the proof of this doesn't say what cases, only that there are a non-empty set of them.)
If the security flaws are not spread, then they stop being a "required" part of the system. It is when they are perpetuated that they become unfixable because fixing them will break things.
By having properly-built secure components, you make it so that it is possible to safely replace the buggy components over time. This is the only way that "expected" security flaws ever really get fixed.
So it's not really an "except" at all. What I described is a necessary first step. If both the original component and the new component require the security flaw, fixing the original component will break the new component. If the new component optionally supports the insecure method but also supports the correct, secure method, then fixing the old component doesn't break anything. Better still, it also allows you to eliminate the shim, accelerating performance.
Not starting from a clean slate is immaterial. A new component can be 100% self-contained (and therefore verifiably clean within itself), communicating via some intermediary layer that handles legacy APIs, network connections, pipes, shared memory, et al.
The new component can therefore be as provably secure as you want. Security holes will then be contained (they must be in pre-existing code and cannot spread into new code).
This is not often done in the business world because they're stupid and prefer to burn huge amounts covering their backsides when inevitable breakins occur rather than the relatively small extra needed to properly secure systems in the first place. (It's stupid because such a method can never be cost-efficient in the long-run and only looks very marginally better on the books in the short-term.)
If we start with the fact that the NSA is responsible for the Rainbow Series, partly responsible for Common Criteria, totally responsible for the NSA guidebook on securing Linux, and also totally responsible for the concepts in SELinux (remember, they talk about methods not code), it follows that the NSA is implying that the processes used to develop this public information are rigorous, sound and the methods the NSA use internally for projects they don't talk about. It actually doesn't say that what the NSA publishes is what they use - they only say that methods that are public are what they use. The source is implied.
It depends. The best place to hide something is in plain sight. And the best way to hide encrypted somethings is in a sea of equally encrypted somethings. If the NSA had some algorithm that they felt OK with others knowing and also using themselves, then any traffic of theirs using said algorithm would be indistinguishable from any other traffic. An attacker would need to decrypt everything in order to establish whether or not anything was being sent that was of interest. Even if there was a vulnerability in the encryption that reduced the search space to something theoretically manageable, having to break each and every single conversation on the Internet would push the search space back into the unmanageable region.
ObSidetrackingRant: This is why sites that use SSL should use SSL for everything - it adds noise which conceals the encrypted packets which would actually be of interest. Don't forget that the biggest weakness in secure systems is context. If you have enough context, you can bypass a lot of system security. A simple example would be the "secret question" systems that are popular. If you know enough about a person, the odds are high that you can guess what the answers are. Another example would be social engineering - if you have enough personal information, you could pretend to be that person to a system admin. Social engineering is really the sum total of all the new cracking/viral methods that are being used these days. Far from being new, it's merely better-automated and better-documented. Social engineering was standard back in the BBS days.
I don't know. I'm waiting for the Cybermen to get back from their meeting with their Cyberleader on the issue of Cyberbombs.
Actually, legislation might not be a bad idea. I propose that it be illegal to store passwords in plaintext (or equiv), allow passwords that John the Ripper can break, not QA code correctly, not encrypt traffic, provide identity verification that is bogus, or provide APIs that allow the protection in place to be bypassed. First-time offenders should be forced to read my posts - not because they're necessarily useful on issues of security, but because they're usually long and occasionally tedious. Repeat offenders should pay for the carpal tunnel syndrome surgery I'll eventually need because of all the writing of long and occasionally tedious posts.
Vile wretch! Thine insults to UIDs of the Fourth Order shall see ye hung, drawn and quartered! Verily, before the sundial reaches noon!
They did brilliantly for a while - but at some point they stagnated and abandoned ARM, followed by the Acorn PC (which was never finished).
RiscOS was infinitely superior to any other GUI of the time, but failed to keep pace. For whatever reason, Acorn became too insular.
When they did finally abandon their entire IT division, a breakaway group tried to continue to develop the Acorn PC. I don't know what happened there, but suspect Acorn got stubborn, given the press releases of the time from them.
We don't necessarily need to replace Tomcat, JBoss, etc, we merely need to be able to handle the ABI they expect -and- be able to run them without a virtual machine (ie: compile them to native form).
Ok, correction. We don't need to replace them - yet. If we use an intermediate step or two, where these existing tools are gradually moved onto a different language or replacements are developed, then the migration will be much less painful and much more likely to actually happen.
I like D. Mind you, I like lots of languages. :) Seriously, D would be the "obvious" choice as it would mean the lowest learning curve for developers and the greatest amount of directly translatable code.
Drizzle is a fork of MySQL from before it was Oracle-ified. It is therefore 100% compatible with anything actually in use for MySQL. However, it is lighter-weight and therefore faster. As such, it is ideal for a simple web site with PHP.
PostgreSQL is heaftier and if you need the extra functions is definitely superior to MySQL's attempts to add in all the extra features. PostgreSQL 9.x series has some amazing capabilities.
I dunno. Think about this. If HP's CEO "happens" to end up in a country with no corporate tax, the company can move its "official" HQ there. Instant tax haven - and one that any revision of tax laws couldn't do much about because it would involve the CEO and not just some unused office with only a janitor in it.