Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 28 Oct 2002 18:30:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 28 Oct 2002 18:30:11 -0500 Received: from sphinx.mythic-beasts.com ([195.82.107.246]:16142 "EHLO sphinx.mythic-beasts.com") by vger.kernel.org with ESMTP id ; Mon, 28 Oct 2002 18:29:55 -0500 Date: Mon, 28 Oct 2002 23:36:13 +0000 (GMT) From: X-X-Sender: To: Olaf Dietsche cc: Subject: Re: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch In-Reply-To: <87smyqnpf3.fsf@goat.bogus.local> Message-ID: 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: 1247 Lines: 33 On Mon, 28 Oct 2002, Olaf Dietsche wrote: > Solving the last issue (checking access to the capabilities database) > involves filesystem support, I guess. So, this will be the next step > to address. > > If you're careful with giving away capabilities however, this patch > can make your system more secure as it is. But this isn't fully > explored, so you might achieve the opposite and open new security > holes. Have you checked how glibc handles an executable with filesystem capabilities? e.g. can an LD_PRELOAD hack subvert the privileged executable? I'm not sure what the current glibc security check is, but it used to be simple *uid() vs. *euid() checks. This would not catch an executable with filesystem capabilities. Have a look at http://security-archive.merton.ox.ac.uk/security-audit-199907/0192.html I think the eventual plan was that we pass the kernel's current->dumpable as an ELF note. Not sure if it got done. Alternatively glibc could use prctl(PR_GET_DUMPABLE). Cheers Chris - 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/