Overall comment: Linda, saying something three times in a row doesn't make it true. On Tuesday 21 March 2006 22:55, Linda Walsh wrote:
The above says it all: instead of having an interactive tool that requires the interactive user's permission, most Linux users have to rely on a "log file" -- that _retrospectively_ will tell you what has happened on your box.
It doesn't allow you to permit/deny traffic in real time, nor does it allow real-time interactive firewall rule construction based on usage.
This idealistic talk about real time neglects three important things: firstly, I dare you to show me one single windows user of any experience level who hasn't gone mad at the constant popups from zonealarm and just presses "allow always" to the outbound requests from Internet Explorer, thus completely disabling any and all protection this tool may have given you Secondly, you're assuming that virus writers don't know how to bypass ZoneAlarm. Dangerous assumption In this overlong rant you're also mixing talk of inbound and outbound connections. Well, here's a LART for you: I can put a SUSE box online for a year completely unattended, and I'll put up a cash prize of one million US dollars for anyone gaining access to it. You know how I can be so bold? Because a machine that doesn't accept connections can't be hacked. An out of the box SUSE installation will not listen to external ports. Even ssh is blocked by default. And if a windows user sets up a server on his desktop machine where he is a console user, he will press the "Allow Always" button in ZoneAlarm every bit as much as he would simply open the port in SuSEfirewall2 on a SUSE box
I find the discussion about how the user should or shouldn't be doing things amusing -- i.e. "Dear ex-windows user: um, we don't have the features and abilities you want, so we want to educate you on what you think you should want and give you lots of reasons why what you want doesn't really protect you (which is what we wanted to tell you what you really wanted)." Bleh!
"I want a nuclear bomb so I can get rid of the moles from my back yard" Now now, don't tell this person that a nuke isn't the best way to fight moles, give the man what he wants. right?
To get back to the Original Poster's article -- and some people's claim that *nix doesn't provide real-time monitoring and permission grants to interactive users only shows the lack of flexibility of the *nix model.
Not really, people's claiming it doesn't make it so. It can be done.
1) identify what process is attempting unauthorized access. (remember, the process may be owned by any user -- not just the "logged in user).
AppArmor does this as part of its basic functionality
2) display a high priority popup on the ... well...who? The primary console user's terminal? What if someone is running "Citrix" or logged in via Terminal Services? Who gets the message? In Windows, it is the console user.
This is yet another place where it breaks down, of course. If you're talking about Citrix and Terminal Services then you're not talking about a regular home user. Using ZoneAlarm in a company setting is just silly
3) Allow the Console user to decide if the "arbitrary process" (good chance it isn't owned by the user) should be granted the appropriate access. Same with incoming connections -- they are probably going into some "system process" (response to "bind/dns", incoming "email" handled by sendmail, etc).
Oh yeah, and you'll be spending 90% at least of your day clicking on popup buttons if you're going to require interactive response to IP packets on the level of dns responses. And incoming email handled by sendmail????????? Are you seriously suggesting using ZoneAlarm on a mail server? No way, under any circumstances on any OS
4) Allow the "unprivileged" user to decide on network access for some non-user owned (likely, system level) process. Ex. I just use a browser to look at a site. Say it is configured to use a proxy (squid). I see a message that squid wants an outside line. Do I allow it? Is it my browser? If I do allow it, squid is allowed for all users and all processes -- it isn't just my browsing. Suppose I choose to allow it - some firewall rule (running with system privileges) needs to be modified. This means my "interactive popup" is allowed to modify system firewall tables? That breaks the fundamental user-superuser separation on *nix.
Indeed, and in this model it wouldn't work even on windows.
5) To modify firewall rules, the user must (at least temporarily) be running with system (root) privileges. You've violated *nix's main protection.
Not at all. This isn't the year 2000 anymore. Capabilities do work now
6) If the *nix system is running "X", more than one user may be running a console session. How will you trace what "outgoing connection attempt" is related to which user (if any). How will these users decide on which non-user utils get access?
Simple, they won't. And you won't find many multi-user windows boxes using ZoneAlarm either
Bottom line: I submit that you can't require instantaneous user interaction on *nix and have the system function "normally".
And I submit that in the silly circumstances you picture, you can't do it on any OS Most network activity on
a *nix system happens on *behalf* of a user -- maybe no specific user, but just as part of making the *nix system responsive and robust. You can't provide something as convenient as "ZoneAlarm" on Linux without _alot_ of work and a violation of the *nix system design.
And I put it to you that AppArmor is just that, and done in a way that makes sense even on a multiuser platform
If you create the support structure necessary to support such "automation", including the ability to click on mail attachments like ".pdf" and have them auto-open acrobat
which of course already exists
you create the same opportunity for "holes" in *nix as in WinNT bases systems.
No, those come with scripting, and trust in extensions. Just having a pdf open in acroread won't do any damage, but if acroread suddenly acquired a scripting capability on the level of MSOffice, then yes, it could happen. Also, linux generally looks at a file to determine what it is, so a file.exe.gif won't be misinterpreted
Do you need more examples?
Yes please
Note -- manual, human-based *logfile review* is _unacceptable_. It is _reactive_, time consuming and error prone. In the one-hour between being mailed "logs", a well qualified hacker could be in, plant a trojan and clean up the logs to remove a trace of their being there. If you have to sleep or go on a vacation for any number of days, you have even less responsiveness to intrusions.
Since you mentioned sendmail above, I'm just picturing you sitting by an exchange server, feverishly clicking "yes, allow" every time an incoming email comes in. Does it pay well?
Sorry, but in my opinion, Linux is considerably more lacking in real-time, interactive security response tools that talk to the active user. In the absence of a real-time, at the console user, traffic is *blocked*. This is very *untrue* for the average *nix system, where systems are expected to run "unattended".
So are most windows servers. You really can't mix the server and desktop environments and expect a sane discussion
None of this should be taken to mean that Linux, as used today is less secure than Windows -- but it easily could be if it was _configured_ to be as easily interoperable as WinNP is (by requirement of legacy compatibility) to be.
Nah, interoperability has nothing to do with it. Compatibility in the user experience, to a certain extent (users expect things to behave in a certain way, even if it kills them) but it could be done safely. Sure, things like ActiveX need to die, and the scripting capabilities of certain things should be cut down, or at least placed in a sandbox, but it can be done
FYI -- I do have linux log files that show me blocked outgoing firewall traffic. It isn't uncommon to see applications (running on Windows through a linux proxy server) to simply and mysteriously "not work". It's only later, if I examine log files and remember what I was doing at the time, do i find that I couldn't watch some "video" because my firewall blocked outgoing ports by my "http-proxy" (squid) to some site. It is rare that I know why the application(s) failed at the time they fail -- there is no interactive message to tell me that a forbidden network traffic type is being automatically blocked. That is way less usable (and useful) than having a popup instantly tell me that my attempt to play some video is accessing some weird port, that isn't in the normal video port range.
I lost you. How is any system supposed to determine what is running *on a different machine*? Not gonna work, not on windows, or on linux. If you have a separate firewall, it's not going to be able to decide if it's internet explorer or MYDOOM.EXE requesting outbound access. Also, what is "the normal video port range"? I wasn't aware that outbound had any sort of defined range (other than 1024-65535) either on windows or linux -- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net