Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755043AbaDPR3d (ORCPT ); Wed, 16 Apr 2014 13:29:33 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:63674 "EHLO mail-la0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754308AbaDPR3a (ORCPT ); Wed, 16 Apr 2014 13:29:30 -0400 MIME-Version: 1.0 In-Reply-To: <1397667766.19767.440.camel@willson.li.ssimo.org> References: <20140416002010.GA5035@redhat.com> <20140416.085743.1614257692560892039.davem@davemloft.net> <1397664837.19767.410.camel@willson.li.ssimo.org> <1397667766.19767.440.camel@willson.li.ssimo.org> From: Andy Lutomirski Date: Wed, 16 Apr 2014 10:29:08 -0700 Message-ID: Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path To: Simo Sorce Cc: David Miller , Vivek Goyal , Tejun Heo , Daniel Walsh , "linux-kernel@vger.kernel.org" , lpoetter@redhat.com, cgroups@vger.kernel.org, kay@redhat.com, Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 16, 2014 at 10:02 AM, Simo Sorce wrote: > On Wed, 2014-04-16 at 09:31 -0700, Andy Lutomirski wrote: >> On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote: >> > On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote: >> >> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote: >> >> > >> >> > Please, just stop. >> >> >> >> No. >> >> >> >> This thread is proposing an ABI. This means that, if the ABI ends up >> >> in Linus's kernel, then it has to be supported forever. Now is the >> >> time to find and fix any issues with it before they become much harder >> >> to fix. >> > >> > Ok, but so far I haven't seen a single objection from you that has solid >> > grounds. >> >> CVE-2013-1959 was caused by a new kernel feature causing a call to >> write(2) to behave as though the caller was authenticating itself to >> something else where, in previous kernels, write(2) did not >> authenticate. >> >> Admittedly cgroups aren't currently as important as uid, but if this >> changes, then SO_PASSCGROUP, as currently written, will have *exactly* >> the same problem. > > Which is easy to foil by using SO_PEERCGROUP and find out who originally > opened the socket, which is why that is also available! Then please remove SO_PASSCGROUP. >> The issue here is that the receiver sets SO_(PASS|PEER)CGROUP, forcing >> the sender to identify or authenticate itself. The sender might not >> want to identify itself. > > You need to explain, why, on a host, when an application connects to > another, it is ok to make it anonymous. If you do not want to expose > yourself, do not talk to other applications in the first place. Why is anonymity harmful here? I don't have a great argument off the top of my head for why it's necessary, but neither do I see why it's bad. And I think a lack of anonymity is asking for trouble (see below). > >> the sender might not intend to authenticate. Certainly no existing >> callers of connect or write intend to authenticate using their cgroup, >> since current kernels don't have those semantics. > > This is a passive check, it's the receiver that wants to make decisions > about who is connecting, again if you do not want to "disclose" > information do not connect in the first place ? > Let's say I have a receiver. I'll call it journald, since I think that's one of the eventual use cases. Let's also say I some random program on my box. It is willing to answer requests on behalf of anyone else with the same uid, and it will happily open a given unix socket and send the requester the file descriptor. Such a program is a bit odd, but it's perfectly safe right now. Now add a malicious program into the mix. It asks the daemon to open /run/systemd/journal/socket. Then it starts writing to the fd. Whoops, now the malicious program can impersonate the helper. This happens because SO_PEERCGROUP (and journald's use of SO_PEERCGROUP) caused connect(2) to produce a descriptor that carries a permission that the descriptor did not carry in the past, and because the caller of connect(2) did not need to opt in to the new behavior. I still haven't seen any explanation for what's wrong with requiring senders to ask the kernel to transmit their cgroup. --Andy -- 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/