This is oftopic for this thread, but Miguel is defianetely one of the people to ask:
Microsoft claims that the CLR bytecode is designd for JIT. Java bytecode was definately originally designed to maximize portability of interpreters (as in there are JVMs for 8-bit microprocessors and 64-bit "big iron") rather than for optimal recompilation to native code.
To what extent is this true? Please tell us about features in the bytecode or the class file format that are optimized for efficient recompilation on the fly. I've read Ken Thompson's paper at Bell labs about the design of the DIS virtual machine. It would seem that a stack-based virtual machine is much less suitable for JITs than a memory based virtual machine. Cam you refute this, particualrly on non-register-starved platforms (PPC, ARM, Itanium)? Granted, memory machines much more complicated in concept than stack machines. However,for optimum register allocation in the native code, you need to basiclly undo the stack machine's register allocation (to two GP registers, the top of the stack) before doing register allocation, while memory machine bytecode is basically ready for register allocation with little preprocessing.
You must have some gripes about MSs VM design. What are the main ones? What about the VM imposing C#s object model at the "hardware" level instead of using constructs written in bytecode and using privledged VM modes (analogous to privledged CPU instructions on a real machine, but perhaps much higher-level instructions) to enforce security restrictions? (This seems to be one of the main gripes of enthusiasts of non-ALGOL-descended languages on the.NET platform.)
While you're at it, can you point to features that indicate MS really wanted a VM that worked elegantly with languages very unlike C#? I've heard that a main deterant to Stackless patches being merged into the main Python distribution is the changes necessary are very ugly to do in the JVM and would probably cause a major split with the Jython people. Would it be easy to get efficient handling of tail-recursion and efficient implementations of Stackless Python? How badlymangled internally are Perl.NET and Python.NET?
Thanks for all of your hard work, and good luck in the future.
Are you a former lawmaker, or otherwise mentally deficient?
The bag is here, the cat is long gone. Taking beauwulf source code off the net is like taking pee out of a pool. (blatantly stolen from News Radio)
The physics behind nuclear weapons is well understood and widely published. It took a small town full of geniuses to figure it out the first time, (and determine that it's even possible) but no longer. They also designed a Uranium gun-type weapon and a Plutonium implosion-type weapon. The latter is muchmuch more complicated. Designing a gun-type Uranium weapon is trivial, and anly slightlymore difficult if you're restricted to pen, paper, and sliderule. (Granted I'm an MIT student, so I'm probably overestimating the amount of brain power available to a large terroist organization.) The difficulty lies in the tremendous amount of effort/electrical energy/sapce/time/money required to perform isotope seperation/smuggling without getting caught before you have the chance to detonate the weapon.
Cracking bulk ciphers is basically infinately parallelizable and does not require much communication bandwitdth at all. Beauwulf clusters don't gain you much. You'd get better performance running your cracking programs over V2OS, FreeDOS, or some other ultra-lightweight OS.
Bin Laden et al. are very smart. Sure they have some grandios long-term plans about getting the US out of Saudi Arabia, creatig an Islamic super-state, and acquiring a fission bomb. However, they are very smart and efficient. They use low-infrastructure, reliable attacks for the most part. Planes filled with fuel, boats filled with conventional explosives, and dirty bombs are all very simple and can be potentially acquired by a single autonomous cell. I'd be much more worried about poison gas attacks and coordinated massively distributed firebomb attacks. These are the kind of low-tech high-casualty attacks at thier disposal right now.
The marginal cost to the record label of your downloading an mp3 is identically zero.
It's more like bribing a McDonnalds worker to give you the next burger that's been in the queue too long instead of throwing it out.
When you download an mp3, there is no extra dirt you track into the theater, extra wear and tear on a seat, etc. There is no extra strain on amusement park security staff, restrooms, wear and tear on the tracks, electricity used to hoist you up that first hill, etc. You also don't take up an extra seat anywhere.
My friend worked at a second-run music theater in HS. The managers let employees get in free and take one friend to one free movie per day. He'd convince other employees (that were working concessions or ticket sales at the moment) to let him use thier "free friend"s so he could get a few friend in for free. This was certainly not what the manager had in mind, but it wasn't theft as long as the theater wasn't packed.
Parrot is a 32-register VM (32 registers of each of 3 types), so you should se significant performance increases over almost all of the VMs out there when running on a decently modern ISA (Itanium, PPC, Alpha, PPC, MIPS, and to some extent x86-64). Remember that the Mono and.NET people are more or less copying the design of the JVM while the Parrot design is completely different from (AFAIK) anything designed before.
Stack-based VMs are much easier to create, but generate a lot more overhead in the JITs. (See Ken Thompson's paper on the DIS VM from the Bell Labs website.) Bickering is bad, but they really want to get it right. You forget, St. Larry has a huge community behind him.
Now,I wish they'd make an ultra-lightweight memory machine VM and implement higher level VM extensions using the VM code itself. All of these higher-level VMs force thier own object models on the code. Perl, Python, etc. get thier object and calling models mangled to be C#-like in order to run on the CIL. Automagic memory management and pointer safety are wonderful things, but stuffing round pegs (Python objects) into square holes (C# objects) doesn't help anyone. I can definately see making seperate sets of registers for pointers and non-pointers (address spaces for mempry machines) and having pointer arithmetic functions cause inlining of helper functions instead of directly manipulating pointers, depending on CPU state. This would allow you per-thread enforcement of arbitrary memory management/object models. If you didn't want pointer safety, etc., it would run blazingly fast. HP had a project called Dynamo where they made a JIT VM that took in PA-RISC object code as its "byte code". On actual PA-RISC hardware, it usually ran very close to native speed, and in some cases exceeded native speed through heavy use of runtime optimization in the critical sections of code.
Anyway, my point is that on architectures with many registers, stack-based VMs are not the way to go for fast JITs. I applaud the Parrot people for taking on such a difficult task. Hopefully we'll see performance payoffs, particularly on non-ia32 machines.
I'm not aware of any FPGAs that clock very fast. The danger is some government fabbing a Gallium Arsenide dedicated chip.
A nice maty POWER4 chip may very well outperform an FPGA, as long as you keep the modulus size small enough. If you're going to make the delay only a month or two, a 768-bit modulus should be fine. Iin this case, The modulus is 12 registers wide. That's 108 multiplications that need to be done. There are also a bunch of additions. A POWER4 has a big cache and can do several integer multiplies per clock cycle. There may very well be some optimizations as well.
In any case, a "break" in the system means that people have your exploit faster. However, this makes things no worse than full disclosure, which I belive to be the current best approach. On the other hand, if you were really worried, you could also lie about the puzzle. The vendor wouldn't know you had lied until reports of bogus decryption keys started comming in.
With the proper low-level drivers, you can read raw data off the CD. We've already seen third-party Windows drivers to allow you to rip Cacrus CDs. These sound just like Cactus CDs with ISO 9660 tracks added. Reading the raw device under *nix might evn work for many cd drives. This sounds like a simple and non-clever "solution" with many simple and non-clever counter-solutions.
It may very well be that Java applications run as fast as "native" x86 code on TM chips.
I wish they'd show JVM and CLR benchmarks on different CPUs. If I were a betting man, I'd bet that TM chips have an extra edge in less optimized code, such as that produced by JITs. HP did some research on code morphing from PA-RISC to PA-RISC (yes, that makes it much easier to do comaprisons, find bugs, figure out optimizations, etc.) that ran some code faster than running the binary natively. It performaed much better compared to native execution when the native binary was compiled with fewer optimizations.
Thier technology certainly is an elegant solution to deaing with ISAs, particlarly ones that have such high decoding overhead. I wish they also exposed an instruction set that was lower overhead for thier code morphing engine. Maybe something like RTL (HP calculator libraries are compiled to a RTL for portability) or a memory machine ("infinate" registers) like the DIS virtual machine from Bell Labs.
However, I'm concerned with issues regarding security. We have all heard the old saw regarding closed source vs. open source: 'Security through obscurity doesn't do the job', however this begs the following question: when does handing the enemy a blueprint of the fortress make guarding the castle easier? With Open Source, I'm concerned that not only are hackers being issued a blueprint for an attack, but that they can also build flaws into the system before it is even implemented!
This is a risk regardless (as opposed to irregardless, which is not a word) of the openness of the source. Which MS product shipped with the "Netscapeengineers are weenies" backdoor password?
Irregardless of the benefits Open Source can bestow on the government, it brings with it a flaw of extraordinary magnitude. Witness the problems caused when the latest flaw is discovered in BIND or ftpd, or when a trojan is actually placed in the software people use to protect their system (tcpdump)! Maybe the Japanese are just trying to wrangle a better price out of Microsoft, but I think it's possible they don't want to be left unguarded a couple of months whence after picking the cheaper solution.
I assume you mean "Regardless" (without regard or without regarding) instead of "Irregardless". (It's not a real word, but it would mean the opposotie of the sense youwere trying for if it was a real word.)
OpenSource will almost definately get you faster patches (at least compared to MicroSoft's security-though-denial strategy). Also, remember when MS shipped a CD with a virus-infected product? (Does someone want to find me the/. story or another link?) You can manuallycheck for all known types of flaws/malicious modifications with OpenSource. With closed source you can run virus checks, but it's usually infeasable to decompile and look for back doors.
Open Source is a bargain that offers far more than what you pay for; however, its track record with security is spotty, and who do you sue when things go wrong?
Who do you give thr death penalty after a suicide attack? If you fall back on the legal system or the prison system, you've got problems. When was the last time a customer sucessfully sued MS for damages due to faulty products or neglegent design/coding practices? Spotty scurity is usually better than rock-steady-awful security. There's also a lot to be said for being about to do your own audts instead of having to trust the vendor.
My point is, the cracker community doesn't need bugtraq to even find these exploits.
Then it doesn't matter at all what Bugtraq does. However, you think this means they shouldn't publish exploits. Your logic is all backwards.
If it doesn't matter what BugTraq publishes, then BugTraq should publish exploits ported to as many programming languages and platforms as pssible, for educational enlightenment.
Look at Rivest's announcement of the MIT LSC 70th b-day puzzle... I think there's Java code in there for solving the puzzle. It's actually VERY simple math... maybe in a few weekends I'll codesomething up and ve it to the Bugtraq people. In any case, it's pretty simple to code up. It's less complicated than coding up DSA, which took me all of one evening.
Exploits are useful and educational. Reading actualexploit code and walking though it helps you write more secure code. Posting exploit code is a community service beyond just putting pressre on the vendor.
Note also that it's been 6 weeks since he contacted Microsoft and basically got a one-fingered salute. This is similar enough to other problems with IE in the past that it's not too far fetched to assume the black hats already know aboout it. Microsoft needed the only kind of wake up call they respond to -- a public relations stink.
IMHO, if BugTraq is going to post vulns, they need to be non-working, and the user has to have the knowledge to fix them. Especially on closed platforms, it does less good release exploits for code you can't fix, because you're not fixing the problem, you're just working around it.
umm... I think the cracker community has thier own system of karma, in the form of reputations. The guy who fixes the exploits for the kiddies gets massive ammounts of karma. There are plenty of smart people willing to fix the exploits for the kiddes, if nothing else, it raises the "noise floor" for hunting down the skilled crackers. Posting broken exploits isn't security though obscurity, it's security though denial.
Look at "Timelock puzzles" or something to that effect by Professor Rivest. You can make the solution to a cryptographic puzzle the decryption key for an exploit. Publish the puzzle and the encrypted explot along with your submission. Give the vendor the decryption key. The problem of repeatedly calulating quadratic residues modulo a Blum integer is essentially non-parallelizable, so it doesn't matter if you set up a beowulf cluster or a distributed.net project. You still only solve the problem as fast as your fastest node. Hence governments don't get the solution much faster than some slashdot reader with a 4 GHz overclocked system. If you have REALLY low latency interconnects, you may be able to spread the work out among several CPUs in the same box.
This way the vendor knows the clock is ticking, and ance you've published the puzzle and the encrypted exploit no ammount of legal manuvering can put the cat back in the bag, so to speak. Basically, it allows you to put pressure on the vendor while still being responsible and giving the vendor a month (for instance) head start. You can put decent bounds on how long it will take the fastest consumer machines to solve the puzzle. There's currently a puzzle running that's supposed to get completed shortly before the MIT Laboratory for Computer Science's 70th b-day, for instance.
I know the crashes are mainly due to the older games that the kids play which are not totally compatible with XP, but hey, they USED to run just fine under Windows98.
Most people are so used to crappy software, it's really sad. If a user-space program can crash your operating system, don't blame the program. That's an OS bug. The program may even be totally programtically correct. For instance, printing a tab folloed by two backspaces and another chracter at the beginning of a DOS emulation window will kill all of the WinNT family. XP reboots, the others BSOD If a program crashes itself, that's a program bug. If the program can do anything it's not supposed to do, that's an OS bug.
I had an internship at a startup that originally planned on getting CC certification for a product of thiers.
The Common Criteria replace the old NIST "Orange Book" specifications.
The CC is a certification standard set up by the NSA, NIST, and some European counterparts. It has an ISO number, too. It can be applied to any computer system (an OS, a browser, a PCI card) as long as you can clearly define the system boundary. The criteria keep alking about the target of evaluation (TOE) instead of calling it an OS, although most commonly you hear about CC being applied to OSes.
When you submit something for CC evaluation, you submit a very specific system with very specific configurations. Anything outside this narrw set of configurations isn't certified. The CC primarily look at design and documentation, so things like buffer overflows don't enter in to the equation. At the highest level (EAL 7), you need all kinds of (mathematical) demonstrations and proofs of sound design (probably mostly involving graph theory). At the lower levels, they require less rigorous proofs and deonstartaions. Basically there are a bunch of feature lists in the criteria and you need to convince the certifier that you have the required features. Good admin/user documentation and configuration tools are a big part of the CC. If it's secure, but not well documented how to keep it secure, you can forget it.
It's expensive to submit a system for certification, so even if the SELinux documentation and config tools were up to par, iit'd be unlikely anyone would pony up the cash to get it evaluated. In terms of software features, I think SELinux could cocievably be EAL 4 or quite possibly higher.
Linux, *BSD, and the NT branch of Windows use rings. (The Windows 95 branch may have also used rings, I'm not familiar at all with Win 95 internals.) I'm not aware of any *NIX whose kernel doesn't run in ring 0. User apps run in ring 3. You can't make a function call (or other jump or branch) into a lower ring, but instead you need to use an interupt. Some instructions are also unavailable in certain rings.
Without hardware enforcement of the abstraction barrier, your user space code could jump int the kernel at spots right after privledge checks, or could manipulate the MMU and get raw acess to every device and every memory location. This would make privledge escalation trivial.
As long as you have 2 (properly designed) rings supported by hardware, you can emulate as many rings as you want, but you'll pay a performance hit.
One important note is that all XBox code runs in ring 0 and in a single address space (unless a devloper goes WAAYYY out of thier way). This is for performance reasons, but if there's an exploitable buffer overflow in a game, it's mre than a "root" exploit, it's a kernel exploit. (Yes, both Linux and WinXP allow superusers to modify the running kernel, so the distinction is moot in these cases.) This wou;d allow for a software "mod chip".
You realize the way they account for vulnerabilities is flawed, right?
Most ofthe OpenSource software would count as third-party software on MS systems. If there's a problem with XMMS or GAIM or PHP it gets counted as a Linux vulnerability. However, problems with WinAMP, AIM, or ColdFusion don't get counted as Windows vulnerabilities. GAIM didn't have that AIM buffer overflow. You also realize, I assume, that you're only counting vulnerabilities know to the white hats, when in fact, it's time windows of open vulnerabilities known to the black hats that really matter.
Also, MicroSoft is much more in the habit of bundling many vulnerabilities together in one announcment, making counting announcements even more rediculous.
I wonder how much work it would be for someone to implement a commercial version of this using Rijndael, or AES, or something unclassified. With a larger market than the government, maybe it could be cheaper, and the development costs made up on volume...
First of all AES is a subset of Rijndael. (Rijndael can be defined with multiple block sizes, AES is Rijndael with a 128-bit block).
Second, the IEEE is
working on a WiFi standard using AES.
Third, it appears that AES is no stronger than 100-bit effective key size due to the XSL attack. (Serpent is reduced to a maximum of 200-bit effective key size. Twofish and RC6 appear to be safe against XSL.) I'd go with Twofish or RC6, but everyone is going to use AES b/c it's the NIST standard, despite it's weaknesses.
When the NIST decided on Rijndael, everyone knew it ran the fastest and was probably the weakest, and now we're stuck with 100-bit (maybe even weaker) equivalent keys.
Slashdot Mirror
I think quite literally, the LZW patent expired 20 Dec. 2002. However, I think I read this on /., a few weeks ago, so it may or may nto be true.
Microsoft claims that the CLR bytecode is designd for JIT. Java bytecode was definately originally designed to maximize portability of interpreters (as in there are JVMs for 8-bit microprocessors and 64-bit "big iron") rather than for optimal recompilation to native code.
To what extent is this true? Please tell us about features in the bytecode or the class file format that are optimized for efficient recompilation on the fly. I've read Ken Thompson's paper at Bell labs about the design of the DIS virtual machine. It would seem that a stack-based virtual machine is much less suitable for JITs than a memory based virtual machine. Cam you refute this, particualrly on non-register-starved platforms (PPC, ARM, Itanium)? Granted, memory machines much more complicated in concept than stack machines. However,for optimum register allocation in the native code, you need to basiclly undo the stack machine's register allocation (to two GP registers, the top of the stack) before doing register allocation, while memory machine bytecode is basically ready for register allocation with little preprocessing.
You must have some gripes about MSs VM design. What are the main ones? What about the VM imposing C#s object model at the "hardware" level instead of using constructs written in bytecode and using privledged VM modes (analogous to privledged CPU instructions on a real machine, but perhaps much higher-level instructions) to enforce security restrictions? (This seems to be one of the main gripes of enthusiasts of non-ALGOL-descended languages on the .NET platform.)
While you're at it, can you point to features that indicate MS really wanted a VM that worked elegantly with languages very unlike C#? I've heard that a main deterant to Stackless patches being merged into the main Python distribution is the changes necessary are very ugly to do in the JVM and would probably cause a major split with the Jython people. Would it be easy to get efficient handling of tail-recursion and efficient implementations of Stackless Python? How badlymangled internally are Perl.NET and Python.NET?
Thanks for all of your hard work, and good luck in the future.
It's more like bribing a McDonnalds worker to give you the next burger that's been in the queue too long instead of throwing it out.
When you download an mp3, there is no extra dirt you track into the theater, extra wear and tear on a seat, etc. There is no extra strain on amusement park security staff, restrooms, wear and tear on the tracks, electricity used to hoist you up that first hill, etc. You also don't take up an extra seat anywhere.
My friend worked at a second-run music theater in HS. The managers let employees get in free and take one friend to one free movie per day. He'd convince other employees (that were working concessions or ticket sales at the moment) to let him use thier "free friend"s so he could get a few friend in for free. This was certainly not what the manager had in mind, but it wasn't theft as long as the theater wasn't packed.
Stack-based VMs are much easier to create, but generate a lot more overhead in the JITs. (See Ken Thompson's paper on the DIS VM from the Bell Labs website.) Bickering is bad, but they really want to get it right. You forget, St. Larry has a huge community behind him.
Now,I wish they'd make an ultra-lightweight memory machine VM and implement higher level VM extensions using the VM code itself. All of these higher-level VMs force thier own object models on the code. Perl, Python, etc. get thier object and calling models mangled to be C#-like in order to run on the CIL. Automagic memory management and pointer safety are wonderful things, but stuffing round pegs (Python objects) into square holes (C# objects) doesn't help anyone. I can definately see making seperate sets of registers for pointers and non-pointers (address spaces for mempry machines) and having pointer arithmetic functions cause inlining of helper functions instead of directly manipulating pointers, depending on CPU state. This would allow you per-thread enforcement of arbitrary memory management/object models. If you didn't want pointer safety, etc., it would run blazingly fast. HP had a project called Dynamo where they made a JIT VM that took in PA-RISC object code as its "byte code". On actual PA-RISC hardware, it usually ran very close to native speed, and in some cases exceeded native speed through heavy use of runtime optimization in the critical sections of code.
Anyway, my point is that on architectures with many registers, stack-based VMs are not the way to go for fast JITs. I applaud the Parrot people for taking on such a difficult task. Hopefully we'll see performance payoffs, particularly on non-ia32 machines.
A nice maty POWER4 chip may very well outperform an FPGA, as long as you keep the modulus size small enough. If you're going to make the delay only a month or two, a 768-bit modulus should be fine. Iin this case, The modulus is 12 registers wide. That's 108 multiplications that need to be done. There are also a bunch of additions. A POWER4 has a big cache and can do several integer multiplies per clock cycle. There may very well be some optimizations as well.
In any case, a "break" in the system means that people have your exploit faster. However, this makes things no worse than full disclosure, which I belive to be the current best approach. On the other hand, if you were really worried, you could also lie about the puzzle. The vendor wouldn't know you had lied until reports of bogus decryption keys started comming in.
With the proper low-level drivers, you can read raw data off the CD. We've already seen third-party Windows drivers to allow you to rip Cacrus CDs. These sound just like Cactus CDs with ISO 9660 tracks added. Reading the raw device under *nix might evn work for many cd drives. This sounds like a simple and non-clever "solution" with many simple and non-clever counter-solutions.
The competition is getting downright dangerous.
It may very well be that Java applications run as fast as "native" x86 code on TM chips. I wish they'd show JVM and CLR benchmarks on different CPUs. If I were a betting man, I'd bet that TM chips have an extra edge in less optimized code, such as that produced by JITs. HP did some research on code morphing from PA-RISC to PA-RISC (yes, that makes it much easier to do comaprisons, find bugs, figure out optimizations, etc.) that ran some code faster than running the binary natively. It performaed much better compared to native execution when the native binary was compiled with fewer optimizations.
Thier technology certainly is an elegant solution to deaing with ISAs, particlarly ones that have such high decoding overhead. I wish they also exposed an instruction set that was lower overhead for thier code morphing engine. Maybe something like RTL (HP calculator libraries are compiled to a RTL for portability) or a memory machine ("infinate" registers) like the DIS virtual machine from Bell Labs.
IP doesn't preserve lower level addresses. Unless a machine on the LAN is cooperating, I don't know of any way to get IP addresses across the globe.
Assuming formulaing implies condoning : -1
Moderation totals: -2
This is a risk regardless (as opposed to irregardless, which is not a word) of the openness of the source. Which MS product shipped with the "Netscapeengineers are weenies" backdoor password?
I assume you mean "Regardless" (without regard or without regarding) instead of "Irregardless". (It's not a real word, but it would mean the opposotie of the sense youwere trying for if it was a real word.)
OpenSource will almost definately get you faster patches (at least compared to MicroSoft's security-though-denial strategy). Also, remember when MS shipped a CD with a virus-infected product? (Does someone want to find me the /. story or another link?) You can manuallycheck for all known types of flaws/malicious modifications with OpenSource. With closed source you can run virus checks, but it's usually infeasable to decompile and look for back doors.
Who do you give thr death penalty after a suicide attack? If you fall back on the legal system or the prison system, you've got problems. When was the last time a customer sucessfully sued MS for damages due to faulty products or neglegent design/coding practices? Spotty scurity is usually better than rock-steady-awful security. There's also a lot to be said for being about to do your own audts instead of having to trust the vendor.
Then it doesn't matter at all what Bugtraq does. However, you think this means they shouldn't publish exploits. Your logic is all backwards.
If it doesn't matter what BugTraq publishes, then BugTraq should publish exploits ported to as many programming languages and platforms as pssible, for educational enlightenment.
Look at Rivest's announcement of the MIT LSC 70th b-day puzzle... I think there's Java code in there for solving the puzzle. It's actually VERY simple math... maybe in a few weekends I'll codesomething up and ve it to the Bugtraq people. In any case, it's pretty simple to code up. It's less complicated than coding up DSA, which took me all of one evening.
Note also that it's been 6 weeks since he contacted Microsoft and basically got a one-fingered salute. This is similar enough to other problems with IE in the past that it's not too far fetched to assume the black hats already know aboout it. Microsoft needed the only kind of wake up call they respond to -- a public relations stink.
umm... I think the cracker community has thier own system of karma, in the form of reputations. The guy who fixes the exploits for the kiddies gets massive ammounts of karma. There are plenty of smart people willing to fix the exploits for the kiddes, if nothing else, it raises the "noise floor" for hunting down the skilled crackers. Posting broken exploits isn't security though obscurity, it's security though denial.
This way the vendor knows the clock is ticking, and ance you've published the puzzle and the encrypted exploit no ammount of legal manuvering can put the cat back in the bag, so to speak. Basically, it allows you to put pressure on the vendor while still being responsible and giving the vendor a month (for instance) head start. You can put decent bounds on how long it will take the fastest consumer machines to solve the puzzle. There's currently a puzzle running that's supposed to get completed shortly before the MIT Laboratory for Computer Science's 70th b-day, for instance.
Most people are so used to crappy software, it's really sad. If a user-space program can crash your operating system, don't blame the program. That's an OS bug. The program may even be totally programtically correct. For instance, printing a tab folloed by two backspaces and another chracter at the beginning of a DOS emulation window will kill all of the WinNT family. XP reboots, the others BSOD If a program crashes itself, that's a program bug. If the program can do anything it's not supposed to do, that's an OS bug.
The Common Criteria replace the old NIST "Orange Book" specifications.
The CC is a certification standard set up by the NSA, NIST, and some European counterparts. It has an ISO number, too. It can be applied to any computer system (an OS, a browser, a PCI card) as long as you can clearly define the system boundary. The criteria keep alking about the target of evaluation (TOE) instead of calling it an OS, although most commonly you hear about CC being applied to OSes.
When you submit something for CC evaluation, you submit a very specific system with very specific configurations. Anything outside this narrw set of configurations isn't certified. The CC primarily look at design and documentation, so things like buffer overflows don't enter in to the equation. At the highest level (EAL 7), you need all kinds of (mathematical) demonstrations and proofs of sound design (probably mostly involving graph theory). At the lower levels, they require less rigorous proofs and deonstartaions. Basically there are a bunch of feature lists in the criteria and you need to convince the certifier that you have the required features. Good admin/user documentation and configuration tools are a big part of the CC. If it's secure, but not well documented how to keep it secure, you can forget it.
It's expensive to submit a system for certification, so even if the SELinux documentation and config tools were up to par, iit'd be unlikely anyone would pony up the cash to get it evaluated. In terms of software features, I think SELinux could cocievably be EAL 4 or quite possibly higher.
Without hardware enforcement of the abstraction barrier, your user space code could jump int the kernel at spots right after privledge checks, or could manipulate the MMU and get raw acess to every device and every memory location. This would make privledge escalation trivial.
As long as you have 2 (properly designed) rings supported by hardware, you can emulate as many rings as you want, but you'll pay a performance hit.
One important note is that all XBox code runs in ring 0 and in a single address space (unless a devloper goes WAAYYY out of thier way). This is for performance reasons, but if there's an exploitable buffer overflow in a game, it's mre than a "root" exploit, it's a kernel exploit. (Yes, both Linux and WinXP allow superusers to modify the running kernel, so the distinction is moot in these cases.) This wou;d allow for a software "mod chip".
People like thier existing WMs. Adoption will go much better if it has an identical WM interface so people can use thier WMs without recompilation.
You realize the way they account for vulnerabilities is flawed, right?
Most ofthe OpenSource software would count as third-party software on MS systems. If there's a problem with XMMS or GAIM or PHP it gets counted as a Linux vulnerability. However, problems with WinAMP, AIM, or ColdFusion don't get counted as Windows vulnerabilities. GAIM didn't have that AIM buffer overflow. You also realize, I assume, that you're only counting vulnerabilities know to the white hats, when in fact, it's time windows of open vulnerabilities known to the black hats that really matter.
Also, MicroSoft is much more in the habit of bundling many vulnerabilities together in one announcment, making counting announcements even more rediculous.
The s-boxes in DES are maximally resistant to differential cryptanalysis. However, they are weak against linear cryptanalysis..
First of all AES is a subset of Rijndael. (Rijndael can be defined with multiple block sizes, AES is Rijndael with a 128-bit block).
Second, the IEEE is working on a WiFi standard using AES.
Third, it appears that AES is no stronger than 100-bit effective key size due to the XSL attack. (Serpent is reduced to a maximum of 200-bit effective key size. Twofish and RC6 appear to be safe against XSL.) I'd go with Twofish or RC6, but everyone is going to use AES b/c it's the NIST standard, despite it's weaknesses.
When the NIST decided on Rijndael, everyone knew it ran the fastest and was probably the weakest, and now we're stuck with 100-bit (maybe even weaker) equivalent keys.
As long as you don't use the condom and handcuffs symbol simultaneously, that means something completely different.