- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Should Desktop Linux go LUK
|
|
|
Comments (52)
No!
18 earlier comments in the full thread.
Quoting:There is no level of isolation when your at that level that could remotely be considered safe.
Why? Please explain.
Quoting:This is letting system level calls using the same API's that hackers already use into the Linux kernel.
That is the Linux kernel is secure ONLY because so few people use it argument. Which I do not buy.
Quoting:As I said before, if you want the funtionality, its already there for you in wine.
No it's not. I can no more use a device, for which there is no functional Linux Driver, with WINE than I can without WINE, on a Linux box.
WINE gives me no functionality that is not already in Linux, it merely translates Windows API calls to Linux API calls, the actual code is actually owned by root. However, that doesn't stop Viruses from running, on Linux, as the entry point to those API calls is in userspace in the C:WINDOWSSYSTEM32 directory.... exactly where they are on a Windows OS
Quoting:There is no excuse, no possible reason, that any one should breach isolation.
Where, specifically did anyone suggest breaching isolation? It is my understanding that the same isolation that makes Linux (the kernel) what it is will remain the same.
Quoting:Well gus, unless you are also r_a_trip I did not direct that comment at you.Yeah, I know, but r_a_trip was agreeing with what I had said, and amplifying it. I think you touch on the point with your comment:
Quoting:That is quite different from adding Windows code to Linux. we are talking about something that WINE already does, but hopefully more securely.The "more securely" is the killer. If an application is written to expect certain insecure behavior, would it break if suddenly Microsoft were to implement proper security in Windows? IIRC, that was a big complaint with Win2K. XP tried to mitigate it with their "privileged operation, continue?" dialog, and Vista is no better.
Yes, I'm a cynic. I can understand why FreeBSD would want to add the Linux entry point to their kernel, but adding a Windows API to the Linux kernel strains credulity.
Quoting:Yes, I'm a cynic. I can understand why FreeBSD would want to add the Linux entry point to their kernel, but adding a Windows API to the Linux kernel strains credulity.
But we already have a Windows API. Only not a secure one. It's called WINE. It's not insecure because the code written by the WINE coder is faulty, or even because the API they are rewriting is badly designed, but because the Windows API, as implemented in WINE... and only because it needs to act exactly like Windows, expects that certain file extensions like exe and bin and bat etc must be executed.
If one is to do this right surely one would create some means of making it work the Linux way, for example, NDISWrapper extracts the binary blob from the Windows driver, rather than executing the installer, the blob is then inserted into the appropriate location in the Linux directory tree, and is owned by root, so cannot be modified from user space. So.......
If one is making Windows API calls available to the Linux kernel, it stands to reason that one would either write code that works like NDISWrapper, or in some other way works around the Windows "you need to be root for me to function properly bug".
So far the majority of comments I've read arguing against the idea have been driven by emotion, the reasons given seem to boil down to "the Linux Developers can't make this work in a proper Linux way", and yet I've not seen any actual technical description of why it's not possible.
Quoting:That is the Linux kernel is secure ONLY because so few people use it argument. Which I do not buy.No, its the windows API is insecure and there is no effective means of correcting that issue argument.
This is very simple, if wine at user level will allow you to pick up a windows virus, and I have had exactly that happen, the putting wine in the kernel is unconditionally insane. This is not saying its secure because no one uses it, this is intentionally unsecuring it by adding fishnet stockings and calling it armor plating.
Quoting:Where, specifically did anyone suggest breaching isolation? It is my understanding that the same isolation that makes Linux (the kernel) what it is will remain the same.
I suggest more research then, this is a kernel level implementation. This gives it full 100% access to your entire system via the same system calls that hackers already know and use. That by my definition is un securing your system. If you want this kind of functionality, need for virus hunters, immeadiate and uncontrollable permission elevation ... they already make an OS for that and it can not be secured. Your saying that the answer is bolt it onto something already secure will somehow magically make it all better. Hogwash, the only thing it will do is bring the same innate failings to a second OS. Think on this, if windows or its kernel(s) could be secured, dont you think someone would have figured out how by now and done so?
Quoting:I've never seen Microsoft's code, and I have no intention of doing so
And that's probably for the best. As a professional programmer, only bad things can come from reading the leaked Win2K source code.
Quoting:they already make an OS for that and it can not be secured.
To begin with Windows can be secured. It just takes more work to get it right.
Quoting:No, its the windows API is insecure and there is no effective means of correcting that issue argument.
The Windows API is not insecure, any more than the Linux API is insecure. Run as root on Linux and you stand exactly the same chance of being pwned as you do on Windows... maybe a slightly higher chance, as Windows has the dubious protection of Anti Virus software.
You are confusing issues here. Windows the OS is insecure because of marketing decisions that have to do with how you install and use software, NOT because of any basic issues with the API. or it's design. It is exactly for this reason that WINE is insecure (the need for WINE to emulate Windows usage).
And yet you argue to put it in the kernel ...
@ azerthoth I'm arguing nothing at the moment, and certainly not that one adds anything to the Linux kernel, other people are saying that it's necessary to add the Windows API to the Linux kernel. I'm just trying to get past the emotion to the technical issues. And trying to explain why the Windows OS (note I didn't say API) is insecure, and why the Windows API is not necessarily insecure.
1) The WINE code written by the WINE developers (which re-implements a significant portion of the Windows API) is as secure as any other piece of Linux code.
2) Yet it's possible to run viruses on Linux using WINE.
3) Applications running on Windows require root (Administrator) level access so they will function properly.
the reason for 2) is 3) not because 1) is untrue.
Because Microsoft have chosen the expediency of making it "easy" for users to install and execute applications, they have been forced to implement additional expediencies, like including vast amounts of code that could, and should be left out of the kernel, in the kernel, causing among other things bloat. The cause of the insecurity is not the inclusion of the code, but the expediency of how Windows expects applications to work, to make life "easy" for users, in fact to make as little change and possible (from the user perspective) from MS DOS, Window 1,2 3, 95 ,98 ME to the so NT kernel based Systems like XP Vista and 7. In other words Windows insecurity is a Legacy thing.. the legacy of MSDOS, not something inherent in the API itself.
Given that WINE is inherently secure, even though the windows user space that relies on it is not, I think that it is safe to assume that it would be possible to create a subsystem that handles Windows drivers in the same safe and sane way that Linux drivers are currently handled, but with a translator like WINE supplying the necessary glue.
I'd love to hear some thoughts from a WINE developer or a Kernel developer or both.
1) The WINE code written by the WINE developers (which re-implements a significant portion of the Windows API) is as secure as any other piece of Linux code.
2) Yet it's possible to run viruses on Linux using WINE.
3) Applications running on Windows require root (Administrator) level access so they will function properly.
the reason for 2) is 3) not because 1) is untrue.
Because Microsoft have chosen the expediency of making it "easy" for users to install and execute applications, they have been forced to implement additional expediencies, like including vast amounts of code that could, and should be left out of the kernel, in the kernel, causing among other things bloat. The cause of the insecurity is not the inclusion of the code, but the expediency of how Windows expects applications to work, to make life "easy" for users, in fact to make as little change and possible (from the user perspective) from MS DOS, Window 1,2 3, 95 ,98 ME to the so NT kernel based Systems like XP Vista and 7. In other words Windows insecurity is a Legacy thing.. the legacy of MSDOS, not something inherent in the API itself.
Given that WINE is inherently secure, even though the windows user space that relies on it is not, I think that it is safe to assume that it would be possible to create a subsystem that handles Windows drivers in the same safe and sane way that Linux drivers are currently handled, but with a translator like WINE supplying the necessary glue.
I'd love to hear some thoughts from a WINE developer or a Kernel developer or both.
Quoting:like including vast amounts of code that could, and should be left out of the kernel, in the kernel
IIRC, in Windows, the GDI was moved into the kernel to make it faster. Running in kernel space means less context switches and thus faster execution.
Are we ok in here? We have some heated exchanges going on and I wanted to be sure that if we feel the need to tell each other off that we are doing through PM please.
This thread reads like a nice little argument..which is not cool for our readers or acceptable to me. After a certain point its better to just agree to disagree and move on in the forums. You can throw daggers at each other all you want in PM.
Kapeesh?
This thread reads like a nice little argument..which is not cool for our readers or acceptable to me. After a certain point its better to just agree to disagree and move on in the forums. You can throw daggers at each other all you want in PM.
Kapeesh?
But Scott!
I was only reading ... never got a comment in. So what's the problem?
YBT
PS I didn't even unlock the weapons cabinet.
I was only reading ... never got a comment in. So what's the problem?
YBT
PS I didn't even unlock the weapons cabinet.
We're cool, just a pleasant disagreement as far as I'm concerned.
> I was only reading ... never got a comment in. So what's the problem?
Yeah, what he said!
Yeah, what he said!
Because Microsoft have chosen the expediency of making it "easy" for users to install and execute applications, they have been forced to implement additional expediencies, like including vast amounts of code that could, and should be left out of the kernel, in the kernel, causing among other things bloat. The cause of the insecurity is not the inclusion of the code, but the expediency of how Windows expects applications to work, to make life "easy" for users, in fact to make as little change and possible (from the user perspective) from MS DOS, Window 1,2 3, 95 ,98 ME to the so NT kernel based Systems like XP Vista and 7. In other words Windows insecurity is a Legacy thing.. the legacy of MSDOS, not something inherent in the API itself.
Well, TA, you already give answer to your own question. So why ask us about it?
The problem is not Cutlers NT. This system is very secure and advanced. The trouble with Windows is Microsoft. They have let the inherent security in NT lie unused for years. The consequence is a userland that has no inkling of security anymore. It's a very ironic tragedy.
So yes, there is no inherent design reason why an NT based system should be insecure, but... MS borked up the policies and that has led to an entire software base assuming NT to behave promiscuous. So implementing a system that allows the Windows application base to run unaltered and work, will be a formidable task if they want to keep the security policies of *Nix in place.
I'm a cynic. I expect it will be easier for Insigma Co., Ltd to just emulate the behaviour of Win32 warts and all. So yes, have a separate project and see if it is viable security wise. If so, congratulations Insigma. If not, have a speedy death LUK.
By the way, having WDM in the Linux kernel is a very sharp two edged sword. On the one hand you get instant compatibility with all devices with a Windows driver. On the other, the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero. Having a WDM interface in Linux will probably condemn us to run every piece of hardware with a closed binary blob.
Well, TA, you already give answer to your own question. So why ask us about it?
The problem is not Cutlers NT. This system is very secure and advanced. The trouble with Windows is Microsoft. They have let the inherent security in NT lie unused for years. The consequence is a userland that has no inkling of security anymore. It's a very ironic tragedy.
So yes, there is no inherent design reason why an NT based system should be insecure, but... MS borked up the policies and that has led to an entire software base assuming NT to behave promiscuous. So implementing a system that allows the Windows application base to run unaltered and work, will be a formidable task if they want to keep the security policies of *Nix in place.
I'm a cynic. I expect it will be easier for Insigma Co., Ltd to just emulate the behaviour of Win32 warts and all. So yes, have a separate project and see if it is viable security wise. If so, congratulations Insigma. If not, have a speedy death LUK.
By the way, having WDM in the Linux kernel is a very sharp two edged sword. On the one hand you get instant compatibility with all devices with a Windows driver. On the other, the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero. Having a WDM interface in Linux will probably condemn us to run every piece of hardware with a closed binary blob.
Quoting:On the one hand you get instant compatibility with all devices with a Windows driver. On the other, the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero.
I agree.
Quoting: the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero.
Y'all might recall the 'give up a little freedom now for more freedom later' movement of a few years ago, in which it was advocated that dumping all kinds of non-free stuff into Linux was a good thing to do. Because it would then be irresistible to Windows users who would then dump 'doze and migrate in droves to Linux. And then they would all buy all of this proprietary stuff for Linux, and then at the magic tipping point they would arise en masse and demand that all of this closed stuff be opened up. And because of their mass purchasing clout, vendors would agree. (I am not making this up, people were saying this with straight faces.)
So let's run through our checklist:
1. Nvidia-- nope, and no hope 2. Adobe Flash-- nope, though there are rumors of opening the client 3. USB 2.0 audio recording interfaces-- not one. Nada. There are a few actual standards-compliant 1.1 devices that work great on Linux, but the industry lost its collective mind with 2.0. Funny how they don't mind writing unnecessary special drivers for Windows.... 4. Firewire audio recording interfaces-- it is to laugh. A very few vendors are sort of Linux supportive. The FFADO project does all the work, and that still isn't good enough 5. Moronic camera interfaces that still require Windows. Fortunately, using a Flash card reader gets around this. Again, they make unnecessary extra work for themselves for Windows, and that's OK. 6. All the favorite Windows softwares: Quicken, Photoshop, games. Are there any vendor-supported WINE implementations? Nope. Are there Linux ports of any kind, open or closed? Nope. 7. Fingerprint readers? Multicard readers? Webcams? Virtually no effort by hardware vendors, most progress is due to heroic FOSS coders
The Linux Driver Project, led by Greg k-H, deserves much of the credit for progress in hardware support in Linux, and the development and maintenance of Free drivers http://www.kroah.com/log/linux/linux_driver_project_status-2...
The Linux Wireless project deserves most of the credit for the substantial progress made in wireless support. They completely overhauled the wireless subsystem in Linux, cleaning it up and making it coherent, and they have built good relationships with hardware vendors.
As near as I can tell, all progress has come from tireless behind-the-scenes work, and the 'give up a little freedom now for more freedom later' strategy has not produced so much as a line of code.
> and the 'give up a little freedom now for more freedom later' strategy has not produced so much as a line of code.
That same thing has been obvious to me as well. Compromise freedom, and freedom has already lost.
This is not a "political" comment just because it relates to life in general. It's a statement of reality in terms of F/OSS.
It's times like this when I wish I were a better programmer, so I could contribute more than just bug reports and the occasional bit of funds.
That same thing has been obvious to me as well. Compromise freedom, and freedom has already lost.
This is not a "political" comment just because it relates to life in general. It's a statement of reality in terms of F/OSS.
It's times like this when I wish I were a better programmer, so I could contribute more than just bug reports and the occasional bit of funds.
Since the LUK project exists and they will most probably produce some LiNTux system with WDM support... Can we use the WDM subsystem to our advantage?
How legal would it be to add a "sniffer" to the LUK WDM subsystem to see how the binary blob communicates with the hardware? I imagine that cleanroom (if sniffers are legal) reverse engineering from the actual communication between driver and device could make stuff easier.
How legal would it be to add a "sniffer" to the LUK WDM subsystem to see how the binary blob communicates with the hardware? I imagine that cleanroom (if sniffers are legal) reverse engineering from the actual communication between driver and device could make stuff easier.
Quoting:It's times like this when I wish I were a better programmer, so I could contribute more than just bug reports and the occasional bit of funds.
Start out with a couple of Python tutorials. It's a great language and easy to learn.
Quoting:Can we use the WDM subsystem to our advantage?
To what end? WDM is deprecated so it's the older drivers that use this. Pretty much all that hardware is supported in the Linux kernel already. Greg HK's driver team is well stocked with programmers but suffers from a lack of work because pretty much everything is already supported.
For anything else (i.e. things that don't belong in the kernel) you don't need to sniff WDM. You can already sniff USB traffic for example.
I mean seriously, what hardware isn't supported in Linux these days? Perhaps the odd USB wifi stick, but even those are being solved.
win32 apps on linux
I can install wine and run a few win apps, but who needs them?
Anything that remotely benefits Microsoft is repugnant to my sense of basic human fairness and justice.
We still have one old win2k box which answers the phone and serves as an OCR and scan/fax platform.
Everything else works better in Linux, including gscan2pdf for scanning to pdf files, and all our old dos apps run great in dosemu.
A pox on Gates and company:)
Anything that remotely benefits Microsoft is repugnant to my sense of basic human fairness and justice.
We still have one old win2k box which answers the phone and serves as an OCR and scan/fax platform.
Everything else works better in Linux, including gscan2pdf for scanning to pdf files, and all our old dos apps run great in dosemu.
A pox on Gates and company:)
> Anything that remotely benefits Microsoft is repugnant to my sense of basic human fairness and justice.
I don't see how it would benefit Microsoft in any way. EVERY piece of hardware on the market will eventually have a driver for at least one version of Windows.
I don't see how it would benefit Microsoft in any way. EVERY piece of hardware on the market will eventually have a driver for at least one version of Windows.
""Everything else works better in Linux,""
BS
EDIT: If you were referring to " your " appz on " your" system, my apologies, otherwise, it stands.
BS
EDIT: If you were referring to " your " appz on " your" system, my apologies, otherwise, it stands.
The way I see it, if this makes it easier to use hardware on Linux, it can only be a good thing.
I'd warn against adding umpty-million Native NT system calls to Linux:
1. The API design of native NT system calls is bad. Apparently, the kernel has to watch for a page fault in some tricky part of system call handlers. This lead to a lot of early NT exploits.
2. You don't really want a kernel with a mix of philosophies. The Mach 2.x kernel (apparently now used by Apple) has just just a mix of philosophies. The Unix stuff battles with the Mach stuff for control. Security and performance loose: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.3...
1. The API design of native NT system calls is bad. Apparently, the kernel has to watch for a page fault in some tricky part of system call handlers. This lead to a lot of early NT exploits.
2. You don't really want a kernel with a mix of philosophies. The Mach 2.x kernel (apparently now used by Apple) has just just a mix of philosophies. The Unix stuff battles with the Mach stuff for control. Security and performance loose: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.3...
It can't be done anyway. The NT kernel does much more than the Linux kernel. In order to add all of Win32/NT to the Linux kernel you'd have to put X.org and a vast amount of other software in the kernel as well.
Quoting:It can't be done anyway. The NT kernel does much more than the Linux kernel.Surely you've heard that any turing machine can emulate any other turing machine? Could you provide an example of something that you suppose the nt kernel can do that the linux kernel can't?
Quoting:Could you provide an example of something that you suppose the nt kernel can do that the linux kernel can't?Let Steve Ballmer think he's the king of the IT world?
Guarantee a revenue stream for Symantec and McAfee?
Hold governments and corporations in a financial straight-jacket? ...oh, wait, that's the lawyers, not the kernel...
running apps in wine, thats fine by me ... adding it into the kernel ... have you lost your mind? The security aspects alone boggle then mind.
Quoting:Could you provide an example of something that you suppose the nt kernel can do that the linux kernel can't?
All the Win32 Windowing and GDI functions for starters. It's not about what the Linux kernel can or cannot do. It's about what it actually does or does not do. The Linux kernel exposes much less functionality than the NT kernel, this you can't map the NT kernel API to the Linux kernel. You'd need to fold back a considerable amount of userspace applications into the kernel.
Sander I think you missed the turing machine point.
I was under the impression, possibly mistaken, that the Windows API [translator?] would not have to be built into the kernel.
Quoting:Sander I think you missed the turing machine point.
No I did not. I invite you to reimplement Win32 in XSLT, which is turing complete. There's a difference between what's theoretically possible and what is practically achievable.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
http://portal.acm.org/citation.cfm?id=1255421.1255422&coll=G...
At the time Windows NT was "POSIX Certified" (by the Coast Guard, as I recall) there was some rancor about the wink-and-a-nudge certification process. That is, a lot of people called "foul" on it. Beyond calling foul, quite a few waivers had to be issued. The only one I recall for sure was about symbolic and/or hard links, but I've never figured out how Windows NT can emulate the fork/exec system call, while it's pretty obvious that fork/exec can emulate the CreateProcess Win32 call. Who knows what evil lies in the heart of NT when it comes to creating a new process?