Pause for effect whilst I scan through your responses..
Okay, the closest thing that I can find that even approaches an idea is:
Since we are on the issue, sure. Re-tool SMTP into an authentication based protocol, requiring your account's password to allow email to be accepted by your ISPs mail server, just as with POP
That's not going to help anything. What's to stop someone from just running their own SMTP server? The software isn't exactly hard to come by.
Even if you could work around that problem, the latest mass-mailing worm/virus is going to roll through/that/ little roadblock, no problem. MyDoom installed a keylogger and has access to every single file that the infected user does. Hence, as soon as they send an email any properly-coded worm will have access to the password and go on a little mailing spree.
By all means start or partake in a discussion trying to devise a sensible solution, but don't pretend that the answer is simple. You'll just look like an idiot.
How do you propose to secure SMTP? Precisely what architectual and/or cryptographic scheme do you propose that would work?
If I want to setup my own mailserver (not outside the realm of possibility, I'm a sysadmin) what hoops am I going to have to jump through to satisfy the Ultra Secure Email Lobbyists for Efficent Sending of Spam (USELESS)? Who do I go to if I believe someone is illicitly sending spam through their (presumably paid-for) email license?
How do you propose forcing every single ISP that they need to filter port 25? Those within the US? Those outside?
(And why bother if nobody uses SMTP anymore anyway?)
And that's just the start. If someone's machine get hits by a virus which spams people (or allows others to spam through that machine) how do I know that it was some evil guy and not Joe User who got compromised? How many people are even going to go through the expense of legal proceedings for the million-odd users out there with MyDoom on their machine?
Don't get me wrong, I don't think spam is fun. And I don't have a magic solution; I haven't even really thought about the problem.
But it's also clear that you haven't thought about it, either.
So unless you have an actual idea, or can point to someone who does, you're not going to garner that much interest.
"It's a great OS and it's stable" but you don't use it because XP is not-really-stable -- but good enough -- and it requires less maintenance from you. Presumably after you've installed all the software you need to use which would otherwise come bundled, like OpenOffice, Gaim and the others you mention.
And then you complain that managing 1000s of libs is a pain in the neck, saying "it needs to get a real system to distribute packages" -- after admitting that you use Slackware.
Users tend to ignore dialogs which pop up asking them for permission. Making something that is dangerous *look* dangerous is probably better, HCI-wise, than asking for permission when the user has already made up their mind that they want to see inside that file.
This was a social engineering attack. The main reason it worked was a) the message itself was believable and b) Outlook does a really shitty job of rendering attachments.
All you really need to add to Outlook to stop these things from working quite so well is a red flashing light next to the unsafe file so that even with a double-encoded extension, very long filename, or whatever other trick an attacker may use it is clear that you shouldn't open/execute that file.
The thing is, user training can only help you so much -- even if they're told that some classes of attachment are dangerous and shouldn't be touched, this attack (and hundreds before it) take advantage of bugs in Outlook so that it looks safe!
When they see a safe non-executable textfile in their email, what should they do? In this case, they shouldn't touch it! But that's an exception to the norm -- how can your users know what is safe and what isn't if their mail client can nolonger be trusted to represent reality accurately?
Herein lies the core problem, in this case at least: Outlook's UI.
It occurs to me that their network outage isn't necessarily being caused by a directed DDoS attack; as many have pointed out, that's only due to begin on Feb 1st.
Instead, it could be:
- Windows machines inside SCO itself which are saturating the network connection *sending* emails
- Windows machines outside SCO which are just sending lots of email to SCO's subnet causing additional network load.
- Someone at SCO taking advantage of the virus to do some network maintenance.
..etc. My prediction is that the DDoS has not yet even begun; how bad it will be depends on the actions of ISPs and sysadmins before it begins.
I've been playing with iCal and WEB-DAV servers recently for work, and I really like iCal. But one thing I discovered today is that the synchronization doesn't run both ways -- a subscribed can't updated a calendar that someone else has published.
Which is a shame, because it would be a lot better than the ad-hoc mechanisms I've got right now.
No, it really is that simple. The *reason* it is simple is that the Win32 API is not, at any point, involved.
The SFU implementation sits on top of the NT microkernel itself in parallel with the Win32 API. It sees all the processes on the system as described by the NT microkernel, including any Win32 applications. But the SIGKILL sent from the SFU universe goes straight to the NT microkernel interface, bypassing the Win32 API completely.
Cygwin is built on top of the Win32 APIs on top of the NT kernel core.
SFU is built straight on top of the core kernel; Win32 API variances (which have caused headaches for the Cygwin implementors of years) are no longer factored in.
Moreover, the core state information (such as process listings and various other things) come straight from the core. It is perfectly possible to send a SIGSTOP or a SIGKILL to Word.exe (a Win32 app) from the SFU universe and watch Word stop dead or die, respectively.
As well as NFS mounting and export capabilities, SFU also supports NIS and can do various user mappings between the Windows and Unix worlds.
Beware the default password set for some of these options.
Memo to self: no service that requires a password for security should be enabled by default with a standard initial passphrase.
For a lot of problems, having a fast network interconnect between the computation nodes is essential to getting good performance. The interconnects in the lab may not be enough.
That said, various software packages already exist to do opportunistic supercomputing using the spare resources in machines suitable for use in a lab -- Condor is one such package. We have it deployed in our computing labs, and several research groups in our department make use of it.
When we're both concentrating on whatever project that we're cooperating on, being able to send messages asynchronously to each other is fantastic as we can send replies to each other when we've finished a section of work.
Think of it as computer-assisted cooperative multitasking.:)
"I'm sorry I can't address your question for good remote filesystems in the face of an unreliable network."
I suspect what he means is that the core network within each site is reliable -- just that the linkage between the two or more storage nodes he has to manage may *not* be, and he wants to be able to recover gracefully in the event of the inter-site link going down and back up again.
The way we do it is that we have some underlying file store running on unix machines. At the moment we've got a couple Sun machines with large RAID arrays.
Then, to provide access to clients, we use Samba as a bridge to the Windows desktops and NFS for trusted linux clients; untrusted hosts can use SFTP or, if they just need read access, HTTP.
Having multiple storage nodes on multiple sites synchronized is a SAN, not client access, problem. NFS just doesn't provide multiple-node functionality. NFSv4 (link, link) may have some interesting features that could help; AFS was designed with multiple sites in mind and does intelligent caching and has other useful features over NFS but does have some limitations; and then there's things like IBM's Storage Tank which I haven't had a chance to look at properly yet.
Bottom line: If you have a flexible SAN infrastructure, you can use bridging nodes to provide access to the SAN tailored to whatever your clients require. The infrastructure is the hard part; with commodity packages like Samba client support is a much simpler seperate issue.
I take exception with some of the things you have written..
"It is my ass here that's on the line; I signed the NDA with Philips and if I goof up and accidently post the decompressor code or fail to protect it properly, I will be the one standing in court, not Linus."
Sure. You signed the contract, you have to deal with the consequences if you fail to do so. We're not forcing you to break your contract, there is no untenable situation here. If you find that you can't provide a non-GPL kernel module to support these cameras without breaking the law, then you're left with the option to simply stop doing so and walk away.
"You cannot force anyone to oblige by a volountary license (because that's what the GPL is: nothing more, nothing less)."
Sure. But if you want to play with the toys we built, you have to play by our rules as codified in the GPL. It's the law.
Linux is becoming more and more important to more and more people as time goes on. If some big important hardware manufacturer doesn't want to support their hardware on our platform of choice that's fine. It'll leave a wonderful opening for all of their competitors.
And if nobody wants to help, then reverse-engineering is still as valid an option as it always was.
What I don't understand is this: why don't Philips want a compression routine (which can be implemented in a 50kb kernel module) being public knowledge?
Don't get me wrong, your work is very much appreciated. But to be honest implementing a compression routine for video and audio feeds has been done before -- Philips's competitors aren't going to be losing sleep over what they might be missing.
And in the mean time, we've got to load this unmaintainable stuff just to be able to use our shiny camera. Don't get me wrong, I and others greatly value your work in implementing support for the hardware, compression spec and all.
But you knew what you were getting into when they started using the phrase "NDA". We lose out when we have to start using binary lumps to support the hardware we want to use, so don't be surprised if we decide it'd be a better use of our time long-term to just reverse-engineer the decompression routines in your driver rather than just put up with the current state of affairs.
Slashdot Mirror
How does that differ from a review?
Pause for effect whilst I scan through your responses..
Okay, the closest thing that I can find that even approaches an idea is:
That's not going to help anything. What's to stop someone from just running their own SMTP server? The software isn't exactly hard to come by.
Even if you could work around that problem, the latest mass-mailing worm/virus is going to roll through
By all means start or partake in a discussion trying to devise a sensible solution, but don't pretend that the answer is simple. You'll just look like an idiot.
How do you propose to secure SMTP? Precisely what architectual and/or cryptographic scheme do you propose that would work?
If I want to setup my own mailserver (not outside the realm of possibility, I'm a sysadmin) what hoops am I going to have to jump through to satisfy the Ultra Secure Email Lobbyists for Efficent Sending of Spam (USELESS)? Who do I go to if I believe someone is illicitly sending spam through their (presumably paid-for) email license?
How do you propose forcing every single ISP that they need to filter port 25? Those within the US? Those outside?
(And why bother if nobody uses SMTP anymore anyway?)
And that's just the start. If someone's machine get hits by a virus which spams people (or allows others to spam through that machine) how do I know that it was some evil guy and not Joe User who got compromised? How many people are even going to go through the expense of legal proceedings for the million-odd users out there with MyDoom on their machine?
Don't get me wrong, I don't think spam is fun. And I don't have a magic solution; I haven't even really thought about the problem.
But it's also clear that you haven't thought about it, either.
So unless you have an actual idea, or can point to someone who does, you're not going to garner that much interest.
"It's a great OS and it's stable" but you don't use it because XP is not-really-stable -- but good enough -- and it requires less maintenance from you. Presumably after you've installed all the software you need to use which would otherwise come bundled, like OpenOffice, Gaim and the others you mention.
And then you complain that managing 1000s of libs is a pain in the neck, saying "it needs to get a real system to distribute packages" -- after admitting that you use Slackware.
Worst. Critique. Ever.
Users tend to ignore dialogs which pop up asking them for permission. Making something that is dangerous *look* dangerous is probably better, HCI-wise, than asking for permission when the user has already made up their mind that they want to see inside that file.
Assuming, of course, that people who are reading slashdot would otherwise be doing something productive instead...
No.
This was a social engineering attack. The main reason it worked was a) the message itself was believable and b) Outlook does a really shitty job of rendering attachments.
All you really need to add to Outlook to stop these things from working quite so well is a red flashing light next to the unsafe file so that even with a double-encoded extension, very long filename, or whatever other trick an attacker may use it is clear that you shouldn't open/execute that file.
The thing is, user training can only help you so much -- even if they're told that some classes of attachment are dangerous and shouldn't be touched, this attack (and hundreds before it) take advantage of bugs in Outlook so that it looks safe!
When they see a safe non-executable textfile in their email, what should they do? In this case, they shouldn't touch it! But that's an exception to the norm -- how can your users know what is safe and what isn't if their mail client can nolonger be trusted to represent reality accurately?
Herein lies the core problem, in this case at least: Outlook's UI.
Instead, it could be:
- Windows machines inside SCO itself which are saturating the network connection *sending* emails
- Windows machines outside SCO which are just sending lots of email to SCO's subnet causing additional network load.
- Someone at SCO taking advantage of the virus to do some network maintenance.
Bait.
Switch.
I've been playing with iCal and WEB-DAV servers recently for work, and I really like iCal. But one thing I discovered today is that the synchronization doesn't run both ways -- a subscribed can't updated a calendar that someone else has published.
Which is a shame, because it would be a lot better than the ad-hoc mechanisms I've got right now.
No, it really is that simple. The *reason* it is simple is that the Win32 API is not, at any point, involved.
The SFU implementation sits on top of the NT microkernel itself in parallel with the Win32 API. It sees all the processes on the system as described by the NT microkernel, including any Win32 applications. But the SIGKILL sent from the SFU universe goes straight to the NT microkernel interface, bypassing the Win32 API completely.
I strongly suspect that any SCO representative entering our building would be considered persona non grata, and ejected.
:-)
And I don't mean by the front door.
There's a more important architectual difference.
Cygwin is built on top of the Win32 APIs on top of the NT kernel core.
SFU is built straight on top of the core kernel; Win32 API variances (which have caused headaches for the Cygwin implementors of years) are no longer factored in.
Moreover, the core state information (such as process listings and various other things) come straight from the core. It is perfectly possible to send a SIGSTOP or a SIGKILL to Word.exe (a Win32 app) from the SFU universe and watch Word stop dead or die, respectively.
As well as NFS mounting and export capabilities, SFU also supports NIS and can do various user mappings between the Windows and Unix worlds.
Beware the default password set for some of these options.
Memo to self: no service that requires a password for security should be enabled by default with a standard initial passphrase.
For a lot of problems, having a fast network interconnect between the computation nodes is essential to getting good performance. The interconnects in the lab may not be enough.
That said, various software packages already exist to do opportunistic supercomputing using the spare resources in machines suitable for use in a lab -- Condor is one such package. We have it deployed in our computing labs, and several research groups in our department make use of it.
Cheers,
David
You might be thinking of Sun Grid Engine, an open-source project sponsored by Sun which does cluster-level load balancing and other tricks.
Cheers,
David
And it's not stupid, and it's actually helpful.
:)
When we're both concentrating on whatever project that we're cooperating on, being able to send messages asynchronously to each other is fantastic as we can send replies to each other when we've finished a section of work.
Think of it as computer-assisted cooperative multitasking.
Thus I suspect "BSD is undead" would be a more accurate moniker.
libcaca is your friend. :)
"Anyway, my original point; bringing back a series after it's been cancelled is unnatural"
It worked for Star Trek.
"I'm sorry I can't address your question for good remote filesystems in the face of an unreliable network."
I suspect what he means is that the core network within each site is reliable -- just that the linkage between the two or more storage nodes he has to manage may *not* be, and he wants to be able to recover gracefully in the event of the inter-site link going down and back up again.
The way we do it is that we have some underlying file store running on unix machines. At the moment we've got a couple Sun machines with large RAID arrays.
Then, to provide access to clients, we use Samba as a bridge to the Windows desktops and NFS for trusted linux clients; untrusted hosts can use SFTP or, if they just need read access, HTTP.
Having multiple storage nodes on multiple sites synchronized is a SAN, not client access, problem. NFS just doesn't provide multiple-node functionality. NFSv4 (link, link) may have some interesting features that could help; AFS was designed with multiple sites in mind and does intelligent caching and has other useful features over NFS but does have some limitations; and then there's things like IBM's Storage Tank which I haven't had a chance to look at properly yet.
Bottom line: If you have a flexible SAN infrastructure, you can use bridging nodes to provide access to the SAN tailored to whatever your clients require. The infrastructure is the hard part; with commodity packages like Samba client support is a much simpler seperate issue.
"Yeah sure! It's still buggering me to download the patch."
Well, I'm pretty sure that isn't going to work..
Is there some reason you can't do it yourself? The act of sticking your foot in your mouth and then shooting is surely in the public doma...
*thinks about SCO*
Never mind...
I take exception with some of the things you have written..
"It is my ass here that's on the line; I signed the NDA with Philips and if I goof up and accidently post the decompressor code or fail to protect it properly, I will be the one standing in court, not Linus."
Sure. You signed the contract, you have to deal with the consequences if you fail to do so. We're not forcing you to break your contract, there is no untenable situation here. If you find that you can't provide a non-GPL kernel module to support these cameras without breaking the law, then you're left with the option to simply stop doing so and walk away.
"You cannot force anyone to oblige by a volountary license (because that's what the GPL is: nothing more, nothing less)."
Sure. But if you want to play with the toys we built, you have to play by our rules as codified in the GPL. It's the law.
Linux is becoming more and more important to more and more people as time goes on. If some big important hardware manufacturer doesn't want to support their hardware on our platform of choice that's fine. It'll leave a wonderful opening for all of their competitors.
And if nobody wants to help, then reverse-engineering is still as valid an option as it always was.
What I don't understand is this: why don't Philips want a compression routine (which can be implemented in a 50kb kernel module) being public knowledge?
Don't get me wrong, your work is very much appreciated. But to be honest implementing a compression routine for video and audio feeds has been done before -- Philips's competitors aren't going to be losing sleep over what they might be missing.
And in the mean time, we've got to load this unmaintainable stuff just to be able to use our shiny camera. Don't get me wrong, I and others greatly value your work in implementing support for the hardware, compression spec and all.
But you knew what you were getting into when they started using the phrase "NDA". We lose out when we have to start using binary lumps to support the hardware we want to use, so don't be surprised if we decide it'd be a better use of our time long-term to just reverse-engineer the decompression routines in your driver rather than just put up with the current state of affairs.
Then simply ask them to release the bits they can, and put comments in the holes indicating what the we need to implement.
If you can't do that, then simply ask them to release the hardware interface specifications. Then we can try writing the whole damn driver ourself.
Wailing that "some of the code in our driver isn't ours" is no excuse. Release what you do have.