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@xxxxxxxxx) 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@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
