Not having root just prevents certain "shady" things from happening, but in the end, you can do everything as your normal user.
If you run everything as root, your system will probably be as vulnurable as any windows system. Not running as root does of course not prevent all attacks, but it does prevent the most nasty ones. A worm with root permissions can do nasty things to your kernel, filesystem, libraries, and standard executables. If such things happens a reinstall will be your only way back to a normal situation. If OTOH the worm only has access to a single unpreveleged user, the system integrity is unaffected. In this case root can log in and watch what is going on, and there is no way the worm could hide anything. You will be able to compare the users file against the last backup, you will be able to see exactly what files the user has created on the system, you can watch his network access. And cleaning up is easy, just kill all the users processes, delete all his files from/tmp and/var/tmp, and finally restore his home directory from the latest uninfected backup. You can use diff to look for suspicious changes. And the backups can be done regularily by a cron job run as root, and can even be stored online.
And now that you actually have a fine multiuser system, why not use this fact? If I want to run something I just downloaded from the net, I usually run it under a dummy user ID. And whenever I run Wine, it is done under a dummy user ID. And you can prevent the user from doing certain things on the network, it is just a matter of a few iptables rules. On my system even if I ran Klez under Wine, iptables would deny it access to SMTP.
You forgot the best (mm/swapfile.c):
Unable to start swapping: out of memory:-)
And this one (arch/i386/boot/setup.S):
# Well, that certainly wasn't fun:-(. Hopefully it works, and we don't
# need no steenking BIOS anyway (except for the initial loading:-).
Damien miller's key has no sigs on it, so there's no reason for us to believe that it really belongs to him...
Even before this trojan history I was pedantic about avoiding a trojaned version. I downloaded Damiens public key from every mirror and verified they were identical. I have kept this key around since then, so if anybody were to create a fake key for Damien, I would notice.
Re:The REAL Question is
on
The End Of Minix?
·
· Score: 3, Interesting
GNU/Minix
Let's get some facts. Is that true or not? Does Minix, like Linux, use the entire GNU suite of tools?
Section 2 requires that people who distribute source code maintain access to the source code for three years.
This only applies if you distribute binaries without sources. You can just distribute sources with all your binaries, and that section does not apply to you.
If you still believe you must have all the benfits of the Amiga, get your self a nice linux box.
Linux certainly is a nice OS. But no matter how nice an OS you install, crappy hardware remains crappy. Where is the computer that will allow Linux to implement removable media handling like AmigaOS had? Where is the computer capable of perfect syncronisation between screen updates, screen refreshes, and sound? Where is the computer capable of moving pictures on the screen smoothly by just changing a few registers instead of copying it all to the new location? And where is the computer with the two nice mouse controllers like in my Amiga?
I hope no one will sue me about the aproximately 42 million spam mails that got lost in my honeypot. (I honestly didn't think anybody would miss them.)
Oh well, if they try something, I sue them for trying to abuse my computer as open relay and win the case.
AmigaOS is from before the CPU got protection, so obviously it had to be possible to crash. But I must say that of all the OSes I have seen running on CPUs without protection, AmigaOS is the best and most stable.
I disagree with that. But I do agree with the rest of what you wrote. Chroot is not broken, but it is however often used for the wrong job. Chroot is intended to be usefull for some system installation, system maintainance, and some software testing. For those purposes chroot works nicely. But using chroot for security purposes can be broken. Though chroot is not intended to be a security feature, it can in some cases help security. Running a daemon with a different root only helps if the daemon does not run as root, in that case we can prevent it from accessing a lot of devices and suid executables, which could potentially contain root exploits. So chroot cannot keep root inside, but it can help preventing another user inside from finding the root exploit he needs to get out.
Have you actually seen the prove and tried to understand it?
I trust a mathematical proof! Of course if the proof is complex, there can be errors in the proof. But I know a complex proof when I see one. The proof for security of OTP and nonsecurity of anything less is actually very simple. It is simple enough for me to follow every step and verify it's correctness.
This will lead me to the conclusion that OTP is secure. That doesn't mean the message cannot be intercepted, but to intercept it you have to find another place to attack. The OTP is not going to fall.
When we go to the physical "proofs" it is not really proofs, but rather strong indications. If the same has happened the first n times an experiment was done, we trust that the probability that it will happen again next time is at least (n-1)/n. But of course this doesn't tell us what will happen if we make another experiment. I don't say for sure, that quantummecanics behaves exactly like the physicians think, but it is very likely that it does to a large enough extent for for instance quantum cryptography to be secure.
But there does of course still exist a small possibility, that the physicians are wrong and you can indeed find the exact state of a quantum particle. But you could of course also intercept the message by almost too trivial teqniue of mindreading.
Do you have to write back and say "disregard bits 4,9,22...",
Not exactly, but it works slightly similar to that.
and if so, how is that return-channel not vulnerable to tampering?
Of course it will be vulnerable to tampering unless you do something to add authenticity to this conventional channel. What is important is the fact, that authenticity is feasible to do unconditionally secure with conventional computers. We already have unconditionally secure authenticity, what quantum cryptography can give us is unconditionally secure confidentiallity. To do that, it has to use the already given unconditionally secure authenticity.
A quantum sessions goes like this:
A sends a large number of quantom bits to B. (could be 3-10 times the size of the message.)
B sends back information about the bases used.
A sends information about the bases used.
Given the bases both parties can now remove the mismatching base pairs.
Now a random subset of the bits are used as samples to verify that the error rate is not too high. This can be done with sufficient reliability with a quite small number of samples, and the attacker cannot affect the random choice made by A or B.
A teqniue similar to an error-correcting-code is now applied to the remaining bits, and thus recovering from the known error rate.
Finally A and B both sends "signatures" proving the authenticity of everything send over the open channel.
If neither A nor B discovered a problem, the attacker will not know anything about the bits in the OTP. Now the message can be transmitted. The encrypted message should of course be signed as well. The encrypted message can include new keys for signatures in the next session.
Not according to the kernel developers. They tend to blame nVidia drivers for half the kernel crashes. (Well, they don't use those exact words, but asks if the problem can be reproduced without nVidia drivers.)
Even simpler than using an OTP, just distribute your message using whatever secure means you used to distribute your OTP.
That is not always possible. A quantum channel can be used to securely transfer the OTP, but it cannot be used to securely transfer the message. I'd better explain since somebody is going to wonder why is it so?
The point is that some of the bits can be intercepted, but you will know. If a bit was intercepted, simply don't use it. A random bit that could end up in the OTP is no use to an attacker if you decide not to use it. Another reason why you cannot transfer the message over the raw quantum channel is, that you will loose on average at least half the bits (at random that is). Finally the remaining raw bits from the quantum channel is hashed into the OTP. This means that you have no control over the actual contents of the OTP. All you know is that it is random, unknown to any attacker, and identical at both ends. This is perfectly suitable for an OTP, but it is not a message.
With OTP the size of the key and message are identical, and has been proven unconditionally secure. It has also been proven that no encryption with more bits of message than key can ever be unconditionally secure. This means that any cryptosystem with a many time pad or a pseudo random OTP is less secure than a real OTP.
In other words what this guy claims to have invented was proven impossible a long time ago. I find it hard to believe people when they claim to have done the impossible.
Where did you read that it was in CVS? I didn't read that anywhere. According to the article the trojan was only in the compressed tar files available for download.
Yes using BitKeeper equals contributing code to some project. But using BitKeeper does not equal contributing code to a project competing with BitKeeper.
You can use BitKeeper and other version control software for developing software for a completely different purpose (like for instance Linux), the question was what the EULA has to say about that.
I actually doubt this statement in the BitKeeper EULA has any relevance for European users. I guess it is only in America you can legally make such ridiculous claims.
So thanks Linus, for helping to develop GNU/Linux. But please consider GNU Hurd! Futrure generations will thank you.
Considering GNU Hurd is a good idea, not because of license issues, but because we shouldn't see Linux as the only option.
Both kernels are released under the GNU GPL, and thus the choice should not be based on the license but the technical differences. Consider the options and choose the kernel that is technically best for your purpose.
Believing that there can be only one kernel is bad no matter which kernel you have in mind.
There was a reason, I just don't remember it anymore. Many years has passed since then. I don't remeber every little detail anymore, but I do remember loosing a 50 bucks bet just because of a missing linebreak.
No, it is not the only reason. But it is one of the important reasons. Sometimes I just want to know what my computer is doing. Haven't you ever looked on a computer producing no visible output on the screen and just wondered: What the h... is going on?
What exactly is it that Lindows has a copyright on?
Those parts of the software which they wrote themselves.
Aren't they simply re-distributing software which is copyrighted by other people?
That is true for a lot of the software in the Lindows distribution.
Shouldn't it be the responsibility of those other people to provide source,
No. The copyright owner actually have little responsibility here. If you sell binaries you have to provide sources as well.
and shouldn't Lindows only have to indicate where the source is available from the original authors or copyright holders?
No, that option only applies if you redistribute non-commercial non-modified binaries. Since Lindows seems to be both commercial and modified, they surely have to provide the sources.
If the CD doesn't come with sources, they must provide the sources on CD for anyone at no more than the actual expences of copying the sources to a CD and shipping it. Providing the sources for download is not enough when selling binaries on a CD. And providing the sources for only registered users is not enough unless all users get it together with the binaries.
For those users who download binaries, it is their own responsibility to also download sources if they are available at the same location.
I don't think you have to give your work to anyone, you have to give anyone the right to use it, which is slightly different. Having the right to use it, they can use it if they can get it, but you don't have to help them get it.
They are not immune, they are actually humans too (kind of). I never wrote a virus, but I did have a game going on with my classmates back in highschool. It was all about poping up statements about each others choice of computer during boot. Since I was the one who wrote the trainers for all the games I could of course easily hide something there.
One day in the canteen the conversation went like this:
Thomas: Kasper you ought to get Martin's computer show some statement about HP vs. TI calculators everytime it boots.
Kasper: Yeah, I could do that.
Martin: I bet you could not.
Kasper: You wanna make a bet? I dare you 20 bucks. Give me two months, and a I will make a message pop up. You will know it was me when you see it.
Martin: Deal, you ain't got a chance.
Of course I wouldn't make the bet if I hadn't got a chance. I knew Martin wouldn't let me get anywhere near his computer before the end of this bet. And so our classmates knew. As soon as Martin has left they asked me what I had in mind. I answered this message will pop up on Martin's computer, and it will pop up on yours too. I had the program ready in place to pop up the message in 50 days. I felt so sure that I later agreed to raise the bet from 20 to 50 bucks. I lost! My program failed because of a missing newline at the end of his AUTOEXEC.BAT file.
Slashdot Mirror
Not having root just prevents certain "shady" things from happening, but in the end, you can do everything as your normal user.
/tmp and /var/tmp, and finally restore his home directory from the latest uninfected backup. You can use diff to look for suspicious changes. And the backups can be done regularily by a cron job run as root, and can even be stored online.
If you run everything as root, your system will probably be as vulnurable as any windows system. Not running as root does of course not prevent all attacks, but it does prevent the most nasty ones. A worm with root permissions can do nasty things to your kernel, filesystem, libraries, and standard executables. If such things happens a reinstall will be your only way back to a normal situation. If OTOH the worm only has access to a single unpreveleged user, the system integrity is unaffected. In this case root can log in and watch what is going on, and there is no way the worm could hide anything. You will be able to compare the users file against the last backup, you will be able to see exactly what files the user has created on the system, you can watch his network access. And cleaning up is easy, just kill all the users processes, delete all his files from
And now that you actually have a fine multiuser system, why not use this fact? If I want to run something I just downloaded from the net, I usually run it under a dummy user ID. And whenever I run Wine, it is done under a dummy user ID. And you can prevent the user from doing certain things on the network, it is just a matter of a few iptables rules. On my system even if I ran Klez under Wine, iptables would deny it access to SMTP.
You forgot the best (mm/swapfile.c): :-)
Unable to start swapping: out of memory
And this one (arch/i386/boot/setup.S): :-(. Hopefully it works, and we don't :-).
# Well, that certainly wasn't fun
# need no steenking BIOS anyway (except for the initial loading
Damien miller's key has no sigs on it, so there's no reason for us to believe that it really belongs to him...
Even before this trojan history I was pedantic about avoiding a trojaned version. I downloaded Damiens public key from every mirror and verified they were identical. I have kept this key around since then, so if anybody were to create a fake key for Damien, I would notice.
GNU/Minix
Let's get some facts. Is that true or not? Does Minix, like Linux, use the entire GNU suite of tools?
Section 2 requires that people who distribute source code maintain access to the source code for three years.
This only applies if you distribute binaries without sources. You can just distribute sources with all your binaries, and that section does not apply to you.
If you still believe you must have all the benfits of the Amiga, get your self a nice linux box.
Linux certainly is a nice OS. But no matter how nice an OS you install, crappy hardware remains crappy. Where is the computer that will allow Linux to implement removable media handling like AmigaOS had? Where is the computer capable of perfect syncronisation between screen updates, screen refreshes, and sound? Where is the computer capable of moving pictures on the screen smoothly by just changing a few registers instead of copying it all to the new location? And where is the computer with the two nice mouse controllers like in my Amiga?
I hope no one will sue me about the aproximately 42 million spam mails that got lost in my honeypot. (I honestly didn't think anybody would miss them.)
Oh well, if they try something, I sue them for trying to abuse my computer as open relay and win the case.
Guru Meditation
AmigaOS is from before the CPU got protection, so obviously it had to be possible to crash. But I must say that of all the OSes I have seen running on CPUs without protection, AmigaOS is the best and most stable.
Chroot is broken
I disagree with that. But I do agree with the rest of what you wrote. Chroot is not broken, but it is however often used for the wrong job. Chroot is intended to be usefull for some system installation, system maintainance, and some software testing. For those purposes chroot works nicely. But using chroot for security purposes can be broken. Though chroot is not intended to be a security feature, it can in some cases help security. Running a daemon with a different root only helps if the daemon does not run as root, in that case we can prevent it from accessing a lot of devices and suid executables, which could potentially contain root exploits. So chroot cannot keep root inside, but it can help preventing another user inside from finding the root exploit he needs to get out.
Have you actually seen the prove and tried to understand it?
I trust a mathematical proof! Of course if the proof is complex, there can be errors in the proof. But I know a complex proof when I see one. The proof for security of OTP and nonsecurity of anything less is actually very simple. It is simple enough for me to follow every step and verify it's correctness.
This will lead me to the conclusion that OTP is secure. That doesn't mean the message cannot be intercepted, but to intercept it you have to find another place to attack. The OTP is not going to fall.
When we go to the physical "proofs" it is not really proofs, but rather strong indications. If the same has happened the first n times an experiment was done, we trust that the probability that it will happen again next time is at least (n-1)/n. But of course this doesn't tell us what will happen if we make another experiment. I don't say for sure, that quantummecanics behaves exactly like the physicians think, but it is very likely that it does to a large enough extent for for instance quantum cryptography to be secure.
But there does of course still exist a small possibility, that the physicians are wrong and you can indeed find the exact state of a quantum particle. But you could of course also intercept the message by almost too trivial teqniue of mindreading.
No, I don't think your question is stupid.
Do you have to write back and say "disregard bits 4,9,22...",
Not exactly, but it works slightly similar to that.
and if so, how is that return-channel not vulnerable to tampering?
Of course it will be vulnerable to tampering unless you do something to add authenticity to this conventional channel. What is important is the fact, that authenticity is feasible to do unconditionally secure with conventional computers. We already have unconditionally secure authenticity, what quantum cryptography can give us is unconditionally secure confidentiallity. To do that, it has to use the already given unconditionally secure authenticity.
A quantum sessions goes like this:
nVidia support.... on Linux it just works
Not according to the kernel developers. They tend to blame nVidia drivers for half the kernel crashes. (Well, they don't use those exact words, but asks if the problem can be reproduced without nVidia drivers.)
Even simpler than using an OTP, just distribute your message using whatever secure means you used to distribute your OTP.
That is not always possible. A quantum channel can be used to securely transfer the OTP, but it cannot be used to securely transfer the message. I'd better explain since somebody is going to wonder why is it so?
The point is that some of the bits can be intercepted, but you will know. If a bit was intercepted, simply don't use it. A random bit that could end up in the OTP is no use to an attacker if you decide not to use it. Another reason why you cannot transfer the message over the raw quantum channel is, that you will loose on average at least half the bits (at random that is). Finally the remaining raw bits from the quantum channel is hashed into the OTP. This means that you have no control over the actual contents of the OTP. All you know is that it is random, unknown to any attacker, and identical at both ends. This is perfectly suitable for an OTP, but it is not a message.
One Time Pad is _provably_ unbreakable.
That is true.
With OTP the size of the key and message are identical, and has been proven unconditionally secure. It has also been proven that no encryption with more bits of message than key can ever be unconditionally secure. This means that any cryptosystem with a many time pad or a pseudo random OTP is less secure than a real OTP.
In other words what this guy claims to have invented was proven impossible a long time ago. I find it hard to believe people when they claim to have done the impossible.
How do these patches make it into the CVS
Where did you read that it was in CVS? I didn't read that anywhere. According to the article the trojan was only in the compressed tar files available for download.
for those of us too lazy to make the extra click
Too bad I already did.
"using" equals "contributing code"
.
Yes using BitKeeper equals contributing code to some project . But using BitKeeper does not equal contributing code to a project competing with BitKeeper
You can use BitKeeper and other version control software for developing software for a completely different purpose (like for instance Linux), the question was what the EULA has to say about that.
I actually doubt this statement in the BitKeeper EULA has any relevance for European users. I guess it is only in America you can legally make such ridiculous claims.
So thanks Linus, for helping to develop GNU/Linux. But please consider GNU Hurd! Futrure generations will thank you.
Considering GNU Hurd is a good idea, not because of license issues, but because we shouldn't see Linux as the only option.
Both kernels are released under the GNU GPL, and thus the choice should not be based on the license but the technical differences. Consider the options and choose the kernel that is technically best for your purpose.
Believing that there can be only one kernel is bad no matter which kernel you have in mind.
I'm more concerned with this statement.
There was a reason, I just don't remember it anymore. Many years has passed since then. I don't remeber every little detail anymore, but I do remember loosing a 50 bucks bet just because of a missing linebreak.
I thought that was the only reason to use Linux!?
No, it is not the only reason. But it is one of the important reasons. Sometimes I just want to know what my computer is doing. Haven't you ever looked on a computer producing no visible output on the screen and just wondered: What the h... is going on?
What exactly is it that Lindows has a copyright on?
Those parts of the software which they wrote themselves.
Aren't they simply re-distributing software which is copyrighted by other people?
That is true for a lot of the software in the Lindows distribution.
Shouldn't it be the responsibility of those other people to provide source,
No. The copyright owner actually have little responsibility here. If you sell binaries you have to provide sources as well.
and shouldn't Lindows only have to indicate where the source is available from the original authors or copyright holders?
No, that option only applies if you redistribute non-commercial non-modified binaries. Since Lindows seems to be both commercial and modified, they surely have to provide the sources.
Does the CD with Lindows also contain sources?
If the CD doesn't come with sources, they must provide the sources on CD for anyone at no more than the actual expences of copying the sources to a CD and shipping it. Providing the sources for download is not enough when selling binaries on a CD. And providing the sources for only registered users is not enough unless all users get it together with the binaries.
For those users who download binaries, it is their own responsibility to also download sources if they are available at the same location.
you have to give your work to anyone who wants it
I don't think you have to give your work to anyone, you have to give anyone the right to use it, which is slightly different. Having the right to use it, they can use it if they can get it, but you don't have to help them get it.
They are not immune, they are actually humans too (kind of). I never wrote a virus, but I did have a game going on with my classmates back in highschool. It was all about poping up statements about each others choice of computer during boot. Since I was the one who wrote the trainers for all the games I could of course easily hide something there.
One day in the canteen the conversation went like this:
- Thomas: Kasper you ought to get Martin's computer show some statement about HP vs. TI calculators everytime it boots.
- Kasper: Yeah, I could do that.
- Martin: I bet you could not.
- Kasper: You wanna make a bet? I dare you 20 bucks. Give me two months, and a I will make a message pop up. You will know it was me when you see it.
- Martin: Deal, you ain't got a chance.
Of course I wouldn't make the bet if I hadn't got a chance. I knew Martin wouldn't let me get anywhere near his computer before the end of this bet. And so our classmates knew. As soon as Martin has left they asked me what I had in mind. I answered this message will pop up on Martin's computer, and it will pop up on yours too. I had the program ready in place to pop up the message in 50 days. I felt so sure that I later agreed to raise the bet from 20 to 50 bucks. I lost! My program failed because of a missing newline at the end of his AUTOEXEC.BAT file.This is outside the scope of quantum cryptography. But of course it is still of interest. There are two different aproaches to solve this problem: