How has the architecture changed to make it insecure? Not the implementation, but the design.
The architecture of the entire Windows NT operating system, not the NT kernel and executive, picked up huge whopping chunks of stupid from Win32 that more than make up for the improvements elsewhere. In particular, the horrendous remote security failures they brought over with Active Desktop make improvements in local security irrelevant.
If Microsoft wants to do something about NT security, the first thing they should do is completely rearchitect the HTML control and the inherently insecure "security zones" model.
NT's security architecture is at least as secure as standard UNIX's.
The NT kernel's design has all kinds of wonderful possibilities for building a secure OS around. I really wish Microsoft would do it.
The Win32 subsystem, however, is inherently insecure. And without the Win32 subsystem, NT is not a complete OS. Win32, includes not just the GUI but the equivalent of all the UNIX daemons and system services, and large parts of what in UNIX would be kernel modules. Take that out and you're left with less than the UNIX kernel.
If I were logged onto a NT workstation as a normal user and opened a virus the worst thing that can happen is my home directory will get deleted.
If you were logged on to an NT workstation as a normal user, first of all, you're more likely to be infected by a virus in the first place because the design of the Win32 subsystem practically invites them in. Secondly, there's a lot more opportunities for an application to boost security to Administrator or even LOCALSYSTEM: not only is the security model very complex, but you have to have all the rights any application you run is ever going to need. To top it all off, there's no hard "system call" interface between different security domains.
And UNIX has mechanisms to establish even stronger borders between protection domains. Even something as simple as chroot() provides a lot of protection, and there are UNIX systems with enhanced chroot()-like tools where it's possible for me to give you a shell account with root access and be confident that you can't compromise anything outside the hosted environment... or run a sniffer on my local LAN... and do it efficiently, without having to run a second copy of the kernel inside an emulator.
If I were logged into a UNIX workstation and opened a virus the worst that can happen is my home directory will get deleted.
No, the worst thing that could happen is that nothing in your home directory is obviously damaged, but a backdoor is created and hidden in your.login that lets someone piggyback in any time you're logged in, install a rootkit, and replace your kernel with one that contains an invisible backdoor they use to do something like attack other systems...
What you mean to say is that there's another layer of security that has to be bypassed after your account is 0wned before the system is 0wned. It's harder to break in if you hav eto do it twice.
The REAL problem in Windows is that it's so much easier to get infected by a virus. On most platforms you're pretty much restricted to social engineering attacks... I mean, until Melissa hit the idea of a mail program that even included a mechanism for a message to run scripts as the local user was a bad joke...
not running as root is just part of it. Even if you're not running as root, a virus can still trash your system or be used to proxy spam or attacks over the Internet.
The big difference with Windows is in the first stage, the infection. There are entire classes of security holes on Windows that don't exist on any other widely used operating system. Yes, any system can have a buffer overflow, but only Windows can suffer from a "cross zone attack", because only Windows tries to reconstruct the rights an object should have based only on its URL.
Depends on the software. Big enterprise software packages involve things like dedicated staff from the software vendor working 9-5 at the customer site, full time, because the software is doing something big and complex (like running the company's books) and if it's down (no matter who's at fault) you're leaking megabucks until it comes up again.
The Caucho license is even more restrictive than the old no-commercial-use licenses. I don't see how it's an improvement over things like the Kermit license... which predates most of the open source licenses including the GPL, allows more freedom than the Caucho license, and has been funding full-time development of Kermit for almost 20 years.
SAP's already open-sourced their database software. The big bucks for SAP isn't in selling software, it's going in and SAPifying businesses for $big$bux$.
There's no way they'd make a Treo running Pocket PC Phone Edition: the Pocket PC GUI is far too limiting... there's no way Microsoft would have let them use the keyboard replacing 1/3 of the touchscreen in a Pocket PC, and the "Stinger" smartphones aren't in the same market. I could see them producing "Stinger" phones, but they can't replace Palm OS with that.
Agreed, the Treo is a tremendously popular unit, and its sales are simply not being counted.
True, the "Pocket PC Phone Edition" is also left out... but I've used one of those and can't believe they've got any significant market share. The mismatch between the OS/GUI and what a phone needs is unreal.
Re:This is one reason apple has failed...
on
NeXTSTEP To Mac OS X
·
· Score: 2, Informative
They did. I have a Mac SE/30 (1989) running A/UX, Apple's first UNIX. The stumbling block for A/UX was the same as the early releases of what came to be OSX: classic Mac/OS emulation. A/UX runs Mac OS 6 under emulation, kind of like the Classic subsystem in OSX, and performance on even a 68030 (which was a pretty fast chip at the time) was lousy.
NeXT, running what became Cocoa, was zippier on a 68030 than either OS9 or OSX on the first generation Powermacs. If they could have shipped Rhapsody for the desktop it wuld have kicked OS9's behind... unfortunately, their developers more or less forced them to hold it back until they had good MacOS emulation (Classic) and a good dual-OS runtime (Carbon), and... well... I booted OSX on a 180 MHz Powermac 7600 and it was far far slower than NeXTstep on my Nexstation. The OS install took a full day to complete...
It's a real shame Apple didn't join the fight over Lorraine (what became the Amiga). The Amiga Exec was a high performance microkernel and with Apple's GUI people handling the user interface it could have been a killer combo.
Tcl is great for throwing these things together, and Tk one of the more platform-independent GUI frameworks. That script should run the same on Windows, Mac OS X under native Aqua or X11, or on any other X11/Unix combo.
And it's not a lot of code.
Have a look at something I created as a display tool for sticking on the end of a pipeline that's twiddling password-style files: viewdb.
the obvious and commonly used GUI counterparts to wc -- many of which are considerably more interesting
Can you use them to count the words added to a file every five minutes, to count the words ONLY on the lines beginning with "IMPORTANT", to count the number of words past the 40th character on long lines, to count the number of words in the ID3 titles in your iTunes Music folder,...
the finest and most satisfying way to count words (if wc's answer is good enough) is to use wc... from vim.
Heretic. Luckily the nvi from Jaguar runs on Panther.
Regardless of where it's implemented, the same work needs to be done, and for the same objects. Apple appears to be doing it in HFS+. All I was saying is "why not do it above the file system, so it's not restricted to HFS+?"...
In the context of this discussion, the extra logic for this would need to be performed conditionally for all block write activity.
I don't believe that's the case. The daemon doesn't need to know about every write, it only needs to know about events that require it to update its database, and it doesn't even need that to be very fine-grained. At the very most it would need to be done when the hierarchy is modified (that is, on operations like creat(), link(), unlink(), or rename()), and when a vnode is moved from the dirty to the clean list or vice versa.
Alpha? I though you wanted "next generation" chips, not chips from yesteryear.
When the rest of the instruction sets out there are based on designs released in the '80s (and in one case, the '70s) as their basis, one from 1992 certainly qualifies as "next generation".
Alpha was the last of the from-scratch RISC designs, and learned a lot from previous generations' successes and failures.
I do agree that a major part of it is that IE is still so common so it's an easier target
I don't think that's a big part of the problem, except for Microsoft. It shouldn't be a problem for the users... Microsoft has known that they were a high profile target for a long time, and has completely failed to even consider adopting a security model that's appropriate for the situation.
Let's look at the real problem. It's not just that the HTML control is integrated into so many applications (including, of course, Windows Explorer), it's the WAY its integrated that's the problem.
The HTML control is just trying to do too much.
1. The HTML control, not the application calling it, is the party responsible for deciding what the behaviour of an object its displaying is.
2. The HTML control is used by components that display objects that must be granted full local user access to work.
3. To allow applications dealing with untrusted objects (IE, Outlook, etc) and applications dealing with trusted objects (Windows Explorer, Windows Update, etc) both to call the HTML control, Microsoft developed this idea of "security zones".
4. The security zone an object is in was originally based on its URL. If the object was local to the computer, or accessed via trusted protocols (eg, CIFS), or on a server that was trusted (either in a list or because it could provide a certificate that said it was trusted), or if the object itself could provide an appropriate certificate, then it was trusted.
A more logical mechanism for integrating IE with the desktop would have been something like this:
1. Create multiple controls, each of which performs some portion of the job. These controls include the HTML rendering engine and the HTTP access engine.
2. When an application opens the HTML rendering control, it provides it with a set of object access and embedding controls it should use for the object. It could provide callbacks into itself for fine control, or entry points to other controls, or other applications, or even scripts.
3. When an object presents the browser with a script, and embedded object, or hyperlink, the browser would pass that to the control registered for that action.
With this design, Windows Explorer could provide controls that granted the object full local access, but called out to Internet Explorer for remote access. Internet Explorer or Outlook would only provide fully sandboxed applets and secure scripting languages. There wouldn't be a mechanism known to the HTML renderer for a VBscript in an email message, or a link to a PIF file, or any of the other tricks used by exploits to sneak untrusted data into the "trusted zone". It wouldn't know about any "trusted zone": if such a thing were needed it would be managed at a different level than the rendering engine, in controls that could be, carefully, added by a specific application where special capabilities were required.
Windows update, for example, would be an application that used the html control but used an HTTP control that only allowed access to signed content on Microsoft's servers...
If Microsoft did this, and the design held up, I would be more than happy to use and recommend Outlook and IE.
I assume you're talking about file://///server/share links, not smb://server/share links? The mapping from UNC paths to URLs is, well, pretty much ad-hoc even in IE. What combination of// and \\ are you using? Maybe you can find something that will work both places.
I can understand where this could be a security issue, too, but I haven't found a specific reference to it in bugzilla, or through google. Can you provide some links?
If Intel would come up with a replacemenet architecture for the x86 that was a credible alternative, they could do it.
Here's what they've tried so far:
iAPX432: arguably the CISC of CISCs. Out-VAXED the VAX, the only instruction set more complex was one of the Japanese TRON designs.
i960: this one had a chance, it was a fairly conventional RISC with good performance, but it was too early. Intel was still enamored with the x86 architecture, and it got stripped of its MMU and shunted into embedded systems lest it compete with the x86.
i860: Baroque RISC variant that forced the compiler to do an incredible amount of work to get decent performance. Kind of a trial balloon for the IA64.
IA64: Even more baroque RISC/VLIW blend, instructions are basically RISC-like, but bundled together in wide instructions. Again, the compiler has to be insanely great. There are some insanely great compilers for it now, we'll see...
XScale: take the DEC StrongARM and give it the Intel touch: long pipelines, heavy dependency on the compiler, the 400 MHz XScale was not a lot faster than the 206 MHz StrongARM. It's still got a shot of taking market share away from x86 at the low end, except that other companies like VIA and Transmeta are waiting to take that on if Intel really starts trying to push.
If they really wanted to wean themselves from the x86 they'd have kept the Alpha EV8 team working on the Alpha, release it as the Intel AXP Architecture, and pretty soon people will forget that it's not their design.
I don't think Intel's managers really want to wean the company from the x86. They say they do, and may believe it, but their actions don't show it.
So, really, Spotlight isn't something specific to HFS+, but it currently only supports HFS+.
Which brings us back to the original question: is it limited to HFS+ because it's implemented in the HFS+ code (and other filesystems would have to be modified to do the same thing), or because it's just not turned on for anything but HFS+ but is still implemented at the vnode layer?
Because that's the only thing I could be 100% wrong about here, that's the only part of what I've said that the previous poster actually contradicted.
I don't think Apple has released the source for Tiger's kernel yet, or I'd check darwin.apple.com and see.
Go back and read my first message in this thread. The one where I said that the only thing you need in the kernel is a hook at the vnode layer to send efficient high-speed messages to a daemon IN USERLAND.
Almost any application can have buffer overflows in it. On the other hand... this isn't the kind of bug we really need worry about. Microsoft (or Mozilla.org, god forbid) can fix buffer overflows easily without breaking applications that depend on them. It's the deeper security flaws in the HTML control that we ned to worry about.
Slashdot Mirror
How has the architecture changed to make it insecure? Not the implementation, but the design.
The architecture of the entire Windows NT operating system, not the NT kernel and executive, picked up huge whopping chunks of stupid from Win32 that more than make up for the improvements elsewhere. In particular, the horrendous remote security failures they brought over with Active Desktop make improvements in local security irrelevant.
If Microsoft wants to do something about NT security, the first thing they should do is completely rearchitect the HTML control and the inherently insecure "security zones" model.
NT's security architecture is at least as secure as standard UNIX's.
The NT kernel's design has all kinds of wonderful possibilities for building a secure OS around. I really wish Microsoft would do it.
The Win32 subsystem, however, is inherently insecure. And without the Win32 subsystem, NT is not a complete OS. Win32, includes not just the GUI but the equivalent of all the UNIX daemons and system services, and large parts of what in UNIX would be kernel modules. Take that out and you're left with less than the UNIX kernel.
If I were logged onto a NT workstation as a normal user and opened a virus the worst thing that can happen is my home directory will get deleted.
If you were logged on to an NT workstation as a normal user, first of all, you're more likely to be infected by a virus in the first place because the design of the Win32 subsystem practically invites them in. Secondly, there's a lot more opportunities for an application to boost security to Administrator or even LOCALSYSTEM: not only is the security model very complex, but you have to have all the rights any application you run is ever going to need. To top it all off, there's no hard "system call" interface between different security domains.
And UNIX has mechanisms to establish even stronger borders between protection domains. Even something as simple as chroot() provides a lot of protection, and there are UNIX systems with enhanced chroot()-like tools where it's possible for me to give you a shell account with root access and be confident that you can't compromise anything outside the hosted environment... or run a sniffer on my local LAN... and do it efficiently, without having to run a second copy of the kernel inside an emulator.
If I were logged into a UNIX workstation and opened a virus the worst that can happen is my home directory will get deleted.
.login that lets someone piggyback in any time you're logged in, install a rootkit, and replace your kernel with one that contains an invisible backdoor they use to do something like attack other systems...
No, the worst thing that could happen is that nothing in your home directory is obviously damaged, but a backdoor is created and hidden in your
What you mean to say is that there's another layer of security that has to be bypassed after your account is 0wned before the system is 0wned. It's harder to break in if you hav eto do it twice.
The REAL problem in Windows is that it's so much easier to get infected by a virus. On most platforms you're pretty much restricted to social engineering attacks... I mean, until Melissa hit the idea of a mail program that even included a mechanism for a message to run scripts as the local user was a bad joke...
not running as root is just part of it. Even if you're not running as root, a virus can still trash your system or be used to proxy spam or attacks over the Internet.
The big difference with Windows is in the first stage, the infection. There are entire classes of security holes on Windows that don't exist on any other widely used operating system. Yes, any system can have a buffer overflow, but only Windows can suffer from a "cross zone attack", because only Windows tries to reconstruct the rights an object should have based only on its URL.
A good peice of software won't need support.
Depends on the software. Big enterprise software packages involve things like dedicated staff from the software vendor working 9-5 at the customer site, full time, because the software is doing something big and complex (like running the company's books) and if it's down (no matter who's at fault) you're leaking megabucks until it comes up again.
The Caucho license is even more restrictive than the old no-commercial-use licenses. I don't see how it's an improvement over things like the Kermit license... which predates most of the open source licenses including the GPL, allows more freedom than the Caucho license, and has been funding full-time development of Kermit for almost 20 years.
Point 3 is simply not going to happen.
SAP's already open-sourced their database software. The big bucks for SAP isn't in selling software, it's going in and SAPifying businesses for $big$bux$.
If Handspring switched to a Symbian OS, then that wouldn't help the Microsoft numbers any, now would it?
There's no way they'd make a Treo running Pocket PC Phone Edition: the Pocket PC GUI is far too limiting... there's no way Microsoft would have let them use the keyboard replacing 1/3 of the touchscreen in a Pocket PC, and the "Stinger" smartphones aren't in the same market. I could see them producing "Stinger" phones, but they can't replace Palm OS with that.
Agreed, the Treo is a tremendously popular unit, and its sales are simply not being counted.
True, the "Pocket PC Phone Edition" is also left out... but I've used one of those and can't believe they've got any significant market share. The mismatch between the OS/GUI and what a phone needs is unreal.
They did. I have a Mac SE/30 (1989) running A/UX, Apple's first UNIX. The stumbling block for A/UX was the same as the early releases of what came to be OSX: classic Mac/OS emulation. A/UX runs Mac OS 6 under emulation, kind of like the Classic subsystem in OSX, and performance on even a 68030 (which was a pretty fast chip at the time) was lousy.
NeXT, running what became Cocoa, was zippier on a 68030 than either OS9 or OSX on the first generation Powermacs. If they could have shipped Rhapsody for the desktop it wuld have kicked OS9's behind... unfortunately, their developers more or less forced them to hold it back until they had good MacOS emulation (Classic) and a good dual-OS runtime (Carbon), and... well... I booted OSX on a 180 MHz Powermac 7600 and it was far far slower than NeXTstep on my Nexstation. The OS install took a full day to complete...
It's a real shame Apple didn't join the fight over Lorraine (what became the Amiga). The Amiga Exec was a high performance microkernel and with Apple's GUI people handling the user interface it could have been a killer combo.
Tcl is great for throwing these things together, and Tk one of the more platform-independent GUI frameworks. That script should run the same on Windows, Mac OS X under native Aqua or X11, or on any other X11/Unix combo.
And it's not a lot of code.
Have a look at something I created as a display tool for sticking on the end of a pipeline that's twiddling password-style files: viewdb.
the obvious and commonly used GUI counterparts to wc -- many of which are considerably more interesting
...
Can you use them to count the words added to a file every five minutes, to count the words ONLY on the lines beginning with "IMPORTANT", to count the number of words past the 40th character on long lines, to count the number of words in the ID3 titles in your iTunes Music folder,
the finest and most satisfying way to count words (if wc's answer is good enough) is to use wc... from vim.
Heretic. Luckily the nvi from Jaguar runs on Panther.
Regardless of where it's implemented, the same work needs to be done, and for the same objects. Apple appears to be doing it in HFS+. All I was saying is "why not do it above the file system, so it's not restricted to HFS+?"...
In the context of this discussion, the extra logic for this would need to be performed conditionally for all block write activity.
I don't believe that's the case. The daemon doesn't need to know about every write, it only needs to know about events that require it to update its database, and it doesn't even need that to be very fine-grained. At the very most it would need to be done when the hierarchy is modified (that is, on operations like creat(), link(), unlink(), or rename()), and when a vnode is moved from the dirty to the clean list or vice versa.
I think these vnode ops would need to be tracked:
VOP_CREATE, VOP_MKNOD, VOP_REMOVE, VOP_LINK, VOP_RENAME, VOP_MKDIR, VOP_RMDIR.
Any other changes to the vnode are already tracked by the dirty/flush mechanism.
Actually... the Alpha's design philosophy lived on in the Pentium 4 - higher clock speeds.
EVERYONE wants higher clock speeds. The Alpha design let them have high clock speeds without deep pipelines.
Pentium III - 12 stage pipeline
Pentium 4 - ~30 stage pipeline (20 stages exposed)
Alpha EV7 - 7 stage pipeline.
Alpha EV8 (cancelled) - 9 stage pipeline.
what's wrong with x86? And x86-64?
About 16 or so pipeline stages.
Alpha? I though you wanted "next generation" chips, not chips from yesteryear.
When the rest of the instruction sets out there are based on designs released in the '80s (and in one case, the '70s) as their basis, one from 1992 certainly qualifies as "next generation".
Alpha was the last of the from-scratch RISC designs, and learned a lot from previous generations' successes and failures.
I do agree that a major part of it is that IE is still so common so it's an easier target
I don't think that's a big part of the problem, except for Microsoft. It shouldn't be a problem for the users... Microsoft has known that they were a high profile target for a long time, and has completely failed to even consider adopting a security model that's appropriate for the situation.
Let's look at the real problem. It's not just that the HTML control is integrated into so many applications (including, of course, Windows Explorer), it's the WAY its integrated that's the problem.
The HTML control is just trying to do too much.
1. The HTML control, not the application calling it, is the party responsible for deciding what the behaviour of an object its displaying is.
2. The HTML control is used by components that display objects that must be granted full local user access to work.
3. To allow applications dealing with untrusted objects (IE, Outlook, etc) and applications dealing with trusted objects (Windows Explorer, Windows Update, etc) both to call the HTML control, Microsoft developed this idea of "security zones".
4. The security zone an object is in was originally based on its URL. If the object was local to the computer, or accessed via trusted protocols (eg, CIFS), or on a server that was trusted (either in a list or because it could provide a certificate that said it was trusted), or if the object itself could provide an appropriate certificate, then it was trusted.
A more logical mechanism for integrating IE with the desktop would have been something like this:
1. Create multiple controls, each of which performs some portion of the job. These controls include the HTML rendering engine and the HTTP access engine.
2. When an application opens the HTML rendering control, it provides it with a set of object access and embedding controls it should use for the object. It could provide callbacks into itself for fine control, or entry points to other controls, or other applications, or even scripts.
3. When an object presents the browser with a script, and embedded object, or hyperlink, the browser would pass that to the control registered for that action.
With this design, Windows Explorer could provide controls that granted the object full local access, but called out to Internet Explorer for remote access. Internet Explorer or Outlook would only provide fully sandboxed applets and secure scripting languages. There wouldn't be a mechanism known to the HTML renderer for a VBscript in an email message, or a link to a PIF file, or any of the other tricks used by exploits to sneak untrusted data into the "trusted zone". It wouldn't know about any "trusted zone": if such a thing were needed it would be managed at a different level than the rendering engine, in controls that could be, carefully, added by a specific application where special capabilities were required.
Windows update, for example, would be an application that used the html control but used an HTTP control that only allowed access to signed content on Microsoft's servers...
If Microsoft did this, and the design held up, I would be more than happy to use and recommend Outlook and IE.
I assume you're talking about file://///server/share links, not smb://server/share links? The mapping from UNC paths to URLs is, well, pretty much ad-hoc even in IE. What combination of // and \\ are you using? Maybe you can find something that will work both places.
I can understand where this could be a security issue, too, but I haven't found a specific reference to it in bugzilla, or through google. Can you provide some links?
If Intel would come up with a replacemenet architecture for the x86 that was a credible alternative, they could do it.
Here's what they've tried so far:
iAPX432: arguably the CISC of CISCs. Out-VAXED the VAX, the only instruction set more complex was one of the Japanese TRON designs.
i960: this one had a chance, it was a fairly conventional RISC with good performance, but it was too early. Intel was still enamored with the x86 architecture, and it got stripped of its MMU and shunted into embedded systems lest it compete with the x86.
i860: Baroque RISC variant that forced the compiler to do an incredible amount of work to get decent performance. Kind of a trial balloon for the IA64.
IA64: Even more baroque RISC/VLIW blend, instructions are basically RISC-like, but bundled together in wide instructions. Again, the compiler has to be insanely great. There are some insanely great compilers for it now, we'll see...
XScale: take the DEC StrongARM and give it the Intel touch: long pipelines, heavy dependency on the compiler, the 400 MHz XScale was not a lot faster than the 206 MHz StrongARM. It's still got a shot of taking market share away from x86 at the low end, except that other companies like VIA and Transmeta are waiting to take that on if Intel really starts trying to push.
If they really wanted to wean themselves from the x86 they'd have kept the Alpha EV8 team working on the Alpha, release it as the Intel AXP Architecture, and pretty soon people will forget that it's not their design.
I don't think Intel's managers really want to wean the company from the x86. They say they do, and may believe it, but their actions don't show it.
So, really, Spotlight isn't something specific to HFS+, but it currently only supports HFS+.
Which brings us back to the original question: is it limited to HFS+ because it's implemented in the HFS+ code (and other filesystems would have to be modified to do the same thing), or because it's just not turned on for anything but HFS+ but is still implemented at the vnode layer?
Because that's the only thing I could be 100% wrong about here, that's the only part of what I've said that the previous poster actually contradicted.
I don't think Apple has released the source for Tiger's kernel yet, or I'd check darwin.apple.com and see.
You know, some days I just want to scream.
Go back and read my first message in this thread. The one where I said that the only thing you need in the kernel is a hook at the vnode layer to send efficient high-speed messages to a daemon IN USERLAND.
Sheesh.
Dave. What are you doing, Dave. Put down those Windows XP install disks, Dave.
You're not IBM-compatible, HAL
Almost any application can have buffer overflows in it. On the other hand... this isn't the kind of bug we really need worry about. Microsoft (or Mozilla.org, god forbid) can fix buffer overflows easily without breaking applications that depend on them. It's the deeper security flaws in the HTML control that we ned to worry about.
Absolut Conservative
[I don't want to go into what would be in the vodka bottle]