As a simple end user who isn't getting much if anything out of the usually promoted solutions such as apparmor, I must say I find the attitude expressed by the experts here in response to the OP highly regrettable.
I for one, would greatly appreciate a solution that let me simply create a rule "This application can't access the internet". I've tried achieving this with apparmor, by doing a test on so constraining Opera, to no effect (and have posted about it in a thread a few weeks ago). Perhaps this can be done with ufw/iptables, but I haven't managed to work it out.
Again, to all the experts, please accept that some of us are too busy accomplishing "real world" tasks with Linux and don't have the time or the inclination to learn complex solutions. We do need simple and powerful options as suggested by the OP. Maybe Tuxguardian isn't the right tool, but the idea is sound.
The development framework for the desktop environment is modular. Software that needs to access the internet is created specifically to access the internet and says so in its descriptions. For example, if something is running in a web browser, it will be accessing the internet. A weather applet installed in the panel or on a dock is going to be accessing the internet. Same for an applet that alerts on new mail. An IM client is going to as well. Those applications are made to do that.
Things like word processors and other productivity applications probably don't need to most of the time, and so they won't. When there's an active link in a PDF or doc file, it will open a browser if there's not one already open, rather than simply connecting itself (well, except for Adobe Reader, which for whatever reason allows the running of scripts and can access the web directly, but that's just bad design and there are alternatives).
Shell scripts can be read as text files before running them to see what they do. If they can't be, or if they're obfuscated or encoded in some weird way, then we all have the option to not run them.
I'm sorry to come across as so exasperated, but I'm having a difficult time understanding exactly what purpose an application based firewall would really serve. I think it would be easier to constrain things on an individual basis, if it's necessary to do so at all. It's probably easier to get support for specific tasks/constraints on specific applications as well.
I'm absolutely no expert on this topic, on the contrary im a complete n00b. But the general idea of linux being safe out of the box and that there is a discussion whether it's possible to hack this or that instead of WHEN it's going to happen seems rather distant to me. (again im no expert so feel free to unload your expertise on me. I need the education).
I mean a 14 year old hacked FBI. Seems to me most things are possible in this digital world!
Without a firewall I think you are virtually exposed to the hackers with or without Linux environment. I've used TuxGuardian in the past and I think is a pretty well application for computer security.
Yes indeed a firewall should be required anyway but not as a software which probably is even running in user space on the machine itself. A nice OpenBSD box for example behind the router (or if versed enough even as the router) would be optimal.
A firewall really doesn't do anything on a default installation, as there are no ports open to the outside world, and if you are behind a router, it's a belt + suspenders type of activity.
it's just like the poster earlier that tried to block Opera from accessing the Internet. Web browsers and many other programs use random high ports for out going connections, so it's pretty hard to block a port if you don't know which one it is using, and it changes every time you use a program, have a look at this example:
I've bolded the outgoing ports, these change every time a program is opened.Code:
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.215:43915 220.127.116.11:5222 ESTABLISHED
tcp 0 0 192.168.1.215:56053 192.168.1.235:22 ESTABLISHED
tcp 0 0 127.0.0.1:7634 127.0.0.1:53732 TIME_WAIT
tcp 1 0 192.168.1.215:44341 18.104.22.168:80 CLOSE_WAIT
tcp 1 0 192.168.1.215:51431 22.214.171.124:80 CLOSE_WAIT