[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Firewalls and inter-team communication, was: Browser mode for nautilus



Hi all,

I've added fedora-devel-list to Cc as this topic isn't really limited to
the desktop.

On Mon, 2008-10-27 at 22:48 +0100, Lennart Poettering wrote: 
> On Mon, 27.10.08 15:29, Stephen John Smoogen (smooge gmail com) wrote:
> 
> > > Having desktop firewalls is security theatre. Having 20 levels of
> > > false and inappropriate security is worse then having a single level
> > > of security that is appropriate for the task.
> > 
> > My guess is that having priv-sep, passwords, etc are all security
> > theatre for the desktop user in this case. I mean if application X
> > can't work without me being root then why not be root? If having a
> > password slows me down from getting stuff done, why not remove it. For
> > this level.. why are we doing anything beyond Windows 98 which seems
> > to be the perfect desktop platform.
> 
> You are making stupid generalizations here, and you know that.
> 
> Please don't talk to to me like I was a complete moron or
> something. In Avahi for example (which I wrote) I went into great
> lengths to run the code in an environment that is as confined as
> possible. We use stuff like chroot(), capabilities, we run as seperate
> user with minimal resource limits and stuff like that, so that even
> without SELinux an exploited Avahi does not allow attackers to exploit
> the entire system.
> 
> In fact, on my F10 system here that runs a lot of stuff in addition to
> the standard install, Avahi is still the *only* process which does
> all that security stuff. No other daemon employs chroot() or anything
> similar. So please, don't tell me I had no clue about how to secure
> daemons on Linux.

A bit off-topic for what's really my concern with this mail, but anyway:
that's probably because chroot() is seen by many as not being a security
tool(*), i.e. it's giving a false sense of security that should be
avoided, which would be consistent with comments made in this thread.

(*): In short: If the process can or is run as root, it can escape a
chroot "jail", if it's running as a normal user, it can't really do the
bad things a chroot environment would inhibit.

What I find a bit puzzling is that many people in this thread made
comments about the firewall being broken (or breaking something on the
desktop), but nobody thought about maybe inviting the iptables package
maintainer to this discussion. I happen to know him and if one --
depending on the POV -- might accuse him of not being exactly open
minded for all proposals coming out of the desktop corner, it's probably
because he'd rather err on the side of caution than be sorry later.

In general I'd very much suggest, when it comes to things that affect
areas other than one's own, to involve the affected persons or teams
early on in the discussion. If one discusses such matters only in one's
own "cabal" -- and I'm using that word with care, because that's exactly
how it's come across in a few instances -- and if one only after the
discussion is over presents something fait-accompli style to the rest of
the world, it very much begs for being shot down. Let me compare this to
casting concrete when parts of it have already begun setting, the result
surely won't be stable or homogenous.

The reason for that is quite simple, it basically boils down to that
nobody is super-human: We all make mistakes. To a certain degree, we
tend to concentrate on the stuff we're most experienced with and miss
things in other areas. Likewise, more often than not we put more
priority on issues that more visibly affect our own turf than on other
things and neglect how our own approach to a certain problem is
detrimental in other use cases. We all occasionally can't see the wood
for the trees.

> Use the appropriate tools for locking things down. Don't add
> protection that is bogus because it will be overriden by the user
> anyway. I am very sure that exactly 0% of all users deactivate all the
> security techniques that Avahi uses -- because they have no reason
> to. Because it doesn't limit the use of AVahi in any way -- it doesn't
> go against what users want to do.

Just as a side note, you've very carefully left out people disabling
avahi because it broke other things. Right on cue just this week, a
colleague disabled avahi on a server where its adding a route into the
169.something auto-IP network made it unreachable in the network, maybe
because that machine (for security reasons) didn't have a default
gateway. The machine in question is RHEL5, so any misbehavior on part of
avahi may be fixed by now, but this is still a good example for a
component unintentionally breaking basic functionality because its
possible impacts in "out of scope" use scenarios weren't fully assessed.
Needless to say that the colleague didn't ask for avahi to be installed
(it doesn't make much sense on a server), it got dragged in by
dependencies.

But I'm digressing: My plea for this week would be that we'd all begin
to look a bit more beyond our own noses and get to the point where
involving other people and teams right away becomes the norm, instead of
trying to circumvent the (perceived or not) shortcomings of components
or areas for which these others are really responsible.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils redhat com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]