Mailinglist Archive: opensuse (3100 mails)
| < Previous | Next > |
Re: [SLE] Re: SUSE Firewall primitive shadow of ZoneAlarm in interactive user-control
- From: Anders Johansson <andjoh@xxxxxxxxxx>
- Date: Tue, 21 Mar 2006 23:38:26 +0100
- Message-id: <200603212338.26698.andjoh@xxxxxxxxxx>
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@xxxxxxxxxx
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@xxxxxxxxxx
| < Previous | Next > |