Microsoft has been attempting to get the scheme you're proposing working since 1997, and they're only trying to do it for a *subset* of the domain you're talking about. When they implemented it in the first place they did such a bad job that they created the worst storm of viruses and email worms the net had ever seen. Over a couple of years the number of active exploits of Microsoft's trust model turned viruses from a minor problem that you could easily avoid by a few simple habits to the biggest problem on the net... I'm seeing gigabytes of just rejected viruses and worms a month.
Nope, they try something different: They try to implement a zone model. On the first glance, this looks quite similar, but there is a big difference. Their zone model is insecure by default. When Internet Explorer looses track on a file downloaded from the net, this file becomes member of the local zone and is suddenly considered trustworthy. With a "secure by default" approach, a zone model could possibly work.
But it is quite interesting, that Active X is somewhat similar to the safe application model. In Active X components can be marked as safe for scripting. Such components can be embedded in IE and controlled by script code. Numerous exploits based on the fact, that unsafe components were marked as safe for scripting. Without some kind of online "trustworthy revocation list" the secure application idea will only work in a perfect world.
The IE zone model also shows, that there is indeed no border between applications and documents. One can easily create a HTML with active code. Although this page should be a document, it is indeed a program. When you save such a page, you have a ticking time bomb on your system. When you open the page from your local disc, the page is "executed" with your user privileges. It's not the application that is not trustworthy, it's indeed the document.
I don't want to have a full blown rigorous mandatory access control (MAC)security model on my Mac. I have some work to do and don't want to struggle with the system. GRSecurity and SELinux show how difficult these monsters are to configure, especially on a desktop system. But I want a lightweight, extensible mixture of a MAC and a zone model that warns me when I try to do something stupid. The system should interact with most of the existing tools, should be easy to understand and should let the user the last word. I think that extensible attributes with some simple rules built into the system might indeed fulfill the job. It's not a perfect tool, but it might help.
And having to mark every file as "safe" before it could be run every time it's edited wouldn't be inconvenient?
That's the nice thing about arbitrary attributes: You can just add some more attributes to define exceptions and refine the scheme. There are two possible solutions:
Remember which program created that file and allow the same program to open the file again. For this, you must just add an additional attribute to the file. Like the "trusted" attribute, this attribute must be tied to the system, e.g. by using digital signatures or adding an unique id to the name.
Add an attribute to the program so every file created with that program is safe by default. I don't like this one, because it breaks the "safe by default" aspect. But this might be nice for development tools --- something generated by development tools on the local computer would just be marked trustworthy by the system.
Of course, one could also bundle applications to suites, that can open each others files. There would be an internet suite, an office suite, a system tools suite, a developer suite and so on. Then the system would warn you, if you try to open an office document created by an program of the internet suite --- this warning is inconvenient but absolutely necessary.
The last two exploits of this kind didn't involve applications that normally run scripts. They involved a help viewer and a manual page viewer. Since these applications are viewers, they wouldn't have checked, and the exploits would still have worked.
Fair enough, my proposal won't stop such exploits in the first place. But when adding some kind of "trustworthy revocation list" such an security hole could be fixed in about 15 minutes. When a safe application has a security hole, just don't consider it trustworthy any more until it becomes patched. Your system becomes secure again, you can still use that application, but using it becomes a bit more inconvenient because the system might warn you from time to time.
It's also one that I've seen people attempt to implement on systems with discretionary access control (like UNIX, Windows, and every other commonly used OS) and failed. It requires a system with mandatory access controls... an "Orange book" B or A class system. There are very few of these implemented, and they are rarely used by anyone outside the military because they're VERY difficult to get right and impose a huge amount of inconvenience.
Yep, you got me on this one. I had MAC in mind. Building such a system provable secure is indeed very complicated and for most real applications nearly impossible. But one can use these ideas to build a system that is almost secure. Better, one buid a system where security holes can be easily fixed. It's important to avoid security holes in the first place, but it is also important to make it very easy to fix security holes. And last but not least: Security must be as convenient as possible or the user will circumvent the security measures.
Thanks for the nice discussion, you helped me to refine these ideas!
Applications are safe, or not safe. Safe applications assume that ALL documents are untrusted, and only pass documents to other safe applications (for example, as plugins).
This would either be very inconvenient or it would need a very savvy user. I want to be able to open scripts in the terminal. But the system should warn me, when I erroneously try to open a script loaded from the net. Whith the concept of "safe applications" this is either not possible or I must carefully examine each script, before clicking it. There is no way to tell the systems, which scripts to run and when to refuse to run the script. Using the concept of safe documents, this is easily possible. The differentiation between documents and programs becomes somewhat artificial with scripts and macros. Therefore I am convinced the concept of safe applications won't work. The concept of safe documents has some advantages:
It is safe by default, because every foreign document is considered unsafe and modified documents become automatically unsafe
It is convenient because the user has the last word. The user can any time override the default and mark an arbitrary document as safe.
It is robust, because documents preserve their state when they are moved around on the local system.
The problem is dug very deep in Mac OS X: One does not know if one can trust a certain file or not. A patch for the current security hole is easy, but won't solve the real problem.
On Mac OS (9 and X) a file can have an arbitrary icon and type, independent from its name. Some systems use the filename to guess type and icon. On Mac OS this information is stored as separate data, in a so called ressource fork. So one could create a file "some_file.xls" that is a text-file and has the icon of photoshop. Or one could create a file "celebrity_naked.jpg" that is indeed a program and has the icon of the preview application --- or worse whose icon shows a naked person. Even when there is no security hole, the user might eventually try to open this file. With the current security hole this step can be skipped --- the browser will open it automatically.
Mac OS X needs a way to mark a file as trustworthy. When a file is not marked this way, several dangerous operation will be disabled and the file must be marked in a certain way in the file browser (Finder, open dialogue, etc.). I think the Finder should have an extra check box in the file info dialogue: "This file is trustworthy". Terminal, Help Viewer and other easily exploitable application should refuse to open a non-trustworthy file. And this files should be viewed with a big red explanation mark on their icon --- at least when they can be opened with a dangerous application. So the user can easily see, that these files are a potential threat. Of course, per default only the system files are marked trustworthy.
An easy way to implement such a "trustworthy" flag would be extended POSIX attributes. On Mac OS X 10.4 every file can have an arbitrary number of these attributes. I suggest the following scheme: A file is only trustworthy, when it has a certain attribute. The name of the attribute depends on the user, its value is a digital signature of the file; e.g. name="trustworthy:34833066-DC6A-459F-8462-7100E84A D100" value="Here comes the signature...". Additionally there are some virtual accounts for the machine and the administrator. When they trust the file, every user on the machine or the domain implicitly trust the file too. This scheme has several advantages:
Several users on the same machine can decide for their own, whether they trust the file or not
The attributes are preserved when the file is moved or hard-linked.
A freshly downloaded file is never trustworthy
A changed file is never trustworthy
All other programs can simply ignore the extended atributes
But let's say you put in your resignation, then backdoored their network on your way out because they didn't cut off your access until two weeks later. This time when the Powers That Be come looking for blood, your boss is SOL: he could try saying "well, we had no idea he was bent..." but the shareholders are just going to respond "He had just turned in his resignation! He was on his way out the door! Why did he still have access?" And your boss becomes the next one on the chopping block, and depending on the nature of the business possibly liable for fines as well.
This argument contains an implicit premise. It took me some time to get it: "If you are not fully commited, you are considered an enemy." It looks like most other readers didn't stumle over this premise. I think this attitude must be somehow special for America.
You can find more infomrations on pro-linux and heise (both german).
A short summary of the German texts: The notebooks will be shipped with FreeDOS pre-installed and a Ubuntu installation CD. Only the kernel on the Ubuntu CD will be modified: it contains HP specific patches to supports all features of the notebook, including full ACPI support, accelerated 3D graphics and two monitors. The rest of the distribution remains unmodified, you can update from the usual Ubuntu sources.
I think that anyone who is considering buying a PC for Lindows would be much better served buying a Mac or Mac Mini and using OS X instead.
Or he could buy one of these fancy HP notebooks that will ship with Ubuntu. Rumors say, HP develops a special Ubuntu version, that will support the complete hardware of these notebooks, including ACPI Suspend to RAM.
Ubuntu has a security model that is similar to Mac OS X. Root cannot login; when root privileges are required, sudo will be used.
In fact, you will see yellow light in many clean rooms. Blue light can interfer with chipm aking process, so you can only use the green and red spectrum of the light. And green and read appears as yellow to the eye.
The yellow light is not a problem, you get used of it within minutes. Then yellow will appear as white to you. But beware when you leave the clean room - everything will look quite funny until your eye recalibrates.
It's easy to connet Asterisk to your Telco's line. Just use a standard ISDN-Card or a modem. To connect your internal devices is a little bit more tricky. You can find appropiate hardware on http://www.digium.com/ or http://www.junghanns.net/.
Background: You can't connect two ISDN devices or two modems with some kind of cross cable witout some additional tricks. To drive analog phones, you need a modem card with FXS support, for ISDN telephones, the card must support the NT-mode. E.g. the Junghanns QuadBRI card support NT and can drive up to 4 ISDN lines. The Wildcard TDM400P supports FXS can drive four analog devices. Both run fine with Asterisk.
If you are in a country you don't speak the language of, you have to point at the things you want (*). It's the same with visual programing. It makes it easy for newbies, because they can simply point at the things they want. But you might slightly more productive, when you can simply tell what you mean. When things become more complex, pointing at things comes to its limits.
*) Just like me. I've learnt English at school, but my grammer is sometimes quite strange.
The difference between Java and Mono is not a technical one in the first place. Both are modern platforms with a JIT compiler and a prefered OO language. Both run on multiple platforms and for bioth are multiple languages available.
The problem is more a political one. On Mono, future language extensions are dictated by Microsoft. The Mono developers could of course extend their VM in any way they want. But they would loose compatibility with Windows.
If you want to try X.org on debian, just add Ubuntu to your sources.list (details here) and intall the packet xserver-xorg.
You could also compile it from source and install it under/usr/local/ (details here)
Slashdot Mirror
Nope, they try something different: They try to implement a zone model. On the first glance, this looks quite similar, but there is a big difference. Their zone model is insecure by default. When Internet Explorer looses track on a file downloaded from the net, this file becomes member of the local zone and is suddenly considered trustworthy. With a "secure by default" approach, a zone model could possibly work.
But it is quite interesting, that Active X is somewhat similar to the safe application model. In Active X components can be marked as safe for scripting. Such components can be embedded in IE and controlled by script code. Numerous exploits based on the fact, that unsafe components were marked as safe for scripting. Without some kind of online "trustworthy revocation list" the secure application idea will only work in a perfect world.
The IE zone model also shows, that there is indeed no border between applications and documents. One can easily create a HTML with active code. Although this page should be a document, it is indeed a program. When you save such a page, you have a ticking time bomb on your system. When you open the page from your local disc, the page is "executed" with your user privileges. It's not the application that is not trustworthy, it's indeed the document.
I don't want to have a full blown rigorous mandatory access control (MAC)security model on my Mac. I have some work to do and don't want to struggle with the system. GRSecurity and SELinux show how difficult these monsters are to configure, especially on a desktop system. But I want a lightweight, extensible mixture of a MAC and a zone model that warns me when I try to do something stupid. The system should interact with most of the existing tools, should be easy to understand and should let the user the last word. I think that extensible attributes with some simple rules built into the system might indeed fulfill the job. It's not a perfect tool, but it might help.
That's the nice thing about arbitrary attributes: You can just add some more attributes to define exceptions and refine the scheme. There are two possible solutions:
Of course, one could also bundle applications to suites, that can open each others files. There would be an internet suite, an office suite, a system tools suite, a developer suite and so on. Then the system would warn you, if you try to open an office document created by an program of the internet suite --- this warning is inconvenient but absolutely necessary.
Fair enough, my proposal won't stop such exploits in the first place. But when adding some kind of "trustworthy revocation list" such an security hole could be fixed in about 15 minutes. When a safe application has a security hole, just don't consider it trustworthy any more until it becomes patched. Your system becomes secure again, you can still use that application, but using it becomes a bit more inconvenient because the system might warn you from time to time.
Yep, you got me on this one. I had MAC in mind. Building such a system provable secure is indeed very complicated and for most real applications nearly impossible. But one can use these ideas to build a system that is almost secure. Better, one buid a system where security holes can be easily fixed. It's important to avoid security holes in the first place, but it is also important to make it very easy to fix security holes. And last but not least: Security must be as convenient as possible or the user will circumvent the security measures.
Thanks for the nice discussion, you helped me to refine these ideas!
This would either be very inconvenient or it would need a very savvy user. I want to be able to open scripts in the terminal. But the system should warn me, when I erroneously try to open a script loaded from the net. Whith the concept of "safe applications" this is either not possible or I must carefully examine each script, before clicking it. There is no way to tell the systems, which scripts to run and when to refuse to run the script. Using the concept of safe documents, this is easily possible. The differentiation between documents and programs becomes somewhat artificial with scripts and macros. Therefore I am convinced the concept of safe applications won't work.
The concept of safe documents has some advantages:
The problem is dug very deep in Mac OS X: One does not know if one can trust a certain file or not. A patch for the current security hole is easy, but won't solve the real problem.
On Mac OS (9 and X) a file can have an arbitrary icon and type, independent from its name. Some systems use the filename to guess type and icon. On Mac OS this information is stored as separate data, in a so called ressource fork. So one could create a file "some_file.xls" that is a text-file and has the icon of photoshop. Or one could create a file "celebrity_naked.jpg" that is indeed a program and has the icon of the preview application --- or worse whose icon shows a naked person. Even when there is no security hole, the user might eventually try to open this file. With the current security hole this step can be skipped --- the browser will open it automatically.
Mac OS X needs a way to mark a file as trustworthy. When a file is not marked this way, several dangerous operation will be disabled and the file must be marked in a certain way in the file browser (Finder, open dialogue, etc.). I think the Finder should have an extra check box in the file info dialogue: "This file is trustworthy". Terminal, Help Viewer and other easily exploitable application should refuse to open a non-trustworthy file. And this files should be viewed with a big red explanation mark on their icon --- at least when they can be opened with a dangerous application. So the user can easily see, that these files are a potential threat. Of course, per default only the system files are marked trustworthy.
An easy way to implement such a "trustworthy" flag would be extended POSIX attributes. On Mac OS X 10.4 every file can have an arbitrary number of these attributes. I suggest the following scheme: A file is only trustworthy, when it has a certain attribute. The name of the attribute depends on the user, its value is a digital signature of the file; e.g. name="trustworthy:34833066-DC6A-459F-8462-7100E84A D100" value="Here comes the signature...". Additionally there are some virtual accounts for the machine and the administrator. When they trust the file, every user on the machine or the domain implicitly trust the file too. This scheme has several advantages:
This argument contains an implicit premise. It took me some time to get it: "If you are not fully commited, you are considered an enemy." It looks like most other readers didn't stumle over this premise. I think this attitude must be somehow special for America.
Geggo
I'm the first, although it was in the wrong discussion :)
You can find more infomrations on pro-linux and heise (both german).
A short summary of the German texts: The notebooks will be shipped with FreeDOS pre-installed and a Ubuntu installation CD. Only the kernel on the Ubuntu CD will be modified: it contains HP specific patches to supports all features of the notebook, including full ACPI support, accelerated 3D graphics and two monitors. The rest of the distribution remains unmodified, you can update from the usual Ubuntu sources.
I think that anyone who is considering buying a PC for Lindows would be much better served buying a Mac or Mac Mini and using OS X instead.
Or he could buy one of these fancy HP notebooks that will ship with Ubuntu. Rumors say, HP develops a special Ubuntu version, that will support the complete hardware of these notebooks, including ACPI Suspend to RAM.
Ubuntu has a security model that is similar to Mac OS X. Root cannot login; when root privileges are required, sudo will be used.
In fact, you will see yellow light in many clean rooms. Blue light can interfer with chipm aking process, so you can only use the green and red spectrum of the light. And green and read appears as yellow to the eye.
The yellow light is not a problem, you get used of it within minutes. Then yellow will appear as white to you. But beware when you leave the clean room - everything will look quite funny until your eye recalibrates.
Background: You can't connect two ISDN devices or two modems with some kind of cross cable witout some additional tricks. To drive analog phones, you need a modem card with FXS support, for ISDN telephones, the card must support the NT-mode. E.g. the Junghanns QuadBRI card support NT and can drive up to 4 ISDN lines. The Wildcard TDM400P supports FXS can drive four analog devices. Both run fine with Asterisk.
Acronyms:
FXS: Foreinge Exchange Subscriber
NT: Network Trminator
If you are in a country you don't speak the language of, you have to point at the things you want (*). It's the same with visual programing. It makes it easy for newbies, because they can simply point at the things they want. But you might slightly more productive, when you can simply tell what you mean. When things become more complex, pointing at things comes to its limits. *) Just like me. I've learnt English at school, but my grammer is sometimes quite strange.
You're right. Criminals are making profit from botnets and they to for at least a year from now.
The difference between Java and Mono is not a technical one in the first place. Both are modern platforms with a JIT compiler and a prefered OO language. Both run on multiple platforms and for bioth are multiple languages available.
The problem is more a political one. On Mono, future language extensions are dictated by Microsoft. The Mono developers could of course extend their VM in any way they want. But they would loose compatibility with Windows.
On Java everyone can join the Java Community Process (JCP). Membership is free and every member is entitled to vote and can even run for election.
Datails can be found at Javalobby.org.
"Power arises when groups of people act in concert." (Hannah Arendt)
If you want to try X.org on debian, just add Ubuntu to your sources.list (details here) and intall the packet xserver-xorg. /usr/local/ (details here)
You could also compile it from source and install it under
You can read the complete story of iTunes, SoundJam and Audion here.