But are you checking that you haven't been compromised by some other software-based keystroke logger, perhaps loaded into the kernel (or hardware-based keystroke loggers as suggested by an earlier poster)? If not, then you should be aware of the risk that you are taking in reacting to the attacks that are well publicized. You may find the risk acceptable for non-life-threatening applications such as online banking. Other people may not.
The parent should be modded up. I'd add that you should be suspicious of key management carried out below the application layer. Even the submitter emphasizes the wrong point, IMNSHO, when he/she says that AES will be used to secure the connection. The choice of encryption algorithm is almost inconsequential because the world has plenty of good encryption algorithms, but the key management is the really difficult part. Designing a protocol is moderately difficult too (read Peter Gutmann's VPN rant to see some examples of poor protocols).
Yes,
NCA = Nexus Computing Application (or something to that effect). The MS documentation shows an NGSCB-enabled system in quadrants. The left-hand side is the normal stuff. The right-hand side is the new NGSCB stuff. Slashdot is not ASCII art friendly, but here goes:
normal process x nexus computing application xxxxxx xxxxxxx xxxxxxxx xxxxxxxx xxxxxx xxxxxx normal kernel x nexus
The normal kernel does not have access to the (curtained?) memory on the right-hand side, otherwise rogue device drivers could compromise the system (of course, that might be what the person at the console wants...). The nexus manages right-hand side memory and provides other limited OS functionality to NCAs, including sealing and remote attestation using TCPA.
This is my reading of the documents at
MS NGSCB
and the Longhorn Platform SDK. It would be nice if any lurking NGSCB engineers could correct it.
Right, but in the Longhorn preview's version of NGSCB you would have to turn VMWare (or MS's version thereof) into an NCA or extend the Nexus. If the former, you would also need to fold the virtualized NCAs into the VMWare NCA to get around the memory isolation between NCAs.
I agree that virtualization is possible with the TCPA spec., but I don't see how to do it easily with the preview version of NGSCB. Perhaps MS will have redesigned it by the time Longhorn ships...
There will be a keypair in tamper-resistant hardware produced by Intel. It's the "dump the private key" part that will be extremely difficult. Yes, if you could extract the private key, then you could emulate the behavior of the hardware, and Intel/Microsoft are perfectly aware of that.
It will be interesting to see how they handle revocation if a private key is ever compromised, and how they will handle remote attestation in virtualized machines (now that MS has entered the virtualization market).
I'd like that to happen, because SELinux is leaps and bounds ahead of the competition (meaning Windows and Macintosh, not grsecurity and friends), but I really don't know whether such a sophisticated access control system will fly in mainstream IT. The re-education campaign for developers and administrators would take a long time too, in part because the UNIX world is unaccustomed to the radical changes that Microsoft foists upon the world on a regular basis (backed with $$$).
That's a fair point. I doubt that there could ever be anything like jail under NT because the Win32 API is so much more complex than the UNIX API (pick one, any one!). With the current virtualization trend, some folk will probably use virtualization to get an effect that's similar to jail. Virtualization is bound to be less efficient, but might be good enough for many applications.
The NT derivatives' mechanisms are more sophisticated. The current implementations of those mechanisms have obviously had bugs and are very often misconfigured (yeah, having a buggy portmapper exposed to the world really would be a good idea) or used badly (IIS not taking advantage of process-level protection for performance reasons). As you point out this has caused huge problems and badly damaged Windows' reputation (quite deservedly). However, it looks to me like Windows' security could be fixed more easily over a few generations than UNIX's could.
Sorry, no MCSE, but I have been a UNIX systems programmer for 16 years and have spent some time looking at the NT kernel and using the Win32 security and crypto APIs. If you want to form your own opinion, try reading Keith Brown's book "Programming Windows Security".
It's not just about the filesystems, nor firewalls for that matter. The security mechanisms in the NT derivatives are considerably more sophisticated than those in traditional UNIX systems. There are some interesting mechanisms for Linux under development (Flask, etc.) but I doubt that many people are getting any benefit from them right now.
Isn't that just because you have created files consisting entirely of digits (so only containing bytes in the range 0x30 to 0x39), whereas catting/dev/urandom to/dev/dsp will use bytes over the entire range 0x00 to 0xff?
<unwarranted-sarcasm>
If that amuses you, try 0x70 to 0x7f. Or, you could be really cool and use 0xa5 to 0xb5 (don't tell anyone else though, it's top secret!).
</unwarranted-sarcasm>
You know that people have used genetic algorithms to improve some kinds of program? Probably nothing very complicated because the fitness tests would take far too long to run (perhaps the Timex 1000's operating system would be possible!). There was an article in Byte or Dr Dobbs about 10 years ago.
Arrays and pointers are distinct in C. It's the implicit coercion from array types to pointer types (in covariant contexts) and the ability to use the ".[.]" operator on both arrays and pointers that makes them look similar. But you can't use an array as an lvalue. Also a compiler has to emit very different code depending on whether an external object is an array or pointer.
If that's unclear, I'd recommend "C: A Reference Manual" by Harbison and Steele, and "Expert C Programming: Deep C Secrets" by Van Der Linden.
Sorry, you are wrong and the grandparent poster is correct. DTDs, XML Schema, and RELAX NG are all systems for describing families of XML documents. The grandparent poster is saying that one of the systems (RELAX NG) is superior to the other two. I'd agree with that assessment...
Validation is just checking that an XML document matches a specification, no matter whether the specification is written as a DTD, an XML Schema, or RELAX NG schema. It is not a separate issue at all.
I am going to college this fal, and was thinking about putting together a huge RAID (200+Gb), and then putting up an anonymous FTP for anyone to create (no delete) of files. Anyone have any advice on that?
What's the difference? I can't see why dynamic loading would require retokenizing/recompiling the source code.
Right, dynamic loading/linking doesn't involve the original source code. However, it does involve matching up identifiers and filling in offsets. Either the loader/linker has to match modulo case insensitivity, or all of the code-generation tools have to normalize identifiers. Others have pointed out that both tasks are a bit tricky for Unicode.
Slashdot Mirror
Even better, the pigeon-hole principle tells you that infinitely many different events will have the same picture.
But the key management problem is easier when you have fewer players and can impose more constraints...
But are you checking that you haven't been compromised by some other software-based keystroke logger, perhaps loaded into the kernel (or hardware-based keystroke loggers as suggested by an earlier poster)? If not, then you should be aware of the risk that you are taking in reacting to the attacks that are well publicized. You may find the risk acceptable for non-life-threatening applications such as online banking. Other people may not.
Yikes. Do you know whether the code is executed in the user's logon session or the system logon session?
The parent should be modded up. I'd add that you should be suspicious of key management carried out below the application layer. Even the submitter emphasizes the wrong point, IMNSHO, when he/she says that AES will be used to secure the connection. The choice of encryption algorithm is almost inconsequential because the world has plenty of good encryption algorithms, but the key management is the really difficult part. Designing a protocol is moderately difficult too (read Peter Gutmann's VPN rant to see some examples of poor protocols).
I wish O'Reilly would put it up on Safari!
I believe there was an Occam editor with folding support before Jamie Lokier wrote the Emacs folding mode.
Yes, NCA = Nexus Computing Application (or something to that effect). The MS documentation shows an NGSCB-enabled system in quadrants. The left-hand side is the normal stuff. The right-hand side is the new NGSCB stuff. Slashdot is not ASCII art friendly, but here goes:
The normal kernel does not have access to the (curtained?) memory on the right-hand side, otherwise rogue device drivers could compromise the system (of course, that might be what the person at the console wants...). The nexus manages right-hand side memory and provides other limited OS functionality to NCAs, including sealing and remote attestation using TCPA.
This is my reading of the documents at MS NGSCB and the Longhorn Platform SDK. It would be nice if any lurking NGSCB engineers could correct it.
Right, but in the Longhorn preview's version of NGSCB you would have to turn VMWare (or MS's version thereof) into an NCA or extend the Nexus. If the former, you would also need to fold the virtualized NCAs into the VMWare NCA to get around the memory isolation between NCAs.
I agree that virtualization is possible with the TCPA spec., but I don't see how to do it easily with the preview version of NGSCB. Perhaps MS will have redesigned it by the time Longhorn ships...
Watch out for patents held by Intel, Microsoft, etc.
There will be a keypair in tamper-resistant hardware produced by Intel. It's the "dump the private key" part that will be extremely difficult. Yes, if you could extract the private key, then you could emulate the behavior of the hardware, and Intel/Microsoft are perfectly aware of that.
It will be interesting to see how they handle revocation if a private key is ever compromised, and how they will handle remote attestation in virtualized machines (now that MS has entered the virtualization market).
I'd like that to happen, because SELinux is leaps and bounds ahead of the competition (meaning Windows and Macintosh, not grsecurity and friends), but I really don't know whether such a sophisticated access control system will fly in mainstream IT. The re-education campaign for developers and administrators would take a long time too, in part because the UNIX world is unaccustomed to the radical changes that Microsoft foists upon the world on a regular basis (backed with $$$).
Where is NT's jail?
That's a fair point. I doubt that there could ever be anything like jail under NT because the Win32 API is so much more complex than the UNIX API (pick one, any one!). With the current virtualization trend, some folk will probably use virtualization to get an effect that's similar to jail. Virtualization is bound to be less efficient, but might be good enough for many applications.
The NT derivatives' mechanisms are more sophisticated. The current implementations of those mechanisms have obviously had bugs and are very often misconfigured (yeah, having a buggy portmapper exposed to the world really would be a good idea) or used badly (IIS not taking advantage of process-level protection for performance reasons). As you point out this has caused huge problems and badly damaged Windows' reputation (quite deservedly). However, it looks to me like Windows' security could be fixed more easily over a few generations than UNIX's could.
Sorry, no MCSE, but I have been a UNIX systems programmer for 16 years and have spent some time looking at the NT kernel and using the Win32 security and crypto APIs. If you want to form your own opinion, try reading Keith Brown's book "Programming Windows Security".
It's not just about the filesystems, nor firewalls for that matter. The security mechanisms in the NT derivatives are considerably more sophisticated than those in traditional UNIX systems. There are some interesting mechanisms for Linux under development (Flask, etc.) but I doubt that many people are getting any benefit from them right now.
but it sounds different! try it you will see.
Isn't that just because you have created files consisting entirely of digits (so only containing bytes in the range 0x30 to 0x39), whereas catting /dev/urandom to /dev/dsp will use bytes over the entire range 0x00 to 0xff?
<unwarranted-sarcasm> If that amuses you, try 0x70 to 0x7f. Or, you could be really cool and use 0xa5 to 0xb5 (don't tell anyone else though, it's top secret!). </unwarranted-sarcasm>
You know that people have used genetic algorithms to improve some kinds of program? Probably nothing very complicated because the fitness tests would take far too long to run (perhaps the Timex 1000's operating system would be possible!). There was an article in Byte or Dr Dobbs about 10 years ago.
You are right, but harsh and unsympathetic to those that have lost their livelihood despite significant investments in their education.
Having said that, I'm not sure that I'll shed a tear when some of the other middle-class jobs outside of the tech industry move overseas too...
Arrays and pointers are distinct in C. It's the implicit coercion from array types to pointer types (in covariant contexts) and the ability to use the ".[.]" operator on both arrays and pointers that makes them look similar. But you can't use an array as an lvalue. Also a compiler has to emit very different code depending on whether an external object is an array or pointer.
If that's unclear, I'd recommend "C: A Reference Manual" by Harbison and Steele, and "Expert C Programming: Deep C Secrets" by Van Der Linden.
Christ, you let a support monkey muck around with your computer? I can feel a comp.risks post coming on...
Do you have a link to a place selling a Genesis to USB converter? I haven't had much luck finding one.
If you want to use "DTD" to mean that, that's your business. However, the rest of the world uses the term in the sense defined in the XML TR.
Sorry, you are wrong and the grandparent poster is correct. DTDs, XML Schema, and RELAX NG are all systems for describing families of XML documents. The grandparent poster is saying that one of the systems (RELAX NG) is superior to the other two. I'd agree with that assessment...
Validation is just checking that an XML document matches a specification, no matter whether the specification is written as a DTD, an XML Schema, or RELAX NG schema. It is not a separate issue at all.
Not planning to stay until Thanksgiving then? :-)
Right, dynamic loading/linking doesn't involve the original source code. However, it does involve matching up identifiers and filling in offsets. Either the loader/linker has to match modulo case insensitivity, or all of the code-generation tools have to normalize identifiers. Others have pointed out that both tasks are a bit tricky for Unicode.