Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756606AbaDPUY5 (ORCPT ); Wed, 16 Apr 2014 16:24:57 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:40169 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756075AbaDPUYy (ORCPT ); Wed, 16 Apr 2014 16:24:54 -0400 MIME-Version: 1.0 In-Reply-To: <20140416193918.GM31074@redhat.com> References: <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> <20140416193918.GM31074@redhat.com> From: Andy Lutomirski Date: Wed, 16 Apr 2014 13:24:32 -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:39 PM, Vivek Goyal wrote: > On Wed, Apr 16, 2014 at 12:13:21PM -0700, Andy Lutomirski wrote: >> 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. > > Either way you look at it, I can't see the problem. Even without cgroup > info, in your example, a non-malicious programs error message will show > up at the receiver (Because malicious program passed that fd as stdout > to non-malicious program). > > Are you complainig about this? > > Or are you complaing that non-malicious program's cgroup info will show > up at the receiver. What's the problem with that. Receiver can use > SO_PASSCGROUP and get non-malicious programs cgroup and log it (along > with error message). I don't see where is the problem in that. I'm not talking about the risk that someone learns someone's cgroup. I'm talking about the risk that a malicious program can get a lot entry like: "whatever planted text" _SYSTEMD_UNIT=non-malicious.service. That is, they've spoofed a log line. If you don't care about spoofing of log lines, then there's no point to having the kernel validate them anyway. --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/