Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756331AbaDPTNp (ORCPT ); Wed, 16 Apr 2014 15:13:45 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:57676 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751307AbaDPTNn (ORCPT ); Wed, 16 Apr 2014 15:13:43 -0400 MIME-Version: 1.0 In-Reply-To: <20140416190657.GK31074@redhat.com> References: <20140416002010.GA5035@redhat.com> <20140416.085743.1614257692560892039.davem@davemloft.net> <1397664837.19767.410.camel@willson.li.ssimo.org> <20140416180642.GG31074@redhat.com> <20140416182530.GB550@redhat.com> <20140416190657.GK31074@redhat.com> From: Andy Lutomirski Date: Wed, 16 Apr 2014 12:13:21 -0700 Message-ID: Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path To: Vivek Goyal Cc: Simo Sorce , David Miller , 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 12:06 PM, Vivek Goyal wrote: > On Wed, Apr 16, 2014 at 11:35:13AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal wrote: >> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote: >> > >> > [..] >> >> > Ok, so passing cgroup information is not necessarily a problem as long >> >> > as it is not used for authentication. So say somebody is just logging >> >> > all the client request and which cgroup client was in, that should not >> >> > be a problem. >> >> >> >> Do you consider correct attribution of logging messages to be >> >> important? If so, then this is a kind of authentication, albeit one >> >> where the impact of screwing it up is a bit lower. >> > >> > So not passing cgroup information makes attribution more correct. Just >> > logging of information is authentication how? Both kernel and user space >> > log message into /var/log/messages and kernel messages are prefixed with >> > "kernel". So this somehow becomes are sort of authentication. I don't >> > get it. >> >> I did a bad job of explaining what I meant. >> >> I think that, currently, log lines can be correctly attributed to the >> kernel or to userspace, but determining where in userspace a log line >> came from is a bit flaky. One of the goals of these patches is to >> make log attribution less flaky. But if you want log attribution to >> be completely correct, even in the presence of malicious programs, >> then I think that the current patches aren't quite there. > > Why do you think that current patches are not there yet in the presence of > malicious program. In your example, one program opened the socket and > passed it to malicious program. And all the future messages are coming > from malicious program. As long as receiver checks for SO_PASSCGROUP, > it covers your example. This is backwards. The malicious program opens the socket and passes it to an unwitting non-malicious program. That non-malicious program sends messages, and the logging daemon things that the non-malicious program actually intended for these messages to end up in the system log. > >> >> Is the reason that you don't want to modify the senders because you >> want users of syslog(3) to get the new behavior? If so, I think it >> would be nice to update glibc to fix that, but maybe the kernel should >> cooperate, and maybe SO_PEERCGROUP is a decent way to handle this. > > Modifying every user of unix sockets to start passing cgroup information > will make sense only if it was deemed that passing cgroup information > is risky inherently and should be done only in selected cases. > > I think so far our understanding is that we can't find anything > inherently wrong with passing cgroup information, though there might > be some corner cases we can run into and which are not obivious right > now. I think I've explained why causing write(2) to start transmitting the caller's cgroup is problematic. Your SO_PASSCGROUP patch does that. Your SO_PEERCGROUP patch does not. I'm still nervous about SO_PEERCGROUP and about a variant of SO_PASSCGROUP that used the cgroup as of the time of connect(2), but I'm much less convinced that there's an actual problem. My nervousness here is more that I don't like APIs that aren't clearly safe. --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/