No. IPC is dirt cheap. Take X11 for example -- that's perfectly usable using plain old named pipes, even without Xshm.
Most of the time, a threaded GUI program will want to use threads in order to perform some operation or another "in the background" while the UI remains responsive. If this operation has well-defined inputs and outputs, why not write it as a separate program? Communication overhead is going to be low.
You don't need a book about threaded programming in Python.
You need two books: one about Python, one about threads. Concepts are universal and can be applied across as many languages as you want. It's like saying you need to re-take Calculus because you just learned French!
You want to charge to messages sent to your SMTP server? Okay, you go first. Unless you run aol.com, gmail.com, or yahoo.com, I don't think you're going to get much traction. Perhaps not even then.
You'd have to either arrange payment details for every communicating pair of SMTP servers or provide a clearing-house. Who's going to run this clearing house? And wouldn't it be in the clearing-house's interest to either see spam (and their their fees) increase, or to simply charge people per legitimate email? If you're willing to go that far, simply charging people per email would have the same effect on spam.
Keep in mind that people don't press the "spam" button. Most of the time, they just delete spam messages like other messages. The financial penalty for a spam message would have to take into account the low likelihood of the message being reported by a given user.
Also, it doesn't address botnets. In fact, it further exacerbates that problem. Now, instead of a user's computer being hijacked to send spam, it's hijacked to send spam and drain the user's bank account.
Maybe, maybe, consider header a saying 'This is for real, cryptographically-signed ClearingHouse: "I'm [foo@example.com]-0x54afafa and I guarantee this message is not spam. If it is, I agree to pay you $10 minus clearing-house fees, cryptographically-signed SomeCompany"'
If you attach that header, your spam score on heuristic filters would decrease markedly. If you forged the header, you'd be marked as spam instantly. (Since everyone using this system would have ClearingHouse's public key on file.)
A cleaner version of the link of thing you suggest is hashcash. The idea is that you force anyone using your service to invest certain resources, with the idea being the investment would be acceptable for a single user, but unacceptable for a massive attack.
The problem with hashcash, though, is that computing power is dirt cheap, especially in this day of botnets. The Storm botnet, taken as a whole, peaked last year as one of the world' most powerful computers.
I think we'll be able to come up with a captcha system that works reasonable well for reasonable periods, making using word problems, cultural questions, or some kind of clever pattern recognition problem. (Of course, any captcha is going to discriminate against somebody: the blind, the deaf, the dumb, the ignorant, etc. Unfortunately, that's a fact of life.)
I think we're better off in the long run destroying the economics of spam than continuing this arms race. Unfortunately, destroying the economics of spam requires regulation and legislation.
The porn hole is still a big problem though, and there's really no way around that. You can think of various cryptographic schemes, sure, but fundamentally, a capcha still relies on something transmitted to our sense organs. And what we can transmit, we can easily record and replicate elsewhere.
I was wrong. Your original comment marked you as being ignorant.
It's your reply that reveals your abject stupidity. Even if your links supported your ridiculous assertion, you'd be arguing by appeals to authority. Since they don't, you're arguing by appeals to a lack of reading comprehension.
I think the difference is that CyberSecure's model is generated from usage, while this package's model is generated with static analysis.
I'm leery about usage-based profiling. What if there's a perfectly legitimate code path that the program just doesn't take while you're generating the profile? The program could be killed for something innocuous. I don't want that danger.
The nice thing about static analysis is that it's always correct!
You're right. You can't exactly predict the behavior of a program without running it.
But that's not what this package is trying to do. Instead, it's trying to rule out large swaths of the behavior space of a program based on static analysis. Of course there will be false negatives -- i.e., malicious actions that remain undetected. But I don't really see how false positives would be a danger, modulo bugs in the static analyzer.
I imagine this package would be nearly useless for something like firefox, which does many varied tasks. But for programs like exim, or bind, or vsftp -- which do one task over and over again -- the degree of protection should be pretty good because there's a lot these programs don't do.
While desktop Linux doesn't have the same malware problems as Windows, we still have problems with random server programs being compromised. This approach is actually, I think, more effective on the server than the desktop.
Firefox, say, has a much larger variety of behavior than bind. Firefox can do anything; bind does the same thing over and over and over.
Since Firefox does more varied stuff, this system call profiling approach would see more of its behavior as "normal". But because bind does the same thing over and over, almost every behavior is outside that norm, and would be caught.
If they modified Linux kernel, they modified then the Linux operating system and not just kernel, because Linux is monolith kernel and not microkernel...
You're an idiot. Regardless of whether the kernel is a microkernel or a monolithic block, there's a separation between kernel and userland. The operating system is userland plus the kernel. Yes, they modified parts of the operating system outside the kernel, but that's beside the point.
It has nothing to do with the distinction between a microkernel and a monolithic kernel.
Why couldn't malware makers then just insure their programs emulate this profile?
No, because the whole point of malware is getting a program to do something other than what it's supposed to do, and the profile describes, well, what the program's supposed to do.
It can't catch every case, but it can rule out a lot of system calls. If setuid never appears in a program or library's source, it can't be called. If a program calls a bunch of things in an initializer function and then enters a more restricted main loop, the static analyzer should be able to catch that too.
I can't see how this approach could hurt, though of course it won't catch everything.
It's more clever than that. Imagine a program always called select(), read(), and write() in that order. Through static analysis at compile time, you guarantee that's all the program should be doing. If you observe the program run select(), setfsid(), write(), it can't be running the code it was compiled with, and so it should be killed.
Do you have a source? Who is "Ford" here?wouldn't help much.
Also, all fuel additives have the same basic problem: if they really helped, fuel manufacturers would add them to the fuel themselves to differentiate themselves from their competitors.
Commercial gasoline is already full of additives that help engine performance, emissions, and so on. That whatever you're buying off the shelf is not in the gasoline already indicates that that particular substance doesn't help.
Thanks. I appreciate when a well-versed person can teach me a few things.
Large correction: the transport layer port numbers are not canonically part of the IP header
Just for the record, I knew that the port wasn't in the IP header itself: my post was more a conceptual overview than a technical guide.
[snip information about Apple telnet]
I'm glad that more programs are using SRV records; they make the most of a bad situation.
Your point (4) is answered through uPNP which is pervasive, and NAT-PMP which is fairly common, lightweight, and robust against intermediate system or end system crashes.
Yep. They even work some of the time, though I imagine that nobody would deploy a system that required uPNP to work -- there are too many installations that ignore it.
If you want to make busywork for yourself, that's your business. But don't inflict NAT on the internet for that. There are a thousand ways you could achieve the same kind of double-checking with a firewall configuration. (Paperwork comes to mind.)
As for firewalls -- you wouldn't put a firewall on each server. That's silly. With public IPs, you put a firewall in the same place the NAT gateway. You can configure it to block everything incoming by default.
Then, if you wanted, you could use packet filtering on individual machines behind the primary firewall. How is that outcome any less secure than NAT?
Slashdot Mirror
No. IPC is dirt cheap. Take X11 for example -- that's perfectly usable using plain old named pipes, even without Xshm.
Most of the time, a threaded GUI program will want to use threads in order to perform some operation or another "in the background" while the UI remains responsive. If this operation has well-defined inputs and outputs, why not write it as a separate program? Communication overhead is going to be low.
You don't need a book about threaded programming in Python.
You need two books: one about Python, one about threads. Concepts are universal and can be applied across as many languages as you want. It's like saying you need to re-take Calculus because you just learned French!
You want to charge to messages sent to your SMTP server? Okay, you go first. Unless you run aol.com, gmail.com, or yahoo.com, I don't think you're going to get much traction. Perhaps not even then.
You'd have to either arrange payment details for every communicating pair of SMTP servers or provide a clearing-house. Who's going to run this clearing house? And wouldn't it be in the clearing-house's interest to either see spam (and their their fees) increase, or to simply charge people per legitimate email? If you're willing to go that far, simply charging people per email would have the same effect on spam.
Keep in mind that people don't press the "spam" button. Most of the time, they just delete spam messages like other messages. The financial penalty for a spam message would have to take into account the low likelihood of the message being reported by a given user.
Also, it doesn't address botnets. In fact, it further exacerbates that problem. Now, instead of a user's computer being hijacked to send spam, it's hijacked to send spam and drain the user's bank account.
Maybe, maybe, consider header a saying 'This is for real, cryptographically-signed ClearingHouse: "I'm [foo@example.com]-0x54afafa and I guarantee this message is not spam. If it is, I agree to pay you $10 minus clearing-house fees, cryptographically-signed SomeCompany"'
If you attach that header, your spam score on heuristic filters would decrease markedly. If you forged the header, you'd be marked as spam instantly. (Since everyone using this system would have ClearingHouse's public key on file.)
A cleaner version of the link of thing you suggest is hashcash. The idea is that you force anyone using your service to invest certain resources, with the idea being the investment would be acceptable for a single user, but unacceptable for a massive attack.
The problem with hashcash, though, is that computing power is dirt cheap, especially in this day of botnets. The Storm botnet, taken as a whole, peaked last year as one of the world' most powerful computers.
I think we'll be able to come up with a captcha system that works reasonable well for reasonable periods, making using word problems, cultural questions, or some kind of clever pattern recognition problem. (Of course, any captcha is going to discriminate against somebody: the blind, the deaf, the dumb, the ignorant, etc. Unfortunately, that's a fact of life.)
I think we're better off in the long run destroying the economics of spam than continuing this arms race. Unfortunately, destroying the economics of spam requires regulation and legislation.
The porn hole is still a big problem though, and there's really no way around that. You can think of various cryptographic schemes, sure, but fundamentally, a capcha still relies on something transmitted to our sense organs. And what we can transmit, we can easily record and replicate elsewhere.
What makes you think a spammer won't just send fake keystroke times? Never trust the client.
Why the fuck shouldn't it be free to see the court order?
I was wrong. Your original comment marked you as being ignorant.
It's your reply that reveals your abject stupidity. Even if your links supported your ridiculous assertion, you'd be arguing by appeals to authority. Since they don't, you're arguing by appeals to a lack of reading comprehension.
Firefox might open /dev/{sounddevice}. And Firefox can't call chroot anyway: it's not running as root.
Your comment illustrates perfectly why application profiles should be created by static analysis and not humans.
I think the difference is that CyberSecure's model is generated from usage, while this package's model is generated with static analysis.
I'm leery about usage-based profiling. What if there's a perfectly legitimate code path that the program just doesn't take while you're generating the profile? The program could be killed for something innocuous. I don't want that danger.
The nice thing about static analysis is that it's always correct!
You're right. You can't exactly predict the behavior of a program without running it.
But that's not what this package is trying to do. Instead, it's trying to rule out large swaths of the behavior space of a program based on static analysis. Of course there will be false negatives -- i.e., malicious actions that remain undetected. But I don't really see how false positives would be a danger, modulo bugs in the static analyzer.
I imagine this package would be nearly useless for something like firefox, which does many varied tasks. But for programs like exim, or bind, or vsftp -- which do one task over and over again -- the degree of protection should be pretty good because there's a lot these programs don't do.
"Malware" is an unfortunate choice of words here.
While desktop Linux doesn't have the same malware problems as Windows, we still have problems with random server programs being compromised. This approach is actually, I think, more effective on the server than the desktop.
Firefox, say, has a much larger variety of behavior than bind. Firefox can do anything; bind does the same thing over and over and over.
Since Firefox does more varied stuff, this system call profiling approach would see more of its behavior as "normal". But because bind does the same thing over and over, almost every behavior is outside that norm, and would be caught.
You're an idiot. Regardless of whether the kernel is a microkernel or a monolithic block, there's a separation between kernel and userland. The operating system is userland plus the kernel. Yes, they modified parts of the operating system outside the kernel, but that's beside the point.
It has nothing to do with the distinction between a microkernel and a monolithic kernel.
No, because the whole point of malware is getting a program to do something other than what it's supposed to do, and the profile describes, well, what the program's supposed to do.
It can't catch every case, but it can rule out a lot of system calls. If setuid never appears in a program or library's source, it can't be called. If a program calls a bunch of things in an initializer function and then enters a more restricted main loop, the static analyzer should be able to catch that too.
I can't see how this approach could hurt, though of course it won't catch everything.
It's more clever than that. Imagine a program always called select(), read(), and write() in that order. Through static analysis at compile time, you guarantee that's all the program should be doing. If you observe the program run select(), setfsid(), write(), it can't be running the code it was compiled with, and so it should be killed.
Do you have a source? Who is "Ford" here?wouldn't help much.
Also, all fuel additives have the same basic problem: if they really helped, fuel manufacturers would add them to the fuel themselves to differentiate themselves from their competitors.
Commercial gasoline is already full of additives that help engine performance, emissions, and so on. That whatever you're buying off the shelf is not in the gasoline already indicates that that particular substance doesn't help.
So that means you could have gotten better fuel economy with the same horsepower, right? I would have made that choice, personally.
Thanks. I appreciate when a well-versed person can teach me a few things.
Just for the record, I knew that the port wasn't in the IP header itself: my post was more a conceptual overview than a technical guide.
I'm glad that more programs are using SRV records; they make the most of a bad situation.
Yep. They even work some of the time, though I imagine that nobody would deploy a system that required uPNP to work -- there are too many installations that ignore it.
Oh. I missed the "on the same network" bit. In that case, you're right.
Then again, every firewall should be using ingress and egress filtering regardless of whether it also performs NAT functions.
ICMP is another important feature. Sure, things sort of limp along without it, but with reject messages and path MTU discovery, things work better.
Besides, dropping ICMP traffic doesn't actually get you any security. You can scan the network perfectly well with connect(2).
Not if you disable IP source-routing you can't.
Many things make "sense" with familiarity and lack of exposure to better alternatives.
If you want to make busywork for yourself, that's your business. But don't inflict NAT on the internet for that. There are a thousand ways you could achieve the same kind of double-checking with a firewall configuration. (Paperwork comes to mind.)
As for firewalls -- you wouldn't put a firewall on each server. That's silly. With public IPs, you put a firewall in the same place the NAT gateway. You can configure it to block everything incoming by default.
Then, if you wanted, you could use packet filtering on individual machines behind the primary firewall. How is that outcome any less secure than NAT?
IP addresses can already be tied semi-reliably to individuals. That's why we have Tor, which works just as well in an IPv6 world.
So why do you need NAT instead of a non-translating firewall?