(I still don't understand how he isn't considered the greatest monster of the 20th century having killed 50,000,000 people...
Because he actually killed about 2 millions people. The rest is based on bullshit claims, mostly created by Robert Conquest (accusing USSR government of the consequences of a natural disaster) and Alexander Solzhenitsyn (some very angry fiction on one unfairly imprisoned writer).
Not really, global nuclear war is very unlikely to destroy all of makind. Just really, really a lot of people, and make the survivors' life too miserable to keep the importance of whatever they supposedly fought for.
The US is at least as dependent on Chinese manufacturers as the Chinese manufacturers are dependent on US buyers.
Right. Because imaginary green paper is soooo unique that no one else can provide it. Americans' hubris and ignorance are astounding. Their LAZINESS and GLUTTONY are supposed to be the greatest resource everyone needs them for.
Fucking hell, please don't write this way. I talked out of what I thought I learned from debian-devel@, and I wasn't trying to do propaganda.
Well, yes, but I just wanted to emphasize how harmful it can be to spread unsourced and unverified information while claiming to be well-informed on the subject. Unfortunately for everyone who tries to make informed decisions, this kind of bold statements, spread as rumors and repeated by everyone, create an environment of what seems to be consensus among experts, or even truth. My comparison with propaganda efforts is limited on the fact that the same effect is being exploited by astroturfers -- they make false but plausible claims, state them boldly, provide no references that could be reviewed, studied or debunked, and see people picking it up as trustworthy.
I can't tell about the issues with VMWare, but I'm sure that there's less virtualization specific holes than kernel root exploits.
Not really. Kernel security bugs are in specific functionality -- they are applicable to specific functionality that may or may not be available on the system, and accessible through a specific interface that is often optional or recommended to be inaccessible on a system with locally untrusted users. Virtualization, on the other hand, has very limited interface, and if something is a security bug, it's almost guaranteed to be exploitable on all systems, with no mitigation or pre-emptive restrictions that could have prevented it. And there is a matter of the whole "host" or "management" environment that, if exploited, has overriding access to absolutely everything. With LXC and other host partitioning mechanisms, it's whatever runs outside the containers, and proper administration can reduce the functionality and interfaces to a minimum. With virtualization, one is lucky if virtualization system's vendor did not stuff GUI and a mail server in there.
So in this way, yes, virtualization is more secure than let's say a simple chrootuid (even with a grsec kernel).
And that's why people use LXC combined with SMACK or SELinux instead of that. As far as truly horrendous security bugs are concerned, such as unrestricted access to raw memory or storage, virtualization and kernel-based containers are equally insecure and equally likely to have such a bug, however even theoretically, virtualization provides less discriminative way of limiting access to the functionality involved, as it does not manage OS-managed primitives. For everything simpler or dependent on the OS interface, OS-managed security is in a better position because it has more clear representation of what item or interface belings where, and does not rely on management requests coming from any of the managed environments.
The only way to make virtualization more secure than that, is to detach it completely from the managed environment's kernel ("IBM mainframe" solution), but then either the performance loss would make the whole thing completely moot, or requirements for hardware-implemented features will make things unreasonably expensive, or the potentially bug-carrying code will shift into hardware where it would cause bugs that are more severe, less detectable and harder to mitigate. With those paths, in my opinion, leading to dead ends, I consider the whole "hypervisor" direction, and specifically its justification through security, to be a harmful distraction in OS/architecture development.
So, there are three, somewhat related points:
1. In general, LXC and similar "host-partitioning" or "kernel-managed containers" mechanisms are the only direction worth future development, as far as production-oriented multi-user hosted/managed environment are concerned. Everything else is either misdirected (authors do not understand how to use or provide such functionality in kernel), malicious (an attempt to impose what is essentially an OS product on everyone, including people who already chosen another OS), or un
That's a false and baseless accusation -- of all large software projects I have seen, Linux kernel is the only one that went through multiple changes in internals while keeping overall reliability, internal consistency and stability/compatibility of external interfaces. The rest either went through periods of massive breakage/loss of functionality/"depercation massacre", or ended up being married forever to inflexible, obsolete internal interfaces due to excessive spread of those interfaces across the software, overriding all intents of modularity.
If the company is not going to make a native application anyway, it's pointless to try to appease that company by making the rest of the system more to its liking -- the best one can get is Windows version working on Wine.
It's very important to realize that most of "requests" that Linux developers are bombarded with, are fake, and exist for no purpose other than an attempt to justify companies' idiotic, sycophantic or vindictive behavior in front of technically competent people.
Writing embedded platform and DSP firmware, working for a company that makes loudspeakers and other audio equipment, using and contributing to relevant open source software projects.
And this is why you can have multiple libraries or specific libraries for specific executable. This is, among other things, how closed source software is usually distributed. Only Windows has one happy DLL dump for everyone.
Yes, lets pretend that adding variables to structures, and adding conditional blocks to stuff like process management, network sockets or various stages of VFS has no effect on the user - specially when this funcionality is all added on a minor release.
It only does if the software is shit to begin with. Good software is maintainable and flexible.
You can't sue software development company for anything software does. All of them explicitly always disclaim all responsibility, and that was never shown to be invalid or illegal. You can sue a CONTRACTOR you have hired, however then closed or open source nature of software is completely irrelevant. If you are buying a license for software that is already written, you have no recourse for anything that happens after that.
You can only sue them for not delivering software or charging you for nothing, or stealing your sandwich, but as long as you got a pile of bytes from them and you "agreed" that those bytes are software you asked for, they are in the clear.
Thanks, you've found the blog post that I was talking about. I'm happy to read that there are mechanisms to get around it and that I was mistaking. However, if then LXC doesn't provide sysfs access to its containers, it's really not convenient. Is that mandatory to make it secured? Or are there ways to still provide sysfs in a safe way?
Yes, and that was discussed, too, however convenience is a completely unrelated matter to security. You claimed that LXC are inherently insecure. You talked out of your ass. Don't do that in the future.
I can't agree with this. Please give me a link to where there was a hole in Xen for example, allowing to gain access to the dom0 from a domU (note: PCI pass-through issues don't count, because you don't need them, and if you do, it's on your own Desktop, and we're talking about servers here). To the best of what I know, this never happened yet with Xen (it did with KVM though). I'm not saying that the software is perfect, or that it will never happen, but it just didn't (yet?). But anyways, there would be a lot of nice feature you'd like about LXC, even without it to be 100% safe.
I have never looked, however even if there never was such a bug found, it does not mean much -- Xen is not as widely used as VMWare, and VMWare had plenty of security bugs. For what it's worth, there weren't any bugs found in secured LXC setup, but this is not a reason to claim that there definitely aren't any. I have mentioned VMWare in particular because they show irresponsibility and hubris in face of actual bugs actually being found, and this behavior determines users' attitude toward virtualization as a whole -- it is perceived to be more secure than OS kernel, even though it is not.
Well, first of all, I'm not working on the kernel stuff in Debian.
Then why in the world you spew bullshit that you have heard somewhere (from a person who doesn't work on "kernel stuff in Debian", either) without even trying to verify its validity, or at least trying to provide a way for someone else to verify it? If you really wanted to post something and too lazy to do your research, you could've said "I can't find exactly where, but someone on debian-devel claimed that LXC are insecure". Now, compare it with what you actually posted and tell me, how in the world this is acceptable for sane, adult person discussing important matters in OS architecture??
Development and maintenance of proper QA procedures require greater amount of effort than maintenance of infrastructure used in development. Most companies' QA practices are abysmal (and this is a part of why there is such an obsession with test-driven development and unit testing -- because developers end up doing and overdoing QA job).
How so? If you mean "..but then everyone will hide the source", this is what can be (and is) done right now with GPL software. The important detail is, then those companies are trying to enforce copyright while distributing that GPL-violating software (to force users to pay, prevent reverse engineering, etc). No copyright -> no expectation that making software proprietary will allow the company to obtain more revenue from it.
Photoshop has no DRM, so Adobe will not port it onto platforms that it doesn't like. Both Adobe products that were ported to platforms that Adobe hates (Flash and Reader), implement DRM.
He claimed that native proprietary software on Linux leads to a slippery slope of DRM.
And it is true! More often than not, if any "consumer" software company bothers releasing anything closed-source for Linux, it's because they insist on restrictions implemented by that software. In particular, this applies to Adobe -- the only products they have ported (Flash and Adobe Reader) are ones that implement DRM. Nvidia and ATI do the same with restrictively licensed hardware drivers -- not DRM but still impediment for freedom of users and developers and massive pain in the ass for security and support/debugging.
They are based on the same kernel, they by default only use free drivers, and you still can install proprietary drivers on both. Ubuntu merely has a nice menu for that, but if this is what makes a difference for you, you should never try to use anything but Ubuntu in the first place.
Because more code gets hammered to provide funcionality the average user doesn't care/know about, often inside critical sections of the kernel.
And since that code is not hopelessly buggy, like in some other software, this has no effect on the user. I repeat, how is it relevant to "random breakages between updates"?
Slashdot Mirror
One of them is imperialism and another is globalization.
trust
Bwa ha ha ha ha ha ha!
BWA HA HA HA HA HA HA!
(I still don't understand how he isn't considered the greatest monster of the 20th century having killed 50,000,000 people...
Because he actually killed about 2 millions people. The rest is based on bullshit claims, mostly created by Robert Conquest (accusing USSR government of the consequences of a natural disaster) and Alexander Solzhenitsyn (some very angry fiction on one unfairly imprisoned writer).
Not really, global nuclear war is very unlikely to destroy all of makind. Just really, really a lot of people, and make the survivors' life too miserable to keep the importance of whatever they supposedly fought for.
The US is at least as dependent on Chinese manufacturers as the Chinese manufacturers are dependent on US buyers.
Right. Because imaginary green paper is soooo unique that no one else can provide it.
Americans' hubris and ignorance are astounding. Their LAZINESS and GLUTTONY are supposed to be the greatest resource everyone needs them for.
Last time you checked my blog in 2007.
That Russians are going to get H-1Bs and take you jerbs!!!!
I already did (in 1994). I also count for both Russia (where I studied) and Belarus (where I was born and studied, too).
ISPs use caches and only need to bring (static) content onto their network once.
No. There are services that provide it for specific content providers, however passing EVERYTHING through a transparent proxy is infeasible.
Fucking hell, please don't write this way. I talked out of what I thought I learned from debian-devel@, and I wasn't trying to do propaganda.
Well, yes, but I just wanted to emphasize how harmful it can be to spread unsourced and unverified information while claiming to be well-informed on the subject. Unfortunately for everyone who tries to make informed decisions, this kind of bold statements, spread as rumors and repeated by everyone, create an environment of what seems to be consensus among experts, or even truth. My comparison with propaganda efforts is limited on the fact that the same effect is being exploited by astroturfers -- they make false but plausible claims, state them boldly, provide no references that could be reviewed, studied or debunked, and see people picking it up as trustworthy.
I can't tell about the issues with VMWare, but I'm sure that there's less virtualization specific holes than kernel root exploits.
Not really. Kernel security bugs are in specific functionality -- they are applicable to specific functionality that may or may not be available on the system, and accessible through a specific interface that is often optional or recommended to be inaccessible on a system with locally untrusted users. Virtualization, on the other hand, has very limited interface, and if something is a security bug, it's almost guaranteed to be exploitable on all systems, with no mitigation or pre-emptive restrictions that could have prevented it. And there is a matter of the whole "host" or "management" environment that, if exploited, has overriding access to absolutely everything. With LXC and other host partitioning mechanisms, it's whatever runs outside the containers, and proper administration can reduce the functionality and interfaces to a minimum. With virtualization, one is lucky if virtualization system's vendor did not stuff GUI and a mail server in there.
So in this way, yes, virtualization is more secure than let's say a simple chrootuid (even with a grsec kernel).
And that's why people use LXC combined with SMACK or SELinux instead of that. As far as truly horrendous security bugs are concerned, such as unrestricted access to raw memory or storage, virtualization and kernel-based containers are equally insecure and equally likely to have such a bug, however even theoretically, virtualization provides less discriminative way of limiting access to the functionality involved, as it does not manage OS-managed primitives. For everything simpler or dependent on the OS interface, OS-managed security is in a better position because it has more clear representation of what item or interface belings where, and does not rely on management requests coming from any of the managed environments.
The only way to make virtualization more secure than that, is to detach it completely from the managed environment's kernel ("IBM mainframe" solution), but then either the performance loss would make the whole thing completely moot, or requirements for hardware-implemented features will make things unreasonably expensive, or the potentially bug-carrying code will shift into hardware where it would cause bugs that are more severe, less detectable and harder to mitigate. With those paths, in my opinion, leading to dead ends, I consider the whole "hypervisor" direction, and specifically its justification through security, to be a harmful distraction in OS/architecture development.
So, there are three, somewhat related points:
1. In general, LXC and similar "host-partitioning" or "kernel-managed containers" mechanisms are the only direction worth future development, as far as production-oriented multi-user hosted/managed environment are concerned. Everything else is either misdirected (authors do not understand how to use or provide such functionality in kernel), malicious (an attempt to impose what is essentially an OS product on everyone, including people who already chosen another OS), or un
That's a false and baseless accusation -- of all large software projects I have seen, Linux kernel is the only one that went through multiple changes in internals while keeping overall reliability, internal consistency and stability/compatibility of external interfaces. The rest either went through periods of massive breakage/loss of functionality/"depercation massacre", or ended up being married forever to inflexible, obsolete internal interfaces due to excessive spread of those interfaces across the software, overriding all intents of modularity.
If the company is not going to make a native application anyway, it's pointless to try to appease that company by making the rest of the system more to its liking -- the best one can get is Windows version working on Wine.
It's very important to realize that most of "requests" that Linux developers are bombarded with, are fake, and exist for no purpose other than an attempt to justify companies' idiotic, sycophantic or vindictive behavior in front of technically competent people.
Now, THAT is a great example of an ad hominem attack.
So what have you been doing with your life Alex?
Writing embedded platform and DSP firmware, working for a company that makes loudspeakers and other audio equipment, using and contributing to relevant open source software projects.
And this is why you can have multiple libraries or specific libraries for specific executable. This is, among other things, how closed source software is usually distributed. Only Windows has one happy DLL dump for everyone.
Yes, lets pretend that adding variables to structures, and adding conditional blocks to stuff like process management, network sockets or various stages of VFS has no effect on the user - specially when this funcionality is all added on a minor release.
It only does if the software is shit to begin with. Good software is maintainable and flexible.
I have gone into business for myself and have a cloud-based service I wrote at http://www.telephonemessagepad.com/
It is not a major money maker ... yet.
lol
You can't sue software development company for anything software does. All of them explicitly always disclaim all responsibility, and that was never shown to be invalid or illegal. You can sue a CONTRACTOR you have hired, however then closed or open source nature of software is completely irrelevant. If you are buying a license for software that is already written, you have no recourse for anything that happens after that.
You can only sue them for not delivering software or charging you for nothing, or stealing your sandwich, but as long as you got a pile of bytes from them and you "agreed" that those bytes are software you asked for, they are in the clear.
And what kinds of ads Microsoft believes to be appropriate for singing Rick Astley?
Thanks, you've found the blog post that I was talking about. I'm happy to read that there are mechanisms to get around it and that I was mistaking. However, if then LXC doesn't provide sysfs access to its containers, it's really not convenient. Is that mandatory to make it secured? Or are there ways to still provide sysfs in a safe way?
Yes, and that was discussed, too, however convenience is a completely unrelated matter to security. You claimed that LXC are inherently insecure. You talked out of your ass. Don't do that in the future.
I can't agree with this. Please give me a link to where there was a hole in Xen for example, allowing to gain access to the dom0 from a domU (note: PCI pass-through issues don't count, because you don't need them, and if you do, it's on your own Desktop, and we're talking about servers here). To the best of what I know, this never happened yet with Xen (it did with KVM though). I'm not saying that the software is perfect, or that it will never happen, but it just didn't (yet?). But anyways, there would be a lot of nice feature you'd like about LXC, even without it to be 100% safe.
I have never looked, however even if there never was such a bug found, it does not mean much -- Xen is not as widely used as VMWare, and VMWare had plenty of security bugs. For what it's worth, there weren't any bugs found in secured LXC setup, but this is not a reason to claim that there definitely aren't any. I have mentioned VMWare in particular because they show irresponsibility and hubris in face of actual bugs actually being found, and this behavior determines users' attitude toward virtualization as a whole -- it is perceived to be more secure than OS kernel, even though it is not.
Well, first of all, I'm not working on the kernel stuff in Debian.
Then why in the world you spew bullshit that you have heard somewhere (from a person who doesn't work on "kernel stuff in Debian", either) without even trying to verify its validity, or at least trying to provide a way for someone else to verify it? If you really wanted to post something and too lazy to do your research, you could've said "I can't find exactly where, but someone on debian-devel claimed that LXC are insecure". Now, compare it with what you actually posted and tell me, how in the world this is acceptable for sane, adult person discussing important matters in OS architecture??
QA talent
A.K.A. button-pushing monkeys.
Development and maintenance of proper QA procedures require greater amount of effort than maintenance of infrastructure used in development. Most companies' QA practices are abysmal (and this is a part of why there is such an obsession with test-driven development and unit testing -- because developers end up doing and overdoing QA job).
Flat out wrong.
How so? If you mean "..but then everyone will hide the source", this is what can be (and is) done right now with GPL software. The important detail is, then those companies are trying to enforce copyright while distributing that GPL-violating software (to force users to pay, prevent reverse engineering, etc). No copyright -> no expectation that making software proprietary will allow the company to obtain more revenue from it.
Photoshop has no DRM, so Adobe will not port it onto platforms that it doesn't like.
Both Adobe products that were ported to platforms that Adobe hates (Flash and Reader), implement DRM.
He claimed that native proprietary software on Linux leads to a slippery slope of DRM.
And it is true! More often than not, if any "consumer" software company bothers releasing anything closed-source for Linux, it's because they insist on restrictions implemented by that software. In particular, this applies to Adobe -- the only products they have ported (Flash and Adobe Reader) are ones that implement DRM. Nvidia and ATI do the same with restrictively licensed hardware drivers -- not DRM but still impediment for freedom of users and developers and massive pain in the ass for security and support/debugging.
They are based on the same kernel, they by default only use free drivers, and you still can install proprietary drivers on both. Ubuntu merely has a nice menu for that, but if this is what makes a difference for you, you should never try to use anything but Ubuntu in the first place.
Because more code gets hammered to provide funcionality the average user doesn't care/know about, often inside critical sections of the kernel.
And since that code is not hopelessly buggy, like in some other software, this has no effect on the user.
I repeat, how is it relevant to "random breakages between updates"?