ISA is really low bandwidth. Getting 4x seems pretty good, all things considered.
Do yourself a favour and lose that ISA card. Get a $50 PCI SCSI adapter instead:)
And for your last comment, IDE is actually not so heavy on the CPU anymore. IDE has improved and CPUs just got a lot faster. For CDRW I can't imagine that IDE would be a problem (thoughput wise).
Basically he just told us that circa 2001, SCSI was faster. I think we mostly knew that already
Not even.
He told us that a 7200 RPM 9 GB drive has faster seek times than a 7200 RPM 40 GB drive. And he told us that opening a maildir is dominated by seek time.
A 9 GB drive has lower density than a 40 GB drive, and this means two things: The lower density yields a slower throughput (which does not matter for opening a maildir). And, the lower density means wider tracks, which again means faster head positioning and therefore faster seek times. Seek times dominate (by far) the time it takes to open a maildir.
He could have taken a 40 GB SCSI drive and a 9 GB IDE drive, and seen the exact same results, reversed.
The IDE vs. SCSI difference is there, somehwere - but for such a limited and over-simplified benchmark, I'd be more than a little surprised if he could see more than a 10% difference. And most likely SCSI would even lose, since his benchmark is latency-dominated (not throughput dominated), and SCSI has higher latency than IDE (because it is a much more advanced bus protocol).
All in all, SCSI is the way to go for many high performance purposes, no doubt about it.
But this sorry excuse for a benchmark test takes a completely incoherent setup, runs a rediculous test which amplifies the severe failures of fairness in the test setup, and makes a conclusion based on an unfair test setup with a ludicrous testing environment set up to make absolutely sure that no result from the environment can be attributed any meaning what so ever.
I felt almost empty inside, seeing an article on slashdot that did not mention how this relates to the war on terrorism.
I could imagine posting anti-terror operatives on the observation decks (or tying one up in the speir), to "track terrorist movement" in the city below. But no, no mention on how this great tower would relate to fighting terrorism.
You, my friend, introduced the subject in this fine discussion. I am now a whole being again. Thank you so much!
Come on - you take detailed personal records, fold the paper, and put it in a publicly accessible and open bin in a crowded public area when you *know* that people who want that information are watching you. Random bypassers could get this piece of paper by *accident* for christs sakes.
And you want to sue *them* ?
I am terribly sorry to be cynical about this, but what did you expect? Honesty and ethics? From someone who is paid solely by the amount of personal data they succeed in gathering? It may not even be those people - it could be a couple of kids skipping classes, pulling an easy prank. Sign the slip "Santaclaus" in bad longhand and mail the form.
It may be legal and it may not be, I don't know and I don't care - but you could just as well have taken that paper slip, xeroxed it in half a gazillion copies and have it air-dropped over your country's major cities.
It was a folded piece of paper in a very publicly accessible place, now get over it please.
My box is on Debian 3.0 - the explanation I saw at that time was that the combination of PAM and the extra OPIE password query wouldn't work with privsep because of some too simplified assumptions in SSH/privsep about what would be asked by the system and what would be submitted by the user.
Or something like that. I set it up half a year ago and to be honest I don't remember the details - I just remember that at that time OPIE+privsep was a no-go, at least on a Debian box with PAM.
It sounded like it was something that could be fixed fairly easily - I was lazy and didn't bother to try doing that myself, and just went with no privsep to get a working setup. I suppose someone could have fixed whatever the problem was, in the mean time. Or maybe the problem somehow exists on Debian and not on NetBSD - I'm sure there is a reasonable explanation somewhere;)
Thanks for letting me know. I should check up on it.
Unfortunately, privilege separation does not work with with OPIE, the one-time password system.
So either you run privsep, or you run OTP.
Without OTP, you'd be crazy to log on to your ssh box from anything but a trusted terminal (e.g. your office workstation or your personal laptop). Without OTP, you cannot log on from a net cafe or anything like that, if you're just slightly security concious.
So I'm stuck with privsep and no OTP on some machines, and OTP without privsep on another (which I need to be able to log on to from untrusted terminals).
It sucks, but it's the best we have for now, it seems.
I do look forward to finally getting that 2.6 SELinux toy box set up;)
That's exactly the sort of question the US media asks. And if you read my post again, you'll notice that nowhere did I say that china was better than the US (but seeing as you asked, I prefer chinese movies to the vast majority of the American films I've seen).
Another point that people seem to be missing is, that maybe we're not just worried that the U.S. is in control of GPS. Maybe we are worried that someone may be able to compromise the system.
Again it is not a matter of whether it's North Korea or the U.S. having the control with the system - once that control is overtaken or compromised, it doesn't matter who it was taken from.
This is why you need at least two systems, controlled by different governments. With GLONASS being virtually useless, GALILEO is a welcome alternative.
I'd be delighted - and indeed would dance a little jig - if the US were to say suddenly "okay, GPS is now under the control of the UN".
I think I just explained why U.N. control over GPS would not solve the problem (not the big one at least):)
Can't see anything at the full disclosure mailing list poiting anything serious. Only a priv mail from theo stating the bug doesn't look exploitable for now.
That is the message that describes that privsep was enabled - a few messages before, the ISP incidents are described.
Do you trust anybody posting something they've heard?
No, and neither should you.
But tell me, why would I deliberately lie?
The guy that started the "new ssh exploit?" thread stated first he knew of an ISP *blocking* sshd traffic (this is far from an exploit).
Yes, that mail states that they are blocking *because* they had several boxes rooted from what *seemed* to be an sshd exploit.
Can you read at all?
So FU** YOU.
Charming.
I am sure that if you could count, you would tell me in how many ways as well.
SO BAD THERE ARE OTHER ARCHIEVES AROUND.
*plonk*
I don't know what you are smoking, but I will try to avoid your dealer.
I see *nothing* in what you wrote above, that casts any doubt on the correctness of what I posted. It was doubtful whether privsep would prevent the bug, and I stated that in the post to keep it correct.
What's your point? So far you've called me a liar, become my first slashdot "freak", and blurted all sorts of things about how unfair the world is to you. Why is it that we need to care about your oppinions? Do you have an oppinion at all? What are you trying to tell us here?
sshd is only granted the necessary access in order to receive user credentials. It therefore cannot access the disk, create network connections, or execute arbitrary programs.
Yes you can compromise sshd, but you will be left with the control over a process that can do virtually nothing.
This changes only when it provides real user credentials to the kernel.
It's mandatory access controls. And the above is why they can give you *real* security, not just 'I think my daemon is sorta secure and therefore trust it with my whole box'-security
I pieced the message together as soon as I had seen about five mails from slashdotted mailing list archives, in order to let people know what the status was at that time - thus the title of the post ("bits and pieces so far").
One of the original posts in one of the threads stated, that there had been multiple successful attacks at an ISP which seemed to be SSH related. In this case they did run with privilege separation enabled.
As the thread evolved, it became clear that there was a vulnerability in SSH.
I therefore wrote that it seems that privilege separation does not help in this case. And I specifically wrote "seems" because it was not proven beyond a doubt, that the original attacks were indeed caused by this vulnerability, it only seemed "highly likely" from the thread.
I never meant to spread FUD - I tried as best I could to get the most information as was available at the time, out to the most people. And it is a lot safer saying "privilege separation might not be effective" than not mentioning that fact (it was a fact that it seemed not to be effective), and having someone believe that they were home free when maybe they weren't.
It should be pretty simple to examine the code to see if the buffer.c routines are used somewhere before the privsep code. I will leave that as an exercise to whoever cares, my sshds are updated now:)
vsftpd is defensible, given that it's an FTP server. And that's it.
Why do *I* need SSH, finger, DNS, PostgreSQL,..., services from that machine? I don't!
If you telnet to a known postgresql server and send it 'asdf', it will reply with 'EFATAL 1: invalid length of startup packet'. When you telnet to security.debian.org on it's postgresql port, it responds with exactly the same message.
So, to answer the other poster: it pretty much looks like a postgresql server - and it sure didn't firewall me away.
It seems that you are right... Just one box. Impressive.
It's impressive in more ways than that - a quick nmap run shows that it has *heaps* of services running, freely available from the net. Among them, postgres, (some) named and SSH.
Apart from the single-point-of-failure problem, why on earth are we running updates from a machine with more holes than a swiss cheese?
Wouldn't it be pretty simple to find an exploit in one of the many services (I bet postgresql will have an overflow or two, having it available from the net is insane to put it mildly), upload a new backdoor'ed SSH package and, say, post a story to slashdot about an SSH hole?
(Yes it does seem that this particular SSH exploit is legitimate, because of references from other sites - the above was just an example).
Just a snippet from the nmap run
21/tcp open ftp 22/tcp open ssh 53/tcp open domain 79/tcp open finger 80/tcp open http 113/tcp open auth 487/tcp open saft 873/tcp open rsync 5432/tcp open postgres
If Visual C++ goes away, there are other vendors who produce C++ compilers
Ok, I just have to step in here with a correction:)
VC++ is not a C++ compiler - we have a large C++ project here and by the time we were spending hours on a daily basis getting VC++ to actually understand our ANSI C++ that other compilers had no problem understanding, we moved to the Intel C++ compiler for our windows port.
If VC++ went away, good riddance. The worst part is probably, that VC++ makes its users think they know C++ - boy, if you use VC++ you have not even touched the surface of what C++ can do.
Evolution has this virtual folder concept, which allows you to set up filters that will decide in which folders mail appear - allowing one mail to apper in multiple folders (but still only having one copy of the mail).
Furthermore when you update the filters, your virtual folders are (of course, by means of the way that it is implemented) updated.
I used it for a while and it worked great. Until I started having more mail, then it started getting slow. Then it got really slow. I quit evolution entirely when it was unable to show any of the mails in my inbox, using virtual folders or not.
In short, the feature is in evolution, but if you have a lot of mail lying around (an inbox with 20-30k e-mails), it just doesn't work. Evolution has some nice features, they're just not implemented in a way so that they work on anything but toy mailboxes. Which is really a pity, since the ideas were great.
Now, I'm on bogofilter+procmail+kmail, and I'm fairly happy with that. No virtual folders, but I can read my mail again. Yippie!:)
While it's slick that they had a dual proc board and all... none of the tests they used used the dual proc-ness of the system. They even indicate in their results that the second proc just threw overhead into the system.
Those people do not have the faintest idea about what they are talking about.
First, of all - a dual processor Opteron is not SMP. It is NUMA. (The difference: SMP="Symmetrical Multi Processing", NUMA="Non Uniform Memory Access").
In an SMP system, multiple processors share access to the memory. In a NUMA system, you have a number of SMP or UP (uni-processor) systems (with their own local memory) and tie all these "nodes" together with some bad-ass interconnect.
In the dual Opteron case, you have two nodes (each with one CPU), and the HyperTransport as interconnect.
What this means is: If your operating system does not have a NUMA-aware scheduler - it may well schedule a process which resides in Node-0's memory to run on Node-1, causing slower memory transfers.
*This* might be a good reason why they saw lower numbers on their multi-processor runs.
Generally, you should see almost no slowdown when making a single-processor workload run on a multi-processor system, if the system is otherwise idle. But the above will explain it - XP does not have anything resembling NUMA awareness.
While it's slick that they had a dual proc board and all... none of the tests they used used the dual proc-ness of the system. They even indicate in their results that the second proc just threw overhead into the system.
Which, as someone else pointed out, is a rediculous request. Their hand-waving about how such software is expensive and requires tens of machines running, oh my oh my.
Boot a recent linux kernel. Run "make -j10" on some big source tree - like the kernel itself or KDE.
Not only would this be a very good multi-processor benchmark (on a kernel for which NUMA awareness in the Opteron case actually exist eiither in merged form or in the form of patches) - heck, it would even be A REAL WORLD WORKLOAD!
Politics: the gentle art of getting votes from the poor and campaign funds from the rich by promising to protect each from the other. -- Oscar Ameringer
Slashdot Mirror
ISA is really low bandwidth. Getting 4x seems pretty good, all things considered.
:)
Do yourself a favour and lose that ISA card. Get a $50 PCI SCSI adapter instead
And for your last comment, IDE is actually not so heavy on the CPU anymore. IDE has improved and CPUs just got a lot faster. For CDRW I can't imagine that IDE would be a problem (thoughput wise).
hehe...
Did you read my comment?
Try reading it again, and you will see that we absolutely agree on that stance.
There is *nothing* in my comment that indicates otherwise.
Basically he just told us that circa 2001, SCSI was faster. I think we mostly knew that already
Not even.
He told us that a 7200 RPM 9 GB drive has faster seek times than a 7200 RPM 40 GB drive. And he told us that opening a maildir is dominated by seek time.
A 9 GB drive has lower density than a 40 GB drive, and this means two things: The lower density yields a slower throughput (which does not matter for opening a maildir). And, the lower density means wider tracks, which again means faster head positioning and therefore faster seek times. Seek times dominate (by far) the time it takes to open a maildir.
He could have taken a 40 GB SCSI drive and a 9 GB IDE drive, and seen the exact same results, reversed.
The IDE vs. SCSI difference is there, somehwere - but for such a limited and over-simplified benchmark, I'd be more than a little surprised if he could see more than a 10% difference. And most likely SCSI would even lose, since his benchmark is latency-dominated (not throughput dominated), and SCSI has higher latency than IDE (because it is a much more advanced bus protocol).
All in all, SCSI is the way to go for many high performance purposes, no doubt about it.
But this sorry excuse for a benchmark test takes a completely incoherent setup, runs a rediculous test which amplifies the severe failures of fairness in the test setup, and makes a conclusion based on an unfair test setup with a ludicrous testing environment set up to make absolutely sure that no result from the environment can be attributed any meaning what so ever.
Get real.
I felt almost empty inside, seeing an article on slashdot that did not mention how this relates to the war on terrorism.
I could imagine posting anti-terror operatives on the observation decks (or tying one up in the speir), to "track terrorist movement" in the city below. But no, no mention on how this great tower would relate to fighting terrorism.
You, my friend, introduced the subject in this fine discussion. I am now a whole being again. Thank you so much!
Come on - you take detailed personal records, fold the paper, and put it in a publicly accessible and open bin in a crowded public area when you *know* that people who want that information are watching you. Random bypassers could get this piece of paper by *accident* for christs sakes.
And you want to sue *them* ?
I am terribly sorry to be cynical about this, but what did you expect? Honesty and ethics? From someone who is paid solely by the amount of personal data they succeed in gathering? It may not even be those people - it could be a couple of kids skipping classes, pulling an easy prank. Sign the slip "Santaclaus" in bad longhand and mail the form.
It may be legal and it may not be, I don't know and I don't care - but you could just as well have taken that paper slip, xeroxed it in half a gazillion copies and have it air-dropped over your country's major cities.
It was a folded piece of paper in a very publicly accessible place, now get over it please.
You don't get much out do you?
Try breathing in outer space.
Intellectual Property, like flying pigs, cannot be found in nature.
Ok, I suppose that's a pretty good explanation.
Thanks for the info.
Interesting.
;)
Is that using PAM?
My box is on Debian 3.0 - the explanation I saw at that time was that the combination of PAM and the extra OPIE password query wouldn't work with privsep because of some too simplified assumptions in SSH/privsep about what would be asked by the system and what would be submitted by the user.
Or something like that. I set it up half a year ago and to be honest I don't remember the details - I just remember that at that time OPIE+privsep was a no-go, at least on a Debian box with PAM.
It sounded like it was something that could be fixed fairly easily - I was lazy and didn't bother to try doing that myself, and just went with no privsep to get a working setup. I suppose someone could have fixed whatever the problem was, in the mean time. Or maybe the problem somehow exists on Debian and not on NetBSD - I'm sure there is a reasonable explanation somewhere
Thanks for letting me know. I should check up on it.
Unfortunately, privilege separation does not work with with OPIE, the one-time password system.
;)
So either you run privsep, or you run OTP.
Without OTP, you'd be crazy to log on to your ssh box from anything but a trusted terminal (e.g. your office workstation or your personal laptop). Without OTP, you cannot log on from a net cafe or anything like that, if you're just slightly security concious.
So I'm stuck with privsep and no OTP on some machines, and OTP without privsep on another (which I need to be able to log on to from untrusted terminals).
It sucks, but it's the best we have for now, it seems.
I do look forward to finally getting that 2.6 SELinux toy box set up
Write a HOWTO and put your real e-mail address in there.
;)
Worked for me
That's exactly the sort of question the US media asks. And if you read my post again, you'll notice that nowhere did I say that china was better than the US (but seeing as you asked, I prefer chinese movies to the vast majority of the American films I've seen).
:)
Another point that people seem to be missing is, that maybe we're not just worried that the U.S. is in control of GPS. Maybe we are worried that someone may be able to compromise the system.
Again it is not a matter of whether it's North Korea or the U.S. having the control with the system - once that control is overtaken or compromised, it doesn't matter who it was taken from.
This is why you need at least two systems, controlled by different governments. With GLONASS being virtually useless, GALILEO is a welcome alternative.
I'd be delighted - and indeed would dance a little jig - if the US were to say suddenly "okay, GPS is now under the control of the UN".
I think I just explained why U.N. control over GPS would not solve the problem (not the big one at least)
Can't see anything at the full disclosure mailing list poiting anything serious. Only a priv mail from theo stating the bug doesn't look exploitable for now.
So that must mean that what I read did not exist?
Try here
That is the message that describes that privsep was enabled - a few messages before, the ISP incidents are described.
Do you trust anybody posting something they've heard?
No, and neither should you.
But tell me, why would I deliberately lie?
The guy that started the "new ssh exploit?" thread stated first he knew of an ISP *blocking* sshd traffic (this is far from an exploit).
Yes, that mail states that they are blocking *because* they had several boxes rooted from what *seemed* to be an sshd exploit.
Can you read at all?
So FU** YOU.
Charming.
I am sure that if you could count, you would tell me in how many ways as well.
SO BAD THERE ARE OTHER ARCHIEVES AROUND.
*plonk*
I don't know what you are smoking, but I will try to avoid your dealer.
I see *nothing* in what you wrote above, that casts any doubt on the correctness of what I posted. It was doubtful whether privsep would prevent the bug, and I stated that in the post to keep it correct.
What's your point? So far you've called me a liar, become my first slashdot "freak", and blurted all sorts of things about how unfair the world is to you. Why is it that we need to care about your oppinions? Do you have an oppinion at all? What are you trying to tell us here?
sshd is only granted the necessary access in order to receive user credentials. It therefore cannot access the disk, create network connections, or execute arbitrary programs.
Yes you can compromise sshd, but you will be left with the control over a process that can do virtually nothing.
This changes only when it provides real user credentials to the kernel.
It's mandatory access controls. And the above is why they can give you *real* security, not just 'I think my daemon is sorta secure and therefore trust it with my whole box'-security
I pieced the message together as soon as I had seen about five mails from slashdotted mailing list archives, in order to let people know what the status was at that time - thus the title of the post ("bits and pieces so far").
:)
One of the original posts in one of the threads stated, that there had been multiple successful attacks at an ISP which seemed to be SSH related. In this case they did run with privilege separation enabled.
As the thread evolved, it became clear that there was a vulnerability in SSH.
I therefore wrote that it seems that privilege separation does not help in this case. And I specifically wrote "seems" because it was not proven beyond a doubt, that the original attacks were indeed caused by this vulnerability, it only seemed "highly likely" from the thread.
I never meant to spread FUD - I tried as best I could to get the most information as was available at the time, out to the most people. And it is a lot safer saying "privilege separation might not be effective" than not mentioning that fact (it was a fact that it seemed not to be effective), and having someone believe that they were home free when maybe they weren't.
It should be pretty simple to examine the code to see if the buffer.c routines are used somewhere before the privsep code. I will leave that as an exercise to whoever cares, my sshds are updated now
What? No!
..., services from that machine? I don't!
vsftpd is defensible, given that it's an FTP server. And that's it.
Why do *I* need SSH, finger, DNS, PostgreSQL,
If you telnet to a known postgresql server and send it 'asdf', it will reply with 'EFATAL 1: invalid length of startup packet'. When you telnet to security.debian.org on it's postgresql port, it responds with exactly the same message.
So, to answer the other poster: it pretty much looks like a postgresql server - and it sure didn't firewall me away.
Nope. By the time we get close to 98%, we will have SELinux by default.
This bug, like any other non-kernel bug, is useless for an attacker on a system with mandatory access controls and a proper policy configuration.
The worms will need a kernel bug *and* a remotely exploitable bug to propagate.
It seems that you are right... Just one box. Impressive.
It's impressive in more ways than that - a quick nmap run shows that it has *heaps* of services running, freely available from the net. Among them, postgres, (some) named and SSH.
Apart from the single-point-of-failure problem, why on earth are we running updates from a machine with more holes than a swiss cheese?
Wouldn't it be pretty simple to find an exploit in one of the many services (I bet postgresql will have an overflow or two, having it available from the net is insane to put it mildly), upload a new backdoor'ed SSH package and, say, post a story to slashdot about an SSH hole?
(Yes it does seem that this particular SSH exploit is legitimate, because of references from other sites - the above was just an example).
Just a snippet from the nmap run
21/tcp open ftp
22/tcp open ssh
53/tcp open domain
79/tcp open finger
80/tcp open http
113/tcp open auth
487/tcp open saft
873/tcp open rsync
5432/tcp open postgres
To be found at:
http://unthought.net/ssh-vuln.html
An updated ssh package just hit the Debian security mirrors.
For anyone running debian stable:
apt-get update
apt-get upgrade
Yes, there is a vuln. in 3.6. You need to upgrade to 3.7 which was released today, to be safe (well, 'safer' anyway).
It will be 3.7p1 for us non-OpenBSD people.
It is a patch to one file, buffer.c, which fixes some allocation/offset stuff.
It seems that privilege separation does *not* help here - so get them systems patched (and firewalled)!
If Visual C++ goes away, there are other vendors who produce C++ compilers
:)
Ok, I just have to step in here with a correction
VC++ is not a C++ compiler - we have a large C++ project here and by the time we were spending hours on a daily basis getting VC++ to actually understand our ANSI C++ that other compilers had no problem understanding, we moved to the Intel C++ compiler for our windows port.
If VC++ went away, good riddance. The worst part is probably, that VC++ makes its users think they know C++ - boy, if you use VC++ you have not even touched the surface of what C++ can do.
Evolution has this virtual folder concept, which allows you to set up filters that will decide in which folders mail appear - allowing one mail to apper in multiple folders (but still only having one copy of the mail).
:)
Furthermore when you update the filters, your virtual folders are (of course, by means of the way that it is implemented) updated.
I used it for a while and it worked great. Until I started having more mail, then it started getting slow. Then it got really slow. I quit evolution entirely when it was unable to show any of the mails in my inbox, using virtual folders or not.
In short, the feature is in evolution, but if you have a lot of mail lying around (an inbox with 20-30k e-mails), it just doesn't work. Evolution has some nice features, they're just not implemented in a way so that they work on anything but toy mailboxes. Which is really a pity, since the ideas were great.
Now, I'm on bogofilter+procmail+kmail, and I'm fairly happy with that. No virtual folders, but I can read my mail again. Yippie!
While it's slick that they had a dual proc board and all... none of the tests they used used the dual proc-ness of the system. They even indicate in their results that the second proc just threw overhead into the system.
Those people do not have the faintest idea about what they are talking about.
First, of all - a dual processor Opteron is not SMP. It is NUMA. (The difference: SMP="Symmetrical Multi Processing", NUMA="Non Uniform Memory Access").
In an SMP system, multiple processors share access to the memory. In a NUMA system, you have a number of SMP or UP (uni-processor) systems (with their own local memory) and tie all these "nodes" together with some bad-ass interconnect.
In the dual Opteron case, you have two nodes (each with one CPU), and the HyperTransport as interconnect.
What this means is: If your operating system does not have a NUMA-aware scheduler - it may well schedule a process which resides in Node-0's memory to run on Node-1, causing slower memory transfers.
*This* might be a good reason why they saw lower numbers on their multi-processor runs.
Generally, you should see almost no slowdown when making a single-processor workload run on a multi-processor system, if the system is otherwise idle. But the above will explain it - XP does not have anything resembling NUMA awareness.
While it's slick that they had a dual proc board and all... none of the tests they used used the dual proc-ness of the system. They even indicate in their results that the second proc just threw overhead into the system.
Which, as someone else pointed out, is a rediculous request. Their hand-waving about how such software is expensive and requires tens of machines running, oh my oh my.
Boot a recent linux kernel. Run "make -j10" on some big source tree - like the kernel itself or KDE.
Not only would this be a very good multi-processor benchmark (on a kernel for which NUMA awareness in the Opteron case actually exist eiither in merged form or in the form of patches) - heck, it would even be A REAL WORLD WORKLOAD!
Politics:
the gentle art of getting votes from the poor and campaign funds from the rich by promising to protect each from the other.
-- Oscar Ameringer