Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 3 Nov 2002 10:55:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 3 Nov 2002 10:55:00 -0500 Received: from mailout07.sul.t-online.com ([194.25.134.83]:13200 "EHLO mailout07.sul.t-online.com") by vger.kernel.org with ESMTP id ; Sun, 3 Nov 2002 10:54:59 -0500 Cc: Linus Torvalds , Oliver Xymoron , "Theodore Ts'o" , Dax Kelson , Rusty Russell , linux-kernel@vger.kernel.org, davej@suse.de References: From: Olaf Dietsche To: Alexander Viro Subject: Re: Filesystem Capabilities in 2.6? Date: Sun, 03 Nov 2002 17:01:10 +0100 Message-ID: <87u1iymym1.fsf@goat.bogus.local> User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2566 Lines: 57 Alexander Viro writes: > On Sun, 3 Nov 2002, Olaf Dietsche wrote: > >> > And as Al points out, new security features don't mean that you can just >> > stop being careful. >> >> Stating the obvious. Capabilities are not an end in itself, nor is suid >> root. It's just another line of defense to help with these binaries, >> which are _not_ capability aware. > > Bullshit. To _be_ careful you need to understand the implications of > what you are doing. Where did I, or anyone else, state the opposite? > To do so in a more complicated model is harder, > not easier. Because it's harder for you to do a proper job, doesn't mean it is for everybody else. > More features != better security. Quite often it's exact opposite. > Human do make errors, otherwise suid-root stuff wouldn't be a problem > to start with. And when security mechanism increases probability > of error it becomes a menace. Capabilities are not about adding features, they are about reducing. Face it, you just don't get it. > Odds of getting screwed are 0 if programs contain no bugs. We are dealing > with real world and there are non-zero odds of exploitable holes being there > and getting found. What we want is to decrease the odds of compromise, > right? So how are ACLs/capabilities/etc. settings different from program > internals? Either can contain bugs. Neither is guaranteed to be done > correctly. Odds of compromise depend on odds of bugs in both. Yet you > seem to imply that metadata *will* be set correctly. By the same vendors > that had shipped vulnerable binary in the first place. Even though the > complexity of metadata had grown. Agreed in _every_ _single_ _point_. But because there might be stupid vendors out there, doesn't mean I have to bow down to their level. And that is, what this is all about. I want to have this choice and fortunately, I have it. > Please, get real. "Completely understood" is much more important than > "versatile" when it comes to security models. And as for additional lines So, what's your point? Like with suid root, capability settings need to be debugged, bug reports filed and people educated. > of defense... How did it go? "For extra privacy that message had been > twice encrypted with ROT13"... Well, _that_ is bullshit. Regards, Olaf. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/